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.
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.
Ticket imported from: #1013937. Ticket imported from: patches/458.
Change History (47)
comment:2 by , 16 years ago
|Summary:||OSystem layers with bigger resolution → OSystem layer with bigger resolution|