[Scummvm-devel] Overlay handling

Marcus Comstedt marcus at mc.pp.se
Wed Jan 21 13:24:34 CET 2009


Max Horn <max at quendi.de> writes:

> As long as your system supports OpenGL, aye -- not all our ports do,  
> though.

Of course, but I just pointed out that there is no requirement
to copy the game graphics to the overlay that would hamper an
OpenGL port as you were suggesting.


> True, but only in the Dreamcast. No other port supports this.

The support is not in the port, but in the blending function in
the UI code.  It needs to take the old alpha value of the pixel
into account, and output a new alpha value, and then it just works.


> And in fact, nothing uses the alpha channel anymore,

Huh?  So the DC is nothing then?


> support for it was  
> dropped in one of the last two GUI code rewrites.

In that case it's a regression which needs to be fixed.  It
was working ok in 0.12.0.  If someone points me to the alpha
blending code in the new GUI code is I can give it a look.


> 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.

Actually, it is not strictly necessary to use
kFeatureOverlaySupportsAlpha; a correct alpha blending function
works with both alpha-based and non-alpha-based overlays.  The use
of kFeatureOverlaySupportsAlpha was simply an optimization to use
a simpler (and faster) algorithm on systems which did not need
true alpha blending.


> 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.

As I said, there is no strict need for two codes.  An overlay
without alpha should return an alpha value of 0xff for all pixels,
in which case a true alpha blender gives the same result as the
"fake" one, and the resulting pixel will always have alpha 0xff
as well.  So we can remove the "fake" code without forcing a change
in all ports.  There would be a slight performance penalty for the
ones who stick to the old way, but nothing major.

Of course, moving game graphics would still not work for overlays
without alpha, as the graphics would only be updated when the overlay
is redrawn.


> 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.

Yes.  I think it's prudent not to require overlay alpha, but simply
to allow it for ports where it makes sense.  I don't know if that
implies any conditional handling on the subject of game freezing,
or if we should simply keep freezing the game on all systems.


  // Marcus






More information about the Scummvm-devel mailing list