[Scummvm-devel] Moving platform specific (down)scalers into the core of ScummVM
Max Horn
max at quendi.de
Thu Jul 30 11:29:08 CEST 2009
Hi again,
first off: Yeah, maybe "small devices backend" should become "small
screen backend"... or not... The name is not so important in my eyes.
In fact, to me the SDB always was more of a meta-level thing, a
concept, not necessarily something that has to be implemented
explicitly as one single backend. The idea always was to provide as
many useful generic components as possible to backend authors -- as
long as it makes sense, at least.
[Side remark:
One part of that meta level goal always was to make the SDL backend
easier to subclass. For example, it would be a nice thing to split the
single monolithic event handler function in the SDL backend, by adding
several handleMouseDown, handleKeyDown etc. callbacks (similar to our
GUI code), which do the actual work. That way, new ports can easily
insert say an alternate hotkey -- they only have to overload a single
method (and can still invoke the original implementation of it, too),
and don't have to copy all the other identical code in the event
handler. It also would allow getting rid of the alternate strategy
porters employed to customize the hotkeys: Nameley, scattering tons of
#ifdef's through OSystem_SDL::pollEvent ;)
]
You ask whether it makes sense to subclass the SDL backend for
downscaler support, citing systems that just use the plain vanilla SDL
backend which still want to use downscaling...
Well, those systems could be switched use the plain vanilla SDL_small
backend, too, so this seems like a minor point to me.
Of course you could now argue that users might want to use downscaling
even on a desktop machine. While I consider that absurd, it might
indeed be helpful for testing purposes to be able *as a developer* to
use a downscaler.
So, I am not opposed to add downscaling to the SDL backend itself.
*If* this doesn't complicate the backend too much. That's a big "if"
in my eyes. But if that can be achieved, why not.
Cheers,
Max
More information about the Scummvm-devel
mailing list