[Scummvm-devel] Virtual keyboard code from GSoC 2008

[Max Horn]

Am 20.01.2009 um 15:00 schrieb Johannes Schickel:

> Max Horn schrieb:
>> Hi folks,
>>
>> after some recent efforts by dhweg, LordHoto and myself, the vkeybd  
>> & key remapper code at least compiles again. More work is still  
>> needed, though:
>>
>> * Fix linker errors (I'll take a look)
>
> It links fine over here at least. So I'm unsure what you mean with  
> this point :-).

Ah, I thought it was an universal problem. Anyway, on OS X, I get this  
linker error (after a "make distclean", running configure with the  
appropriate settings and then "make"):

Undefined symbols:
   "Common::VirtualKeyboard::isDisplaying()", referenced from:
       DefaultEventManager::pollEvent(Common::Event&)       in  
libbackends.a(default-events.o)
   "Common::VirtualKeyboard::loadKeyboardPack(Common::String)",  
referenced from:
       DefaultEventManager::init()      in libbackends.a(default- 
events.o)
       DefaultEventManager::init()      in libbackends.a(default- 
events.o)
   "Common::VirtualKeyboard::VirtualKeyboard()", referenced from:
       DefaultEventManager::DefaultEventManager(OSystem*)in  
libbackends.a(default-events.o)
       DefaultEventManager::DefaultEventManager(OSystem*)in  
libbackends.a(default-events.o)
   "Common::VirtualKeyboard::show()", referenced from:
       DefaultEventManager::pollEvent(Common::Event&)       in  
libbackends.a(default-events.o)
   "Common::VirtualKeyboard::close(bool)", referenced from:
       DefaultEventManager::pollEvent(Common::Event&)       in  
libbackends.a(default-events.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: *** [scummvm] Error 1
make: Target `all' not remade because of errors.


[...]

>> For the desktop, we could certainly use fancier keyboard maps,  
>> matching the looks of our themes. The advantage of the attached  
>> ones is that they compress really well, esp. the black and white  
>> version. The fact that we only support uncompressed 24bit BMPs is  
>> actually annoying here; as a bitmap BMP, it takes up only 5104  
>> bytes, as 24bit BMP it needs 40896 bytes.
>
> Actually adding support for another BMP format in the loader code  
> shouldn't be too hard. We would probably need to store the data in  
> memory in overlay format thus 16bpp though, everything else would  
> slow down drawing of the vkbd. Of course depending on how often we  
> need to redraw that might be acceptable.

Well, if we really wanted absolutely best speed, *and* if the keyboard  
was bitmap only, then it wouldn't be very hard to write a bitmap  
blitter, akin to the one we use for fonts. But I am not sure whether  
it would be worth the effort (and extra code size). But I am concerned  
that e.g. the NDS will not be able to use the vkeybd code: Right now  
it requires a 600kb .zip file (OK, for 320x200 only devices, that  
could be trimmed down), and adds a bunch of new code. And adds another  
dependency on the XML parser, so ... maybe we should the file format  
to .ini style after all... :)

And then there is Marcus' suggestion, of course. If we had a  
VectorKeyboardRenderer, then on small devices we could compile in only  
that, and get rid of all the image loading, drawing code, the XML  
parsing part, etc., etc. And it would be relatively easy to draw this  
kind of keyboard semi-transparently, too ;).




Cheers,
Max