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

Kostas Nakos knakos at phys.uoa.gr
Wed Jan 21 11:28:56 CET 2009


Max Horn wrote:
> 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:

So yes, I agree too that showing the vk on the overlay while all else 
freezes makes this feature less appealing and functional. Still, it is 
usable and I really cannot decide if going for a nice feature set on the 
vk warrants code restructure.

But anyway, what the "base" target platform should be is a software blit 
only platform and 16bpp (8bpp is perhaps too low a requirement, except 
if I'm wrong :-) ). And, as it has been mentioned, it is really 
expensive to do true transparency or a fake one avoiding possibly the 
multiplications. But this kind of port could just dismiss the 
transparency altogether in a certain rect of the 16 bit screen 
containing the vk and blit a black background. So we could have an alpha 
only surface which is ignored by the base ports and an associated 
overlay-containing rect which define the part of the screen to obscure. 
I think that should be fast enough. Overdraw can be eliminated e.g. by 
splitting a full screen update into 4 (max) rects (this hurts a little 
more for unaligned blits). The overlay rect should be able to be 
positioned freely around the screen to help the user see the playfield.

Still, this solution has a "hacked together for the vk" taste which is 
perhaps not that good a thing.

And what about plugging the overlay event handling in the main loop? 
Will this be handled by intercepting the PollEvent call and branching 
from there? E.g. the engine has no knowledge of the overlay being shown?

Kostas

PS. As a side note, on WinCE the keyboard is shown in the 40/80 pixels 
(height) below a 320x200 or 640x400 playfield. If the playfield is 
320x240, it is always obscured. But the keyboard can be switched off to 
show the bottom part of the screen normally.




More information about the Scummvm-devel mailing list