Conversion of applications using 8bpp modes

Since the PineBook Pro does not support (yet?) 8bpp modes, I need to adapt most of the full-screen plugins used by DigitalCD which rely entirely on it. The idea is in such situation to use the same colour depth as the desktop, redirect the output to a 256 sprite then plot that sprite.

I started yesterday with Cthugha and I will list here the issues which I encountered to provide some guidelines for other developers.

First I should maybe list some technical features of Chugha:

• uses tripple buffering
• uses a lot of different 256 colours palettes.
• works internally with 2 buffers which are used to transform the current image into the next one. They are defined as sprites so that I can redirect output to them and plot some text in it.
• the current buffer is then copied on screen with possibly effects like mirroring and some kind of OSD can be plotted over it.

So here are guidelines and issues:

• set as mode number for the 8bpp sprite you use to redirect your output the pointer to the 8bpp mode specifier you intended to use. This will avoid discrepencies like differing EigFactors.
• substitute the address of the first pixel of that sprite to the screen write address in case you intend to poke the screen directly.
• your main processing loop will now perform:
  • switch output to sprite (OS_SpriteOp 60 with a save area whose size is given by OS_SpriteOp 62)
  • process frame
  • switch output back to screen (OS_SpriteOp 60 with the parameters given on exit of the first call to OS_SpriteOp 60)
  • plot the sprite
• after that you may notice that some things are not quite right, because actually you performed some one time screen related configuration (like setting the size of text characters, …) before your main loop, that is to say when your output is not redirected to the sprite.
• I told you I use a lot of palettes, well calling ColourTrans_WritePalette while the output is redirected to the sprite doesn’t touch the sprite’s palette, you will have to update it’s palette manually.
• Restoring output to the screen has a little problem: it resets the screen’s display and write pointers to the start of the first screen bank so you have to change them back to the original screen banks. Remember that I already used sprite redirection to plot some text in the internal buffers, well of course I changed the pointers back just after restoring output to the screen, except that now it is not restoring output back to the screen but to another sprite and updating these pointers in this situation is a bad idea. Touching the pointers shouldbe only performed when restoring output to the screen (Note: you cannot rely r2 = 0 on the second call to OS_SpriteOp 60, this doesn’t work on RISCOS Select).

I had a few of those problems redirecting output to a sprite with GraphTask, but the job was simplified by only supporting VDU sequences for palette changes and not any of the ColourTrans SWIs.

I don’t think this affects the ELS plugin but it reminded me of a problem I found with it a couple of years ago on the PI4. It was incorrectly setting a 15bpp mode instead of a 16bpp mode. It seems I made a small change to the read_vdu_vars function in win.c, It looks like a quick fix and may not cope with all situations but here is the zip I created at the time.
It’s compiled with gcc so the assembler files have been gcc’d.

I also had issues with the RPCEmu using 16bpp BGR modes which I don’t think ELS copes with either.

ELS was written before the major video addition in RISC OS 5 like 4K colour modes and RGB versus BGR. I am in the process of updating it to detect and setup the appropriate modes (like 64K full screen on the PI4) and update the plot routines.

Thanks André, I feel a bit responsible for it but don’t have much kit here to test on. Please let me know if I can help in any way.