[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