[Scummvm-devel] On Overlays (portes please read!)

Max Horn max at quendi.de
Wed Sep 18 08:05:02 CEST 2002


Hiya,

quite some time ago the concept of overlays was discussed here, and 
why it would be useful for us to add them in. During the last couple 
of days I had some discussions with endy and aquadran about this, and 
started a prototype implementation in the SDL backend. I run into 
some problems there, and am now essentially facing a fundamental 
decision as how to go on, and I need your input - your being mostly 
porters who have to tell me which approach is "best" for their 
system, but anybody else is welcom, too, of course.

But let me first recap:

What is it?
===========
An overlay is an additional graphics layer over the normal graphics. 
Stuff can be drawn into it w/o affecting the actual game graphics. It 
can have a different bit depth (e.g. 16 bit instead of 8 bit) than 
the rest of the game. It can be opaque or alpha blended.

Why do we want it?
==================
For the GUI. Right now, the GUI in ScummVM is tied strongly into the 
Scumm part. That means we currently can't use it in the Simon part, 
and we can't use it for the "launcher" (*).
It causes more problems: we can only use 8bit colors, and that is a 
bit limit because essentially we have to be able to display a good 
looking GUI with *any* palette - this is nearly impossible. Also the 
size of dialogs is restricted to the size of virtaul screen 0 in 
Scumm, which can be relatively small (e.g. in Zak256).
All these problems are overcome with an Overlay. 16 bit graphics (no 
palette to worry about), no size restrictions, and it'll work even in 
Simon or when no game is being run at all

Requirments
===========
* 16 bit graphic depth (we decided against 24/32 bit graphics as a 
compromise, as some devices like the GameBoy Advanced only support 16 
bit mode currently, and also have memory restrictions)
* some support for (possibly faked) "alpha blending" (this is not 
strictly necessary of course, but we really would like to have it)
* the overlay can assume that the "normal" game graphics will not 
change while it is being displays -> this can be used to optimize its 
drawing


Approaches & Problems
=====================
One of the first problems is font rendering: the current GUI relies 
on Scumm rendering text data. There is a built-in font in ScummVM 
right now, but it is very ugly and is non-proportional. Thus, we need 
to come up with a game independent font rendering; this shouldn't be 
too hard, the biggest obstacle probably is to acquire suitable font 
data.

Now, I started to design a minimal interface for the overlay (to be 
implemented by all backends):
void show_overlay();
void hide_overlay();
void copy_rect_overlay(const int16 *buf, int pitch, int x, int y, int 
w, int h);

The first two functions should be self-evident. The third one was to 
be used to display data on the overlay, working just like copy_rect, 
only that it targets the overlay (BTW, the overlay in my current 
design just always has the size of the game screen, before any 
scaling; we might want to reconsider that, but for now it keeps the 
implementation very simple).

This approach has one issue: In order to e.g. draw a rectangle frame, 
the NewGUI code would have to use an image buffer where it would draw 
that frame, then use copy_rect_overlay() to blit it to the overlay. 
This means that NewGUI has to keep a full copy of the overlay data 
(for a 320x200 screen at 16 bpp that is ~128kb). Also, it would have 
to initialise this backing store not with just all white or all black 
pixels, but rather with the current game graphics. With the current 
API that is not possible, also it wouldn't be hard (at least for the 
SDL backend) to add system API function grab_screen() which copies 
the currently displayed graphics into a buffer provided by the caller.

While this approach adds the memory taken up by one game screen at 16 
bit (usually 320x200x2 = 128 kb), it would be quite flexible. It 
would also ensure that all the drawing could be done (almost) exactly 
as now, with full flexibility.

Would this be OK for all the porters?

If not, about the only alternative I see right now would be to add 
drawing primitives to the system backends. This would mean adding 
many more function to it, plus would probably need to a lot of 
unnecessary code duplication. But it might also have advantages, I am 
not sure, feel free to point them out.



Cheers,

Max



(*) The "launcher" is my name for the planned GUI that is shown when 
you launch ScummVM, and which will then present the user with a list 
of games to play. User will also be able to setup the game paths, 
music driver, scaler, etc. in there.
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:max at quendi.de>
phone: (+49) 6151-494890




More information about the Scummvm-devel mailing list