[Scummvm-devel] Re: 16 bit graphics: Thoughts on how to implement it

[Max Horn]

At 16:34 Uhr +0100 24.07.2002, Ruediger Hanke wrote:
>Hi Max,
>
>ok, I see 16 bit graphics are quite needed for stuff like GUI. I agree
>it won't be worth to change _everything_ to draw in 16 bit from the
>start.
>
>*But* ... in one point you're wrong ... it will definitely be slower, at
>least for my port.
>
>As for color cycling and LUT mapping stuff ... on systems like MorphOS
>or AmigaOS it doesn't matter if the desktop is running in 16 bit, you
>can still open an 8 bit screen and voilá I've got a palette environment.
>And this is much faster than than any 16 bit stuff as I don't have to
>map color indices to RGB values (esp. for color cycling). It can't use any
>scaling then, but at least it's full-screen sized and not a tiny window.
>I sometimes play in 8 bit myself :)

Interesting. So this then is hardware palette support inside a 16 bit 
screenn ?!? You are sure that it doesn't just do the palette 
conversion itself (like it would do on MacOS - I can open 8 bit 
windows here, too, that just means the OS will deal with the software 
palette for me).


>Same with scaling, I do the scaling myself and not with the functions
>from scale.cpp, and with some minor modifications I can speed it up
>quite a bit. Ok, still room to optimize things that the SDL driver does
>better ATM but I'd lose some speed by not scaling myself.

So, do you want to say that you can't do scaling for a 16 bit screen?


>This is just an idea thrown in and not a really thought-over plan, but
>I could imagine something like a 16 bit "overlay" that may be
>drawn on top of the game screen which is used for GUI stuff. So as
>for the game screen itself "business as usual", but add a function
>copy_overlay_rect or so which supplies data in 16 bit. (Just a quick
>thought)

I actually considered that approach, too. On the negative side, it 
would make live considerably harder for backends - they would have to 
support 8 bit palette data *and* 16 bit graphics data, and they would 
have to implement the overlaying etc. On the pro side, this would be 
even simpler to implement for the system independent part of ScummVM 
- basically only NewGUI would have to use the overlay stuff.

Overlays should be allowed to be "transparent", though, this would 
still force some sort of conversion in the backends. Alas, they could 
just choose to not implement the alpha blending.

One helpful thing (implementation wise) is that currently, if an 
overlay is showing, the 8bit part will be frozen. Backends could use 
that fact to greatly optimize things (like the above mentioned alpha 
blending).

What do other porters (dreamcast, X11, Windows...) say to this?



>As for dropping 8 bit entirely ... as I mentioned above, 8 bit may be
>available on some systems for great speed improvements, and it
>may be argued that "just" a new GUI may be worth it ...

OK, that was one of the purposes of my mail, to find out about such 
concerns. Though I must admit that I am surprised, I wasn't aware 
that there is still hardware being used out there that can't deal 
with 16 bit graphics sufficiently fast. :-) That doesn't mean I want 
to suggest to ignore you of course. I am glad for your feedback.


>  maybe the
>old GUI remains and is still used for 8 bit screens, and the new GUI
>is used for 16/32 bit screens. Or it's just ignored or the driver tries
>to map the overlay to the colors on screen as good as possible ...

Just FYI: The "old GUI" is just a save game dialog plus some bits. 
The new GUI when finished will, besides other things, allow you to 
set all preferences, choose which game to play, let you specify paths 
etc.

In any case, this sounds like a support nightmare. I'd much prefer to 
drop the old GUI like a hot potatoe as soon as NewGUI is ready to 
supply everything old GUI did, even if it will not yet be at it's 
100% completness stage then. Old GUI is just a big mess...


>As for reading back pixels, again I think this should be left to the
>system driver. At least I could read back pixels easier using the OS
>without the need for yet another full-size 16 bit buffer.
>
>One last note, even if I can't keep you from doing everything as
>you planned :),

Read my mail again, I didn't "plan" anything yet, I just started a 
discussion - we have to talk it over eventually, so I figured we 
should start it now :-)


>I hope that you won't just simply supply the data
>in 16 bit but in the actual pixel format used by the hardware ...
>otherwise you've got two conversions: one ScummVM-internal
>8 -> 16 bit, and one by the system driver or SDL or the OS from
>16->24 bit or 565 16 bit -> 565 byteswapped 16 bit etc etc.

The overlay approach would deal nicely with this I think...



Cheers,

Max
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:max at quendi.de>
phone: (+49) 6151-494890