Hi Tinnus, Many thanks, you were very helpful!
I will probably choose the "565 and direct buffer access" approach. I think I will fall back on WinDrawBitmap() with noDither for legacy 8-bit devices and prepare to apply some bit-shifting on native 24-bit screens (if any).
Thanks again! Regards, delon
1, rendering directly to screen buffer is still a viable alternative or a no-no?Certainly it is--most emulators (including LJP) and lots of games use it due to being lots faster. Of course your pointer and data must be 16-bit to do that in 16-bit screens though.2, do current devices have the same screen characteristics (I mean they are all(?) 16-bit hicolor now but they may differ in bit order: 565, 565LE, etc)I don't think they're ALL 16-bit--but you can check for that of course. But all that are 16bit are RGB 565. Don't worry about BE and LE before you start to transfer stuff between 68k and ARM.3, do devices really support indexed color displays? Will my 256 color mapped image be rendered as-is or an 8-bit to 16-bit pixel-by-pixel remapping takes place when I call, for example, WinDrawBitmap()?I think if you tell the window (via the API) to be in 8-bit mode, it IS in true 8-bit mode. However, I think the screen pointer itself might still be 16-bit. Not sure about that last one though. -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
-- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
