[Scummvm-devel] PORTERS/ENGINES: Backend graphics handling improvements

Max Horn max at quendi.de
Thu Oct 16 19:33:37 CEST 2008


Am 03.10.2008 um 12:23 schrieb Johannes Schickel:

> 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:

[...]

I somehow doubt you'll ever get feedback on this from any porter,  
unless you go ahead and implement it and cause some pain to one of  
'em... :)


> ----------------------------------------------------------------------------------------------
>
> 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)

Agreed.

> 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?

Anything that makes it impossible for the client code to continue  
working is a serious error. Which is right now probably only the  
screen size. Anything else should be cosmetical. Ideally, an engine  
would detect if there was a failure to set up its desired screen size,  
put up an error, and quit / return to the launcher (alternatively, it  
could return a suitable error code and we display a common error  
dialog for it; in base/main.cpp, we then would have to check the  
return value of runGame()).

>
> 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.

Yeah... It should try anything to provide the requested screen size,  
treating all other requests secondarily. It then should return an  
error value which indicates: all OK; disastrous failure; partial  
success (e.g. screen size set fine, but ASR was not set correctly).

Bye,
Max




More information about the Scummvm-devel mailing list