[Scummvm-devel] RFC: overlays extension to OSystem

Eugene Sandulenko sev at scummvm.org
Mon Jul 12 17:12:03 CEST 2004


Max Horn writes:
 > is it easier or harder than the old overlay code etc?
The main difference here is that overlay can have different
resolution. I.e. current code applies overlay and then scales it
together with whole picture.

 > > possibility to draw on either of them. Their resolution will be
 > > independent, but usually this second buffer will be 2x scaled
 > > comparable to main buffer.
 > 
 > "Usually" meaning: it might be only 1x, or 3x, as well? Don't forget, 
 > several of our backends only support 320x200 or 320x240 and nothing 
 > more.
Yes, but games I'm talking about are at least 640x400 originally, and
that is not currently supported by all those backends. Particularly
problem arose with windows versions of early HE games which still have
320x200 graphics but always work in 640x480 with graphics streched. But
cursors there are designed for bigger resolution and they are applied
over stretched picture by means of standard Win32 calls.

 > So code using that buffer will have to be able to cope with varying 
 > scales there. No big problem, just keep it in mind, as it does 
 > complicate client code (e.g. the GUI code).
Particularly it is just another step in rendering pipeline which will
be prevented by something like `if (_overlayed)' and probably
#ifdef'ed for platform which do not support it (see below).

 > As Marcus pointed out, there is no reason whatsoever why the cursor 
 > should be in that buffer, or another -- it should be up to the backend 
 > to decide how to render the cursor... one might consider adding an 
 > option which tells the backend whether a given cursor should be scaled 
 > up or not
Well, this could work and do the job. And probably I even will end up
with just this approach. Just overlayed system was handy for FM-TOWNS
games as I was told that they used something like this to render Kanji
fonts.

 > >      RATIO is ratio between MAIN and OVERLAY resoltion, i.e. 2 for
 > >      320x200 and 640x400 respectively.
 > >      SCALE is current requested picture scale. It never can be less
 > >      than RATIO, i.e. you can't switch to 1x for such games.
 > 
 > Which exactly are "such games" ?
puttdemo-win, puttputt-win, moondemo-win, puttmoon-win, fbdemo-win,
fbear-win, all those which have _heversion 70.

 > 
 > >   1. Scale MAIN buffer to requested SCALE with any requested scaler.
 > >   2. Scale OVERLAY by (SCALE/RATIO) with simple linear scaler. I.e. if
 > >      there is requested 3x SCALE, it will be scaled by 1.5x. I am not
 > >      sure either this is essential, but will be nice to have.
 > 
 > That sounds like yet another slow down :-/.
exactly, that's why I was talking about simple linear scaler. From the
other hand scaling for those games can be disabled at all, i.e. they
are just forced to work in original resolution.

 > 
 > >   3. Overdraw MAIN with OVERLAY using alpha mask.
 > 
 > And that, too. The current overlay system goes to great length to 
 > *avoid* using alpha masks.
Well, when I was writing that I had in my mind a simple 1-bit alpha
mask. I.e. either apply pixel or not.

 > > problem #3 with finer fonts will never be implemented, but at least
 >
 > For GUI rendering, fine, I am all for it. For in-game fonts: I don't 
 > like the idea to do anything like that for them
I agree with you here.

 > Please keep in mind that we have to support systems which only have a 
 > 320x200/8bit resolution.
We can't as they are not able to run those games anyway. That's the
whole point (I mean 320x200, not 8-bit).

 > or at least let us (porters, other develeoprs on the project) 
 > review the precise OSystem API changes you plan (i.e. tell us about the 
 > methods you want to add/change/remove and how they are supposed to 
 > work, so that one can better judge how to a) use them and b) implement 
 > them).
I was going to go by route you used for File object improvement. Come
with some API, write pseudo-code and push it to the devlist for
discussion.

As I understand, basically it will affect just SDL, X11 and Morphos
(is it still maintained?) ports as only being capable of rendering
640x480+. If PalmOS port someday will support bigger resolution
devices, then it will need be done for it as well.


Eugene




More information about the Scummvm-devel mailing list