#1997 closed defect (fixed)
GUI: Mouse drawn at wrong position in overlay mode
| Reported by: | fingolfin | Owned by: | fingolfin |
|---|---|---|---|
| Priority: | normal | Component: | GUI |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
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 location.
Ticket imported from: #1184616. Ticket imported from: bugs/1997.
Change History (9)
comment:1 by , 20 years ago
comment:3 by , 20 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 , 20 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 , 20 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 , 20 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 screen.
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 , 20 years ago
| Owner: | changed from to |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
comment:8 by , 20 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 , 6 years ago
| Component: | --Unset-- → GUI |
|---|
It does seem to work correctly with the --force-1x-overlay option, though, so it has to be something with the scaling.