[Scummvm-devel] SurfaceSDL-Backends and Scaler Plugins

John Willis John.Willis at Distant-earth.com
Tue Aug 14 21:32:38 CEST 2012


Hi Eric,

> I have read all the backend code and tried to make some specific
> suggestions for each.

Thanks, it's much appreciated that you took the time to dig through all this
code.
 
> All ports
> =========
> 
> The SurfaceSdl getSupportedGraphicsModes does runtime selection of
> available plugins. Defining s_supportedGraphicsModes is not needed
> anymore. Use configuration defines to enable the compilation and linking
> of the different plugins. Right now there are 4 states:
> 
> None of the below defined: Only the Normal plugin is used and it does 1x
> scaling only.
> 
> USE_SCALERS: All are enabled except HQ and Edge scalers.
> 
> USE_HQ_SCALERS: All enabled except Edge scaler. Requires above define.
> 
> USE_EDGE_SCALERS: All scalers enabled. Requires both above defines.
> 
> Similarly, setGraphicsMode(int mode) should no longer need to be
> overriden (or it can at least call the parent implementation after some
extra
> handling).

That is great; I can't say anything other than thanks for starting to clean
up of all this stuff. 
Without looking in too much detail I can see this being helpful for backends
that with to make use of OpenGL(es) optionally.

> Ports using GFX_HALF
> ====================
> 
> There is no GFX_HALF plugin. The scaler plugins could be extended for such
> a thing, or it could be handled as a special case (like it is now).
> There was discussion on scummvm-devel about possibly subclassing
> SurfaceSdl for GFX_HALF since it is common for 320x240 devices.
> 
> Let me know if there are any changes I can do to make this easier (e.g.
> how gfx modes are managed).

Sorry, LordHoto pointed me to your reply to my earlier -devel post, somehow
it never made my mailbox so I did not response at the time :(.
I'll read that and respond later.

> DINGUX, GPH, and LinuxMoto
> ==========================
> See notes on GFX_HALF. I do not see any other issues.

Agreed, even the GFX_HALF hacks are pretty much common to all of these so
I'll check them over on the GPH devices but I don't foresee problems looking
(quickly) at your branch.

> OpenPandora and Symbian
> =======================
> 
> These ports seem not to override much of surfaceSdl. They might be fine
> with only preventing certain plugins from linking and compiling.

Also not worried here, in the case of OpenPandora (one of mine) it is pretty
basic on the SDL graphics front and until I get the OpenGLes stuff into
shape for it, it will remain that way ;).

> WinCE
> =====
> 
> This is the most complicated port.
> 
> For high and low resolution devices, I would link all plugins that could
> possibly be used, but the normal plugin is guarenteed to be plugin 0. So
low
> resolution devices can default to mode 0. Otherwise, high resolution
> devices can switch plugins as they did before.
> 
> The special aspect + scaling functions (e.g. Normal2xAspect) do not have
> plugin counterparts. I would recommend either using the normal plugin and
> aspect correcting afterward (like the desktop), or treating them as a
special
> case (similar to GFX_HALF) especially if they offer necessary performance
> benefits on some devices.

It's been ages since I looked at the CE backend but for what it is worth I
tend to agree.

At least until there is a wider talk on the GFX_HALF and we can maybe look
at applying it to the other CE tweaks. You will find that just about all the
'special' scale/aspect codepaths in the CE port exist for performance
reasons.

Regards,

John






More information about the Scummvm-devel mailing list