[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