[Scummvm-devel] RFC: overlays extension to OSystem

[Marcus Comstedt]

Eugene Sandulenko <sev at scummvm.org> writes:

> Proposed solution:
>
> 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.
>
> 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.
>      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.
>   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.
>   3. Overdraw MAIN with OVERLAY using alpha mask.
>   4. Feed it to renderer.


Add a separate (translatable) layer for the cursor, and you get how
the Dreamcast backend already does things.  :-)  (Except that the
overlay and main always have the same scale factor currently, and also
the cursor since people were complaining that the cursor was too big
in CoMI...)

I don't think there is any reason to require that the cursor lives in
the overlay; as far as the engine is concerned the cursor should be on
top of both the MAIN and OVERLAY buffers, and then it's up to the
backend how to implement it.


  // Marcus