[ scummvm-Patches-1013937 ] OSystem layers with bigger resolution

[SourceForge.net]

Patches item #1013937, was opened at 2004-08-22 23:16
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=418822&aid=1013937&group_id=37116

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Eugene Sandulenko (sev)
Assigned to: Nobody/Anonymous (nobody)
Summary: OSystem layers with bigger resolution

Initial Comment:
Here I present OSystem change which were mentioned some
time ago on the devlist.

It lets us to have that layer where cursor and menus
live use 2x or 3x bigger size than original resolution.
As it was discussed, it gives us possibilty to have
640x400 in-game interface as well as launcher.

It runs perfectly with 1x scale, i.e. with currenlty
implemented behaviour and also it requires just one
small change to backends which aren't going to
implement it. All other functions have default
implementation which runs layer in 1x mode.

Basically it adds another surface with keycolor
transparency, draws cursor there, and works with GUI as
former _tmpscreen, i.e. no changes to current gui code
were made to make things run.

Thing gets turned on when showOverlay() is called. In
this mode mouse events are generated in overlay space,
i.e. 640x400 for 2x overlay.

OSystem changes:
 o initSize gets third parameter (default to 1), which
specifies overlay 
   scale factor. Currently overlay works only for
320xYYY modes, i.e.
   in 640x480 its scale is always 1. This is the only
change which
   has to be implemented for other backends, but its
value could be
   safely ignored there.

 o OverlayColor overlayKeyColor(). Returns transparent
color of the
   overlay. Is not used now, but may be if you want to
draw holes.

 o int Scr2Ovl(x) and int Ovl2Scr(y). Functions which
convert 
   coordinates between game and overlay. I.e. if you
want to draw
   something on overlay but align it with game screen,
use those.

 o void cursorScaled(bool scale). If called with true
(default), then
   cursor is always scaled to match current scale
factor, i.e. it
   becomes bigger as in current implementation. When it
is called
   with false, then cursor is used as is. It is used
with HE 7.0 games
   which ran in scaled 320x200 with cursors designed
for 640x480.
 
Also this patch introduces GF_UNSCALED_CURSORS which is
set for HE 7.0 games.

I run launcher as well as all 320x200 SCUMM games with
2x overlay. As current GUI is 320x200-specific, it
spans only on 1/4th of the screen, but this is out of
this patch scope :).

This patch has some flaws:
 o It uses 1.5x scaler when user requests scale to 3x
with 2x 
   overlay, I wrote quick and dirty implementation of
it, so it has to
   be replaced with something more nice looking.

 o It obviously restricts scaling for rates lesser than
overlayscale, i.e.
   for 2x scaler you cannot switch back to 320x200. But
if you have
   some 1x scaler specified in your ini file, it
doesn't avoid that and
   crashes. This has to be fixed in main.cpp

 o For same reason when you try to start 640x480 game
with 2x
   overlay from launcher, runGame() tries to switch to
GFX_NORMAL
   before the game engine calls initSize, and this leads to
   crash. It is design flaw in current implementation,
and probably
   such engines should check scale by themselves and call
   initSize appropriately.

 o When overlay is visible, it copies game screen and
uses it as an
   eyecandy by providing interface shadows. As there is
1.5x scaler
   introduced, simple scalers are used to produce
shadows. There
   could be added some brains to call, say HQ2x in HQ3x
mode,
   but I'm not sure is it really necessary.

 o now showOverlay() and hideOverlay() functions change
their 
   meaning and could be renamed to activateOverlay() and 
   deactivateOverlay() or some better names. I didn't
do that in the
   patch.

 o We could introduce kFeatureScaledOverlay or
something to 
   denote backends which support overlaying and fall
back to 1x
   if they're not. But getOverlayHeight() could be used
for that as
   well.

 o Cursor jumps when user switches resolution. But it
works in
   same way in current implementation, just becomes more
   obvious with this patch. It definitely has to be fixed.

Your feedback/critique/whatever is more than welcome.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=418822&aid=1013937&group_id=37116