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

John Willis John.Willis at Distant-earth.com
Thu Jul 30 11:12:37 CEST 2009


Hi Max,

You managed to make some semblance of my drivel, a rather impressive feat.

> several backends need downscalers, and would benefit from ARM
> optimized versions of those (and might even benefit from carefully
> optimized C/C++ versions, for that matter). So it  certainly makes
> sense to have some of those in graphics/scalers -- at least as long as
> they are only compiled on ports that want them. (Which is easy enough
> to achieve). In particular, yes, downscalers are useful.

Agreed, I think my whole mail would have made more sense if I had just used
the term 'SDL derived backends' but glad to see you have no inherent issues
with this type of code going into the core anyway.

> Actually, we listed this a long time ago as one of the desirable
> features for the ominous "small devices meta backend", see
> <http://wiki.scummvm.org/index.php/Small_Devices_Backend
>  > ;).

Yep, my only reason for not directly referring to the Small Devices
Metabackend was that I did not want to get bogged down in the rest of it.

That said, the more I think about it the more that 'do it once, do it right'
seems to apply. I keep skirting around it as I don't want to commit myself
to doing it all ;).

I also have a slight issue with the relevance of the Small Devices
Metabackend (in current thinking) in our codebase as increasingly our 'Small
Devices' are anything but in terms of raw power and capabilities. Small
Screen Devices may be a better term (and just initially deal with the render
pipeline?) as the really small devices (NDS, older Plam's) have their own
backends anyway. Still, that is going off on a tangent.

> The other issue is how to make it as easy as possible for backends to
> use downscalers; i.e. how to interface with them, what API to use. For
> a stand-alone backend, such as the NDS one, this is probably not
> really an issue. Most of your questions seem to be only relevant to
> backends that are based on the SDL backend and wish to reuse as much
> of its code as possible; in particular, those backends ideally would
> like to just tell the SDL backend to use a downscaler and be done with
> it. As you already pointed out, the SDL backend is not well prepared
> for this.

Yep, I can think of a few 'dirty hacks' to OSystem_SDL to get this in
quickly (Ugly 'scale direction' flag ;)) but they are not really ideal other
then proving points.

> So, we could try to adapt the SDL backend to deal with that. But I
> think that would make an already overly complicated rendering pipeline
> even more complicated... So maybe here's a good opportunity to
> introduce a OSystem_SDL_SmallDevice subclass, which provides a
> graphics pipeline custom tailored towards downscaler mode...  That
> might help to keep the code clean, and would still allow backends
> derived from it to use both up- *and* downscaling (the backend can
> choose whether it invokes the OSystem_SDL or the
> OSystem_SDL_SmallDevice renderer). Alternatively, this functionality
> could be added directly into the SDL backend.

The only slight issue with keeping it subclassed from OSystem_SDL is how we
could get the benefit of these features to platforms/distributions like
Angstrom that just use OSystem_SDL 'as is' without any (or very few) tweaks
to our codebase to tie to unique platforms.

Angstrom is just an example of a target we support in Configure and is
relevant in that it mostly targets embedded systems often with constrained
screens. The vast majority of these devices would happily downscale larger
surfaces using the existing ARM or C/C++ half scaler if given an option (GUI
or detected at a combination of runtime and compile time based on the
presented hardware). This leaves me wondering if the subclass is the way to
go. 

It's more of an open question as I really don't have an answer ;). Just
pondering how to make sure any work gets the widest exposure.

> As for the overlay: I think on *any* port, whether it is SDL based or
> not, the overlay should ideally be unscaled, i.e., use the native
> screen resolution. At least in theory -- in reality, we don't define
> themes for resolutions beyond 640x480, and while our GUI is vector
> based, the fact that we don't use vector fonts means we can't scale it
> arbitrarily without custom themes... So, in the real world, if your
> native screen is around 320x200 or 320x240 or 640x480, use that
> natively for the GUI; if it's bigger, then use an overlay size close
> to 640x480.

That makes good sense, that was my understanding of how we treat the overlay
but good to know for sure that I was not missing something.

Well I treat it slightly differently in the old GP2X backend but that's a
hangover of the devices hardware scaler seeming inability to mix scaled and
native resolution surfaces without glitching.

Cheers,

John






More information about the Scummvm-devel mailing list