[Scummvm-devel] RFC: overlays extension to OSystem

[Max Horn]

Am 29.06.2004 um 14:55 schrieb Eugene Sandulenko:

> Hi dev'ers,
>
> here I would like to present my request for comments of one quite
> noticeable extension to OSystem.

Which means that we should first get feedback from as many porters as 
possible to learn how it'll affect them. Marcus already replied; but 
will PalmOS/WinCE/etc. backends be affected? Can they implement the new 
system, is it easier or harder than the old overlay code etc? That 
should be checked.

[...]

>
> All these problems exist because we always render on same virtual
> screen buffer, then scale it blindly and throw to renderer.
>
> So I propose to implement how I call it, overlayed rendering.
>
> Basically we will have two buffers instead of current one, and have
> 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.

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).

>
> Then rendering pipe will look like this:
>
>   0. MAIN is main buffer with gameplay picture
>      OVERLAY is additional buffer with bigger resolution. It has alpha
>      mask. Usually it will contain cursor, text or whatever.

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, though (that way, the cursor shapes as set by games, would 
be scaled, while e.g. the GUI code could provide hires cursor). But 
that's only a gimmick and not strictly needed.


>      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" ?

>   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 :-/.

>   3. Overdraw MAIN with OVERLAY using alpha mask.

And that, too. The current overlay system goes to great length to 
*avoid* using alpha masks. While alpha masks are very attractive for 
the "end user" (i.e. the coder using OSystem, as opposed to the coder 
writing the backend), it is very annoying to support them on our 256 
color targets.



>   4. Feed it to renderer.
>
> Basically it will let us address all above problems, well, maybe
> problem #3 with finer fonts will never be implemented, but at least
> will be possible to do it easily. To implement it, all text-drawing
> calls should be directed to OVERLAY with coordinates transformed to
> match its resolution.

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 (unless the particular 
game already uses vector fonts, which AFAIK none of our games do).

>
> Also OVERLAY may have feature of dynamic resizing, so when user
> switches to bigger resolution, it will use finer fonts for rendering.
>
> So what do you think about it?
>

Please keep in mind that we have to support systems which only have a 
320x200/8bit resolution. I don't mind offering additional features for 
systems with more graph res, but it shouldn't cause crippling to other 
backends. As long as that is ensured, I don't have any fundamental 
objections. Since this is a very big change you propose, I'd recommend 
that you do not make hasty commits, though. Going with a patch might be 
safer; 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).

Cheers,

Max