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

[John Willis]

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

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.