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

[John Willis]

All,

Sorry for the rambling mail below, it's a bit of a sleep deprived brain
dump.

Recently I committed code to the GP2XWiz backend in Trunk (not sure if I am
going to backport it for 1.0.0 yet) to make use of one of the software
downscalers (r42863) that up until now has been confined to the WinCE
backend.

To do this I wrapped the WinCE implementation (PocketPCHalf/PocketPCHalfARM)
into a new scaler called HalfScale that only exists in the Wiz backend. 

This serves the simple purpose of letting me downscale 640*4xx games to
320*2xx on the fly and actually works very well thanks to Robin Watts ARM
assembly version of the scaler (the C implementation also works but is much
slower).

In order to do that I added another ENUM value for GFX_HALF and try and
treat the local scaler as if it was one provided by ScummVM's core with a
few hacks here and there to deal with downscaling rather then upscaling
(keeping the overlay unscaled at 320*2xx for instance) and stuff such as
pixel format passing.

While the code I have committed works (just) and is not invasive to other
backends (well other than giving the Wiz a dependency on wince/ARMscaler.s)
it did get me thinking about the merits of moving some of these platform
specific downscalers into  /graphics/scalers at the very least and ideally
talking to them in a much more generic manner so that any backend can
'ab'use.

---

Hence the point of this mail, ideas, input (and ridicule ;-)) from the team.

A number of points:

* Historically ScummVM 'scalers' actually tend to mean upscalers and some of
our design seems to support that.

* Are downscalers actually useful? 
 
 I would say yes, WinCE uses them, GP2XWiz uses them now and I know of a few
others handheld console ports that I am trying to get authors to put on the
tracker that could make use of them (both pure C and ASM implementations).

* If we start to add downscalers how will we deal with the minimal invasion
of existing code?

* Do we decouple to the overlay from the downscaled game surface (as I think
WinCE does and I do with the GP2XWiz?)

 This is one area that needs some thinking about, in SDL we tie them
together and a lot of ports slave as much to the SDL backend that they can
get away with.

* Can we make all the downscaler functionality definable, maybe separate
from upscale scalers (chances are, if a platform needs a downscaler its not
going to need an upscaler but that may not always be true, 800*600 and
320*2xx games on a 640*480 device in the future maybe?)

I actually think the work need not be that major (famous last words) but it
would require involvement of a most porters (or at least a consensus) and
some design steering from the core team. As it is well outside of my area
it's not really my place to try and push a specific design/idea for selfish
reasons.

I am happy to do a good chunk of the lifting if people think this idea has
merit as long as we do not have to hit any specific timescales ;-).

Regards,

John

--

> What is a grue?

The grue is a sinister, lurking presence in the dark places of the earth.
Its favourite diet is adventurers, but its insatiable appetite is tempered
by its fear of light. No grue has ever been seen by the light of day, and
few have survived its fearsome jaws to tell the tale.