OSystem layer with bigger resolution
|Reported by:||sev-||Owned by:||fingolfin|
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.
o initSize gets third parameter (default to 1), which
scale factor. Currently overlay works only for
320xYYY modes, i.e.
in 640x480 its scale is always 1. This is the only
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
o int Scr2Ovl(x) and int Ovl2Scr(y). Functions which
coordinates between game and overlay. I.e. if you
want to draw
something on overlay but align it with game screen,
o void cursorScaled(bool scale). If called with true
cursor is always scaled to match current scale
factor, i.e. it
becomes bigger as in current implementation. When it
with false, then cursor is used as is. It is used
with HE 7.0 games
which ran in scaled 320x200 with cursors designed
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
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
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
overlay from launcher, runGame() tries to switch to
before the game engine calls initSize, and this leads to
crash. It is design flaw in current implementation,
such engines should check scale by themselves and call
o When overlay is visible, it copies game screen and
uses it as an
eyecandy by providing interface shadows. As there is
introduced, simple scalers are used to produce
could be added some brains to call, say HQ2x in HQ3x
but I'm not sure is it really necessary.
o now showOverlay() and hideOverlay() functions change
meaning and could be renamed to activateOverlay() and
deactivateOverlay() or some better names. I didn't
do that in the
o We could introduce kFeatureScaledOverlay or
denote backends which support overlaying and fall
back to 1x
if they're not. But getOverlayHeight() could be used
for that as
o Cursor jumps when user switches resolution. But it
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.
Ticket imported from: #1013937. Ticket imported from: patches/458.
Change History (47)
comment:2 by , 15 years ago
|Summary:||OSystem layers with bigger resolution → OSystem layer with bigger resolution|