[Scummvm-devel] Overlay handling

[Max Horn]

Hi all, Marcus,

I think as as so oftenn we two manage to miss each other's point *g*.


Am 21.01.2009 um 07:24 schrieb Marcus Comstedt:

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

OK, I see now what you were getting at. Agreed!

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

Of course the DC port is not "nothing" -- sorry, didn't mean for it to  
come across like that. Let me rephrase the two statements:

(1) The DC port is currently the only port providing support for an  
overlay with an alpha channel.

(2) None of the "generic" code (outside of backends/platforms, like  
the GUI code, or the vkeybd code, etc.) makes use of a potential alpha  
channel. Mainly because of point (1)

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

I wouldn't call it a regression. At that time, it was a more or less  
conscious decision not to re-implement the alpha channel rendering  
code when the GUI code was rewritten again. I wasn't part of that, but  
I can see and understand the reasoning, given (1) above. In fact, had  
it been implemented, then the only way to verify that it actually  
works would have been to try it with the DC port, which 99% or more of  
us don't have access to.

That doesn't say we shouldn't consider re-enabling support for alpha- 
channel enabled overlays (with that I implicitly assume that the  
*backend* then is responsible for compositing this over the game  
graphics). But since we'll have to expend man power to write and  
maintain that code, IMHO it only makes sense to consider doing so if  
more ports would take advantage (and, no offense intended, ports that  
target a bigger audience than the DC port).

In particular, in my eyes it only makes sense to spend that effort if  
the SDL backend implemented an alpha channel enabled overlay. This is  
still our primary port and the majority of developement testing is  
done there.

And I think it would be attractive to do so for various reasons.  In  
fact, in my dream world, we'd only alpha channel based blending (even  
if it's only a 1bit alpha channel in 555 mode), and remove all  
software based alpha blending from the front end code. However, I am  
somewhat skeptical as to whether this is possible, esp. on WinCE,  
Symbian and PalmOS. BUt besides DC and SDL, I would bet that the Wii,  
GC and PS2 backends could implement alpha channel support for the  
overlay. And maybe also NDS and PSP, no idea.


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

Of course we can use an alpha channel w/o  
kFeatureOverlaySupportsAlpha. Its sole function was to determine (in  
the old GUI rendering code) where compositing happens: In the backend  
or the "frontend" code. In the past, the former was used when  
kFeatureOverlaySupportsAlpha  was enabled, and the latter otherwise.  
But we ditched the former, and now only do frontend ("software")  
compositing

In the future, maybe we just always leave the compositing to the  
backend. Then it would be up to the backends to decide how to do the  
compositing: Using OpenGL (or something equivalent), or using software  
based alpha blending. My main concern with that is the question  
whether it will be efficient enough. You called it a "a slight  
performance penalty" later on -- if it's indeed minor, then of course  
we are fine and can proceed quickly. I just don't want risk killing  
several "small" ports :).


Bye,
Max