[Scummvm-devel] PORTERS/ENGINES: Backend graphics handling improvements
Johannes Schickel
lordhoto at gmail.com
Fri Oct 3 12:23:38 CEST 2008
Hi,
some of you might have seen my patch tracker item #2123680 "SDL: Backend
transaction / rollback support"
(http://sourceforge.net/tracker/index.php?func=detail&aid=2123680&group_id=37116&atid=418822).
It implements proper rollback via our gfx transaction support in the SDL
backend. To achieve that some things changed:
Affecting client code:
- setGraphicsMode has now to be called inside transaction block
- when enabling aspect ratio correction and/or fullscreen via setFeatureState
the client code has to call it inside a transaction block
Affecting SDL backend subclasses:
- behavior of various backend functions changed:
-> loadGFXMode is only called from endGFXTransaction and hotswapGFXMode now
-> setFullscreenMode and setAspectRatioCorrection changed to only update
transaction details
-> setGraphicsMode now only updates transaction details, for enabling the
scaler the newly introduced setGraphicsModeIntern has to be used
-> loadGFXMode now returns a bool to indicate success or failure
-> on failure endGFXTransaction will fall back to the old mode
Affecting other porters:
- They might think of assuring setGraphicsMode and setFeatureState is used in
the same way as in the SDL backend, means it should only be allowed inside a
gfx transaction block. If your backend does not have gfx transaction support
you don't have to worry about that though.
----------------------------------------------------------------------------------------------
General Questions:
Since endGFXTransaction does fall back to the *old* video mode instead of
crashing in the SDL backend it should return some error flag(s). I personally
would seperate between non important errors here (like failure to enable
aspect ratio correction should not really stop client code from working
properly, same goes for scaler change IMHO) and important errors like when it
fails to setup a new screen size. An example for the latter: a game wants to
use 640x480 and the backend is not able to set it up properly, now SDL
backend would fall back to the old video mode, which might be 320x200, thus
client code needs to be informed about it.
Now is the question on what porters and engine authors think of it:
- Which errors should be reported?
- How should error reporting be handled?
-> Via a ORed flag list in endGFXTransaction?
--> This is of course bad for backends without gfx transactions, since
they only supply a dummy endGFXTransaction function
-> A new queryGFXError method?
-> Any other idea?
- Which are minor errors, which are important ones?
Related to that: the SDL implementation in my patch will fall back to the old
video mode even when it fails for only IMHO minor problems like scaler,
aspect ratio failure or fullscreen setup.
That is of course bad when the client code would setup a new size + aspect
ratio correction in one gfx transaction block. If it would fail because of
aspect ratio correction, the size transaction would be simply lost.
In my opinion the backend should then try to revert aspect ratio, fullscreen
and/or scaler changes first and the last try should be to revert the size
change and report a proper error according to what failed to change.
// Johannes
More information about the Scummvm-devel
mailing list