[Scummvm-devel] Overlay handling (Was: Virtual keyboard code from GSoC 2008)

[Max Horn]

[ I am replying to the middle part of Johannes mail separately because  
it is a slightly different subject, plus my reply is a bit...  
longish :) ]

Am 20.01.2009 um 15:00 schrieb Johannes Schickel:

> Max Horn schrieb:
>>

>>
>> * Fix key remapper dialog (it will crash right now, because not all  
>> of it has been transitioned to the new system
>> * Decide what to do about the hotkeys F7 and F8 (just like the F6  
>> hotkey for the GMM)
>> * Come up with new / better keyboard packs.
>
> One thing which I find particularly annoying is that when you enable  
> the keyboard all game / GUI interaction is stopped. For example when  
> trying to enter a save game name in GMM's save dialog via the vkbd  
> it will not be displayed while using the vkbd. The whole input will  
> only be shown after the vkbd is closed. I guess that's already on  
> some TODO list though :-). It would probably require backend  
> internal handling though, since currently the vkbd is just drawn on  
> the overlay, which might lead to conflicts when the GUI would be  
> updated while the vkbd is shown.

There are two major problems with this.

1) The whole vkeybd code runs in its own event loop. If we wanted to  
show the vkeybd while the game runs, we'd have to redesign this. Like,  
by setting aside a portion of the screen for the vkeybd, and whenever  
a click occurs in there, we intercept it.

2) The current overlay code is built around the assumption that the  
underlying game graphics are frozen. This is yet another thing (of  
countless others) that would be nice to improve. Some random thoughts  
on this:

One idea is to make it possible to shrink the overlay so that instead  
of covering the whole screen, it only covers part of the screen (e.g.  
the part used for the keyboard, or the debug console). That might make  
it possible to let the engine run, and would mesh well with what I  
mentioned in part (1). However, unless it is semi-transparent, I am  
not sure how attractive it would be to let the game run while half  
your screen is covered by a virtual keyboard. In particular, the  
keyboard might very well cover the part where your typed text  
appears... Unless we make it possible to move the vkeybd around (at  
least switch it between "top" and "bottom" of screen, via a small  
toggle button or so).

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.

One alternative would be to drop that rendering mode (and drop 8bit  
overlay support), and rely on the alpha channel of the pixels instead.  
Since with 16bit graphics, that might be only 1 or even 0 bits,  
though, we might have to also add a separate alpha channel surface, or  
require all backends to implement 32bit overlays (with on-the-fly  
reductions on systems with only 16 bit graphics). Drawback: More  
memory consumed, slow on already slow 16bit GFX devices.


Cheers,
Max