Opened 15 years ago

Closed 15 years ago

Last modified 13 months ago

#1997 closed defect (fixed)

GUI: Mouse drawn at wrong position in overlay mode

Reported by: fingolfin Owned by: fingolfin
Priority: normal Component: GUI
Keywords: Cc:


Even with latest CVS, the mouse cursor is not drawn in the right
position when the overlay mode is active, i.e. the GUI is on. (Talking
about the SDL backend).

To notice what I mean, go to any GUI dialog, e.g. the launcher.
Make sure scaling is active. Aspect ratio correction doesn't matter.
Now move the mouse all the way to the top -- the drawn cursor will
stop a few pixels before it reaches the top.

To prove that the cursor doesn't match up with the actual mouse
position, just move the cursor over something that has a "hover"
effect, e.g. the scroll bar in the launcher. You'll notice that the center
of the "cross" does not match up with the actual mouse cursor

Ticket imported from: #1184616. Ticket imported from: bugs/1997.

Change History (9)

comment:1 by eriktorbjorn, 15 years ago

It does seem to work correctly with the --force-1x-overlay
option, though, so it has to be something with the scaling.

comment:2 by eriktorbjorn, 15 years ago

Could it simply be an error in the scaling of the mouse
cursor hotspot?

comment:3 by sev-, 15 years ago

yes, it should be mouse scaling code and most probably
hostpot calculation. maybe sapect correction there is always
applied or applied twice.

comment:4 by fingolfin, 15 years ago

The problem actually also affects the x-axis. Since it happens regardless
of the aspect ratio correction, I don't think that it is related to that...

comment:5 by eriktorbjorn, 15 years ago

It's because it affects both the X and Y ax... well,
whatever axis in plural is, that I suspect hotspot
calculation. In particular, I'm suspicious about this code
in drawMouse():

dst.x = _mouseCurState.x - _mouseHotspotX / _cursorTargetScale;
dst.y = _mouseCurState.y - _mouseHotspotY / _cursorTargetScale;

Perhaps that offset calculation should also involve
'scale2', which is 1 in normal mode and _overlayScale in
overlay mode. From what I understand the cursor has been
scaled to work with the overlay, but the hotspot has not.

Which, when you stop to think about it, is a bit odd because
the overlay cursor will look different if you play a 640x480
game than if you play a 320x200 game.

comment:6 by fingolfin, 15 years ago

This code is quite convoluted <sigh>.

From what I understand, _mouseCurState is in "game"
coordinates -- e.g. 320x200 limited, no scaling/aspect ratio
applied (or rather, they were un-applied :-).

OTOH, the _mouseSurface is in real screen coordinates --
640x480 if 2x scaling and AR are active for a 320x200 game

Now, subtracting the hotspot from that should be correct if
one wants to compute the top-left corner of the cursor rect
in game coordinates (I am not worrying about the
_cursorTargetScale yet).

But we then later scale this rect -- but that seems wrong to
me, because it means we are now using the top left corner of
the cursor as the center for our scaling. We really want to
use the middle of the cursor.

comment:7 by fingolfin, 15 years ago

Owner: changed from sev- to fingolfin
Resolution: fixed
Status: newclosed

comment:8 by fingolfin, 15 years ago

Fixed in CVS, as per Erik's suggestion. The code still is... tough. Would be
nice if we could simplify the whole affair somewhat, but I guess with all
those different scales being applied, it never will be easy :-/

comment:9 by digitall, 13 months ago

Component: --Unset--GUI
Note: See TracTickets for help on using tickets.