"Correct" Mode Change and RGB<>BGR detection for BASIC code ?
Kuemmel (439) 384 posts |
Following some discussion in the programmers newsgroup I want to raise some talk also here about what would be the most wise or correct way to change the screen mode in one’s single task BASIC code. And by most wise I mean to have it working basically on all devices (of course I know there’s no palette mode’s any more with OMAP5). Especially since the arrival of the OMAP5 boards it’s not an easy task any more. A simple “MODE” command doesn’t work for e.g. setting mode to 800×600×32 Bit Colour. It displays an error like screen mode not available. A “OS_ScreenMode”,0,block with the necessary data and check of the mode flags works, but I’m not yet sure if that’s the holy grail. Any other ideas ? Furthermore since OMAP5 (at least for me, as it’s no issue on RPI, Panda or Beagle) we need to know if RGB order is BGR so that your graphics code (once you are doing low level stuff with graphics…) knows in what order to write or read screen data. I guess for that the only option is to read that from the mode flags ? …and then use the desired code for RGB or BGR. Any other way around that ? |
Jeffrey Lee (213) 6048 posts |
BASIC’s MODE command is certainly one of the things that hasn’t been touched yet – at the moment requesting a BPP of “16” will work if a 15bpp colour TBGR mode is available, and “32” will only work with a 32bpp colour TBGR mode is available. Considering that all the OS rendering routines support the new modes, I’m wondering whether the solution there would be to have it automatically pick the most compatible pixel format, similar to the way the display manager operates – e.g. selecting a BPP of 16 would actually try the following modes:
And for a BPP of 32 it would try:
If software is directly accessing the screen or assuming that pixels are in the traditional format then this might cause some compatibility issues – but in theory we already suffer from those kinds of problems due to the way numbered modes are substituted for others (generally an equivalent-resolution 8bpp mode) if the requested mode isn’t available.
That’s probably the best approach for now. If you want you can also enumerate the available screen modes and work out which pixel formats are available from that, but that’s a bit of a complex operation (both for you and the OS) since there’s no way of just getting the pixel formats that are supported for a specific resolution. If we want, I think there are two things we could try to make mode selection easier:
For writing to the screen, you can use ColourTrans_ReturnColourNumber to convert a &BBGGRR00 format colour to the right pixel value for the current mode. But it’s not the kind of thing you’d want to do on a per-pixel basis if you’re trying to render a full screen at a reasonable framerate :-) (e.g. I recently updated ArcEm to use that SWI, but it uses it to build a 4K entry lookup table which is used until the next mode change) There’s no equivalent SWI for reading from the screen (there’s one for converting to a GCOL number, but that’s a bit useless and I’m not even sure it works correctly outside of 8bpp modes), so maybe that’s another thing we can improve. |
Chris Hall (132) 3554 posts |
BASIC’s MODE command is certainly one of the things that hasn’t been touched yet Since version 1.06 (23-Aug-1993) I think you mean:
Also version 1.26 (20-Apr-2001):
More detail here – the BASIC manual still describes version 1.05 (either 1988 or 1992 depending which version of the manual you have, possibly plus an addendum dated April 1995). |
Jeffrey Lee (213) 6048 posts |
I probably wasn’t clear enough; I was talking about the “MODE <width>,<height>,<bpp>[,<framerate>]” version, which hasn’t been updated to add any way of selecting the new screen modes. “MODE <string>” can be used to select the new modes (since it just uses *WimpMode, which uses the new-ish OS_ScreenMode 15 and so supports the full mode string syntax), but since it uses *WimpMode it’s probably something best to avoid (a single tasking BASIC program shouldn’t be messing with the wimp mode! Why on earth did Acorn think that was a good idea?) |