Recording the RISC OS desktop
GavinWraith (26) 1532 posts |
I see that for Linux there are lots of desktop-recording applications. Presumably they save out a chosen part of the screen as an MP4, with or without sound. Is there anything like that for RISC OS? Alternatively, is there any means of displaying the RISC OS desktop in a window on a machine running Raspbian? |
andym (447) 464 posts |
You could use Jeffrey Lee’s VNC Server and a VNC Viewer on Raspbian. I always use Steve Potts’ excellent VNC Front End with the server as it makes configuration nice and easy. |
David Feugey (2125) 2687 posts |
I use an Avermedia Game Capture HD 2 and the result is just perfect. It’s an hardware device, but very affordable, since second hand models are common. I bought mine around 40 E. |
GavinWraith (26) 1532 posts |
Thanks for the advice. Raspbian has a VNC Viewer provided as part of the distribution, and I got it working with Jeffery Lee’s VNC server. This opens up all sorts of possibilities that I had not previously envisaged. |
GavinWraith (26) 1532 posts |
I think VNC is doing more than I want, and I do not know the pukka terminology for what I do want. If I have got it right, then what VNC does is: 1) Send the server’s monitor output to the client, and I want 1) on its own, without 2). What I want would be achieved, more indirectly, by having a camera record the server’s monitor and feeding its data to a window on the client’s desktop. Can VNC be configured to do just this? |
andym (447) 464 posts |
Using the server front end, simply untick the ‘Allow keyboard and mouse’ radio button and restart the server. There will be a command line option to do this if you’re not using the front end that achieves the same. |
Raik (463) 2026 posts |
What will you do? Have try to made a small ffmpeg based “Screen Capture Tool”. It is working in desktop but it is not fast and the mouse pointer is not visible. You can create something like this (made with my PiTab). |
Bernard Boase (169) 190 posts |
This looks interesting. Can you say anything about how you are using ffmpeg to achieve screen capture? I take it that you use your developing !MovieCentre to add the subtitles? And what are the chances that someone can discover how to make the mouse pointer visible in this method of screen capture? |
Raik (463) 2026 posts |
What I wrote was not really clear ;-) I’m not sure. Is it possible to make the mouse pointer visible in a screenshot? |
Chris Johnson (125) 819 posts |
There are ways of doing it. Snapper has the option to include the pointer in snaps. It does this by overwriting the snap with the mouse pointer in the correct position. If you wish to talk about this and see the code (in C) let me know. If you are creating a movie, then the additional code could slow things up a little. There may be other ways to capture the pointer. Some of the large extent screen modes possible now use a software pointer generated by the OS do they not? |
Raik (463) 2026 posts |
Have play around with !Snapper. On Titanium (5.25 05-Dec-2018) with C16M in screenmode it gives a “Internal Typ2 error”, with C64KB it works but I never get a mouse pointer in snaps. Same things with RPCEmu works. |
Rick Murray (539) 13405 posts |
It’s a calculation error. Type 2 is SIGFPE. You’d know that, and where, if CLib programs generated decent backtrace/dumps as standard. ;-) |
Chris Johnson (125) 819 posts |
As far as I know, Snapper was working fine on the Titanium when I tested it a while back. I will have a look at this later on.
Not quite sure what you wish to do here. Do you mean call Snapper from another program to take a screen shot? This might be possible with a bit of mucking with the code. Anything other than a full screen would be another thing altogether. |
Chris Johnson (125) 819 posts |
OK. I can confirm that Snapper does a type 2 if you set it to show the pointer superimposed on the snap. This occurs on the Titanium and the IGEPv5 but not on the ARMX6. I shall need to look at this. Not sure when it started, because I do not normally have the show pointer option set. The IGEPv5 ROM of Nov 17 shows it. The Titanium, with Apr 18 and Mar 19, shows it. The ARMX6 with ROM Aug 18 does not show it. Looks like some debugging will be required 8( |
Raik (463) 2026 posts |
Have try *snapper_key &68 (have changed the snapper config to menu key) on RPCEmu in a TaskWindow. Was working exactly for one snap. Then never again. Also not after reboot. I’m a bit confused. |
Chris Johnson (125) 819 posts |
To my mind that means the hot key combination will be (right ctrl + right shift + left logo). You obviously need to load the module and reenter the command after a reboot (or use the front end to automatically start the module and send the command when Snapper is started). I haven’t had time to set up a debug version and test it yet – other things to do! |
Rick Murray (539) 13405 posts |
Is it built with function names? If so, try: *set debugger$dumpoptions -file annotated *set debugger$annotatedfile $.whatever Then crash it and see if the output file tells you anything… |
Chris Johnson (125) 819 posts |
I think I have now fixed this. It would appear that the pointer is still defined in ‘new sprite format RISC OS 3.5’ on the ARMX6, but is defined in ‘even newer sprite format RISC OS 5’ on the IGEPv5 (and I assume the Ti which I haven’t checked yet). Snapper was assuming the pointer was always defined in RISC OS 3.5 sprite format, and a divide by zero was being generated during the superimposition of the pointer onto the snap. I will do some more playing later, and if things are still OK on all three hardware, I will put up the fixed version. |
Jeffrey Lee (213) 6046 posts |
Interesting – how are you getting the pointer shape? |
Chris Johnson (125) 819 posts |
The magic incantations were produced by David Pilling as a support module a long time ago. I have very little input to this area and have had little need to look at the code. Very briefly: There is a support module which Snapper loads when it starts. This module claims a number of software vectors – keyv, wordv, bytev. The keyv allows the state of the relevant hot keys to be monitored (down/up state). Sitting on the Wordv and Bytev allows
The main Snapper front end uses a couple of SWI calls in to the module to (a) check the state of the set hot keys at null polls and if they are all down to initiate the snap. (b) once the snap is complete, if the flag to superimpose the pointer is set, a second SWI returns the pointer in use (1-4) and the address of the buffer holding the four definitions. This data is then used by the front end to reconstruct the pointer and superimpose it on the snap in the correct position. If you are interested in the finer detail then I can put the Basic assembler source for the module on my web site. |
Rick Murray (539) 13405 posts |
The original source is here: https://www.davidpilling.com/wiki/index.php/Snapper |
Chris Evans (457) 1614 posts |
Related to ‘new new sprite’ formats !Paint 2.23 11.11.2017 as supplied with 5.24 Seems to default1 to ‘new new sprite’ format on the IGEPv5 & Titanium but not on the Pi! This means their sprites can’t often be viewed on RISC OS 3, 4 or pre 2017? 5 Unless a late version of ChangeFSI is used. Which is a real pain. I can’t see a way of telling paint to not use the new format. What are the cons for making it available? Can ChangeFSI by used to convert them? 1 This is when snapshoting or creating new. |
nemo (145) 2437 posts |
Uggh, that’s a good point. “Best format for the platform” is not necessarily “best format for portability”.
I’d always expect a snapshot to be in the format of the actual screen, which may well be BGR, 565 etc. |
Chris Johnson (125) 819 posts |
!Paint 2.23 11.11.2017 as supplied with 5.24 Seems to default1 to ‘new new sprite’ format on the IGEPv5 & Titanium but not on the Pi! If you are concerned about screen or area snapshots, then !Snapper will help you out. Its default action is to save the snap in the native format (bpp, bgr/rgb, etc), but there is a user setting to convert the snap to original ‘new sprite’ format (RISC OS 3.5). The only downside is that a 64k 5/6/5 format would be reduced to the standard 32K format. |