[Scummvm-devel] Moving platform specific (down)scalers into the core of ScummVM

John Willis John.Willis at Distant-earth.com
Thu Jul 30 12:14:40 CEST 2009


Hi Max/All,

> [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 ;)
> ]

Could not agree with that more :). 

So who is up for having a go at this with me, any volunteers :).

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

I agree it is absurd when viewed in a desktop context but since when has use
cases and intelligence ever been something that has any relation to one
another. I can think of other cases where it 'may' be relevant on a desktop,
TV out for instance but coming up with compelling cases is a non-starter ;).
I'll let users come up with that.

I'll take the comments onboard and see what I can come up with, maybe start
pushing some small patches up to the tracker at some point to see what the
consensus is (the usual 'work commitments aside' applies).

Cheers,

John






More information about the Scummvm-devel mailing list