[Scummvm-devel] Mouse cursor surface scaling when using GFX_HALF.

[Eric Culp]

On 07/29/12 18:13, John Willis wrote:
> I thought I would post this to -devel as I suspect this applies to more than
> just one of my backends so I don't just want to commit a quick backend
> specific fix.
>
> While looking into a recent bug report in the GPH backend
> http://goo.gl/CbbnC I noticed that mouse cursors are not being downscaled
> when the backend uses GFX_HALF to downscale - When we go from 640*4xx to
> 320*2xx). This in itself is not much of a problem but it also seems to lead
> to clipping on the edges of the mouse surface where calculations are a
> little off so ugly graphics glitches and trails.
>
> It does not seem to happen in all engines, it's quite easy to spot in scumm
> and sword1+2 but tinsel seems fine for example. I have not yet looked into
> the engine side of the code as I don't think that is relevant to a decent
> fix anyway but I assume engines handle the cursor draws in different ways.
>
> Looking at the backend code it seems fairly obvious where the problem might
> be (setMouseCursor/blitCursor) as none of the mouse surface code copes with
> the concept of a downscaler. In fairness, we never really implemented a
> bidirectional scaling model anyway.
>
> But before I just overload those methods for the GPH backend and hackup a
> fix it struck me that as a few other backends use GFX_HALF as an internal
> downscaler  (dingux, linuxmoto off the top of my head) so probably suffer
> also the same problem.
>
> Therefor a fix that touches surfacesdl may be a little more appropriate but
> there is no way I am committing something like that until I at least verify
> the problem applies to other backends using GFX_HALF as I know my luck and
> I'll kill someone else's backend ;).

My GSoC project for scaler plugins might be relevent to this. Right now 
it only exposes an API for integer scaling. How useful would a more 
general API be for including downscaling or possibly aspect correction?

I can think of a few things.
Pros:
	* This class of bugs would be easier to avoid if all scale factors were 
rational numbers.
	* Individual backends might be able to do less overriding if surfacesdl 
handled all the various scalers "out of the box".

Cons:
	* All backend code would have the added complexity of dealing with 
rational numbers or somehow detecting non-integer scaling.
	* Adds complexity to systems that would not really benefit ...
		* We would only have one downscaler or AR correcter in a build. 
Flexibility gained by wrapping with plugins would not be taken advantage of.
	* There are just a few special cases, it might not be bad to treat them 
specially (Although a fix implemented in surfacesdl would probably be best).

I would like to hear if there is any interest in this (especially from 
porters).


Thanks,
Eric Culp (singron)