[Scummvm-devel] Overlay handling
Max Horn
max at quendi.de
Wed Jan 21 04:15:43 CET 2009
Am 20.01.2009 um 20:37 schrieb Marcus Comstedt:
>
> Max Horn <max at quendi.de> writes:
>
>> Right now we implement transparency for the overlays by making a copy
>> of the game graphics to the overlay, then blitting our data atop it.
>> Makes it difficult for backends to speed up things with OpenGL etc.
>> and of course also impossible (with sane computation time) to work
>> atop changing game graphics.
>
> Actually, an OpenGL accelerated overlay should not be difficult
> at all.
As long as your system supports OpenGL, aye -- not all our ports do,
though.
> You just need to do what I do in the Dreamcast port:
>
> * Use a pixel format with a couple of alpha bits for the overlay
> * Make the OSystem return true for the kFeatureOverlaySupportsAlpha
> feature
> * Make clearOverlay() fill the overlay with transparent pixels,
> nothing should be copied from the game graphics
>
> Then the overlay will work just fine atop changing game graphics.
> This support has been there for almost 4 years. :-)
True, but only in the Dreamcast. No other port supports this. And in
fact, nothing uses the alpha channel anymore, support for it was
dropped in one of the last two GUI code rewrites. In fact, there are
exactly two occurrences of kFeatureOverlaySupportsAlpha in the source,
once in common/system.h and once in the DC backend. So your nice alpha
channel support is never used anywhere.
Part of why kFeatureOverlaySupportsAlpha was dropped was that
virtually no backend supported it, hence maintaining this second code
path in the GUI was deemed pointless.
Read my mail as stating that we maybe should force all backends to
support an alpha channel. And at the same time, rewrite the GUI code
to use that, and remove the "fake" transparency code in the GUI code.
But there's really a big question mark after this "maybe" -- adding
such a requirement could incur nasty performance penalty on some
ports. At the very least, it would require most of our porters to put
some serious effort into rewriting their overlay support.
I am not saying it can't be done, though. However, the fact that we
have so many ports but so few port maintainers with spare time at
their hands is becoming more and more a problem for us. Changing our
APIs in a major way ideally requires input from as many maintainers as
possible (to avoid making changes that would break lots of ports), and
also requires them to code changes. Sadly, past experience shows that
this is somewhat unlikely to happen :/.
Cheers,
Max
More information about the Scummvm-devel
mailing list