Opened 12 years ago

Closed 6 years ago

Last modified 5 years ago

#6059 closed defect (outdated)

SDL: Mouse sticky to bottom and/or right border

Reported by: SF/robertmo Owned by: csnover
Priority: normal Component: Ports
Version: Keywords:
Cc: Game:

Description

mouse sticky to bottom border

WinXP-32bit Win7-64bit Win32 ScummVM Daily Snapshot (build from repository, 6521K Win32 exe file, last update: June 24, 2012, 12:25 am) Provided by ScummVM Team member Travis 'Kirben' Howell, updated several times daily

mouse sticky to bottom border. Up, right and left borders are ok move your mouse to bottom border and some more and it will take a bit more to move it back(distance of cursor size i guess) (guess it has something to do with mouse cursor not hiding behind bottom and right borders in this game) it happens only in fullscreen and can be fixed by ctrl-alt-a (if you switch to window and back to fullscreen again it will happen again - though it happens only with aspect off (default) )

Ticket imported from: #3537524. Ticket imported from: bugs/6059.

Change History (20)

comment:1 by wjp, 12 years ago

Summary: mouse sticky to bottom borderSOLTYS: mouse sticky to bottom border

comment:2 by Strangerke, 12 years ago

Owner: set to Strangerke

comment:3 by digitall, 12 years ago

Tried to replicate this by building git master on MinGW on Win32. Can't replicate.

comment:4 by SF/robertmo, 12 years ago

i said the problem is in Daily Snapshot. I have no idea how "git master on MinGW on Win32" behaves as i don't have it. So maybe say whether you can or cannot reproduce the bug in Daily Snapshot too to remove the confusion.

comment:5 by digitall, 12 years ago

Strangerke: Ah, have worked out what robertmo means here and have replicated. The issue is a small variation of the mouse behaviour compared to running the original interpreter. In that you can move the mouse to beyond the visible screen, but in ScummVM, the mouse cursor is jailed within the visible screen window with it's full width and height.

This is mostly visible when the OS pointer is moved outside the window to the right or bottom side, and then moved back. The cursor fails to move until the OS pointer is at the hotspot (in the top-left corner of the cursor shape)... which is a bit wrong.

Fixing this should be possible, though you will need to be careful that drawing partial cursor/outside of visible screen area doesn't cause memory bugs etc... Up to you.

comment:6 by SF/robertmo, 12 years ago

I have to correct that mouse cursor shouldn't hide beyond right or bottom border in this game. Compare in DOSBox. (no hiding on real computer too). This game is unique in this matter. (same behavior in game The Patrician)

comment:7 by digitall, 12 years ago

Confirmed in DOSBox as well. I can't really observe any difference, except possibly that DOSBox is warping the OS pointer to the Cursor hotspot on window entry... But robertmo has said that this is not the issue he is observing.

Unless the issue can be explained clearly i.e. maybe a youtube video or similar, so it can be replicated, I doubt this bug can be progressed.

comment:8 by SF/robertmo, 12 years ago

Component: Engine: CGE
Game: Soltys
Owner: Strangerke removed
Summary: SOLTYS: mouse sticky to bottom borderSCUMMVM: mouse sticky to bottom border

comment:9 by SF/robertmo, 12 years ago

ok it happens not only in soltys but also in indiana jones fate of atlantis (mouse cursor is hiding behind bottom border) And i have a feeling it hapens in pure scummvm launcher too - it takes more time to move mouse back from bottom than it should. I will investigate more.

comment:10 by SF/robertmo, 12 years ago

Indiana jones and fate of atlantis is best for testing as it hides mouse cursor behind border when bug is unleashed. It happens with usb and ps2 and com mouse too. I figured out it has something to do with black fields surrounding image. It happens with gfx type 3x for right border too. (same with no scaling). When i manually add 640x400 resolution in my nvidia's control panel there are no black borders at top and bottom with default scummvm gfx type - hence no bottom bug. So when testing make sure black fields appear as the bug won't happen if you don't have black fields (columns or horizontal stripes)

comment:11 by SF/robertmo, 12 years ago

same problem happens on win98se voodoo3

comment:12 by SF/robertmo, 12 years ago

Summary: SCUMMVM: mouse sticky to bottom borderSCUMMVM: mouse sticky to bottom and/or right border

comment:13 by lordhoto, 12 years ago

Do you use "desired_screen_aspect_ratio" in your ScummVM config file?

comment:14 by lordhoto, 12 years ago

Summary: SCUMMVM: mouse sticky to bottom and/or right borderSDL: Mouse sticky to bottom and/or right border

comment:15 by SF/robertmo, 12 years ago

i wasn't changing anything from default

comment:16 by lordhoto, 12 years ago

I take it you don't use the "desired_screen_aspect_ratio" setting then?

Also where do you get black borders? Only on the bottom and right? Or is the game screen centered and there's black borders all round it?

comment:17 by SF/robertmo, 12 years ago

[scummvm] aspect_ratio=false

game is centered and black border is all round (when the problem is for right and bottom) When the problem is with bottom only black is only on top and bottom.

comment:18 by lordhoto, 12 years ago

This sounds like SDL's internal behavior, which picks a larger resolution, when the desired isn't available and then centers the game screen. The mouse issues you are seeing might be a result of SDL not handling this like you would expect it. But it's still odd that it doesn't apply for the top and left borders.

Our own screen aspect ratio force code in the SDL backend definitly doesn't handle this properly. But it will only add black borders to the right and bottom, i.e. it doesn't center the game screen. And of course you need to use "desired_screen_aspect_ratio" to enable this. So this shouldn't be an issue for you.

At any rate, this might be a problem with SDL, since as pointed out this is not an issue, in case there won't be black borders and we really don't know if SDL picked a bigger resolution for fullscreen (AFAIK). Maybe someone should check through known SDL problems.

comment:19 by csnover, 6 years ago

Owner: set to csnover
Resolution: outdated
Status: newclosed

This is not a problem with SDL2 and the new graphics manager code.

comment:20 by digitall, 5 years ago

Component: Ports
Note: See TracTickets for help on using tickets.