[Scummvm-devel] New GUI; PNG, zlib BMP and other formats

Max Horn max at quendi.de
Tue Aug 23 11:34:08 CEST 2005


Yo folks,

I am sitting here next to my cousin, whom I am currently forcing to  
create a sketch for a revised ScummVM GUI, based on / inspired by the  
new web site design. Looks pretty nifty so far... I'll show some  
drafts once this has progressed a bit more.

I also started hacking on supporting this required UI. I have to load  
graphic files for this, though (e.g. for the logo). And ideally, I'd  
like the thing to be flexible and customizable, so that we can revise  
the UI if we want to -- hence I do not want to hard code the looks of  
a button, but rather would like to control it via a few image files.

This rises some questions:

1) Portability, which mostly means: Memory usage. Of course using  
bitmaps (for the ScummVM logo, launcher background, buttons) means  
more memory is used up. Alas, not all our ports even use the  
launcher. Some (PalmOS) already offer a skinnable UI. I am not sure  
whether we have a problem here or not, I need to learn what our  
porters think to judge this properly...

2) Data formats. Right now, I am storing everything in BMP files  
(simply because SDL provides a loader for this, so it was the  
quickest thing to hack in). Mind you, this is encapsulated, so I can  
plugin anything else. We could use PNG (via libpng). Or zlib  
compressed BMPs (which gives me comparable compression ratios as PNG,  
actually). Since we already require zlib for compressed savegames, I  
figured the latter might be nicer

3) External resources vs. compiled in: The drawback of having our GUI  
code rely on external images is that if those images are lost (e.g.  
user deleted them), ScummVM wouldn't run. (this could be avoided by  
having fallback code ready). OTOH the advantage is that it makes it  
very easy for people to customize the UI (ScummVM would be  
"skinnable"). I am not *that* happy about this, actually, but it sure  
simplifies the live of a graphics designer, who can test new UI  
sketches immediately, w/o having to recompile ScummVM or anything  
like that. My thought here is to have an abstract image reader API;  
client code doesn't care where it's data comes from. The image reader  
then could read built-in data, BMP, PNG, TIFF, whatever we like. It  
could even first try to read an external BMP and if that is not  
present fall back to a built in picture. On a Palm it could do  
something different yet again. etc.


Cheers,
Max




More information about the Scummvm-devel mailing list