[Scummvm-devel] SDL scaler refactoring

[Eugene Sandulenko]

Hi Phil,

Sorry about late reply.


On Mon, 02 Aug 2010 22:40:03 +0100
LionsPhil <lionsphil at gmail.com> wrote:
> The current way scalers are implemented in SDL seems to be rather
> deeply entangled with the backend as a whole
Indeed.

> I propose that it might be better to refactor the scaling operations
> out to an appropriate Scaler class which has virtual member functions
> for performing game/hardware co-ordinate transforms, as well as the
> actual graphical manipulation
Sounds fine. Also this could potentially be turned into plugins and
thus we could add more scalers.

> I'm hoping this'll stimulate some discussion with the people more
> deeply familiar with the SDL backend, but as a starting point my plan
> of attack would be (the backend should be left in a working state
> inbetween each complete step):
Note that pretty soon we will be merging this year GSoC task which adds
heavy refactoring to SDL backend.

> I believe the mouse
> layer should always be on the same co-ordinate system as one or the
> other?
Not necessarily. With current implementation GUI overlay always matches
window resolution, thus mouse maps 1:1, whereas game overlay has fixed
resolution specified by the engine, and requires mapping.

>   - Migrate the scaler functions into classes. Instead of setting 
> [new]scalerProc and [new]scaleFactor, the switch blocks of 
> setGraphicsMode and setGraphicsModeIntern would construct an instance
> of an appropriate Scaler subclass. scalerProc is converted from a
> function pointer to a virtual method call, and scaleFactor is set to
> a value returned by scalerobject->scaleFactor().
A thing to resolve is mapping scalers to the keys. Perhaps it is
another good task for our (not yet finished) keymapper.

>   - Migrate mapFooToBar methods from OSystem_SDL to the Scaler class, 
> and change calls appropriately. Determine the desired screen
> resolution in loadGFXMode() by querying the Scaler object. Remove
> scaleFactor from OSystem_SDL and the Scaler class.
Sounds good.

> This also allows us to implement scalers with non-integer and
> variable scale factors, without forcing floating point upon
> everything (as keeping scaleFactor public would).
These days we have Ratio class which should be used instead of FP
arithmetic where possible.

> A future development to this may be allowing Scalers to handle their
> own 200->240 correction, to avoid a second pass. For example, if 
> StretchToFit were a simple nearest-neighbour sampling aiming for
> sharp pixel boundaries, it could avoid the resampling performed by 
> stretch200To240().
Yes. You may consider doing this in a scaler superclass with a virtual
method which could be overridden in your StretchToFit class. I.e. the
main problem is that current scalers cannot handle ratio scales, i.e.
1.2x which is used for aspect correction.

> So, if you've read through all this, thoughts? :)
Really good.


Eugene