[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