VOGONS

Common searches


Reply 100 of 156, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

gulikoza, I hope this is your lucky day. I finally encountered a mouse-related problem and fixed it. Unfortunately, I haven't tested my change on windows yet (and I don't provide a windows DLL this time), because my windows development environment got trashed. I'd be very grateful for someone to test my change on win and send me a DLL which I can provide as 'official' DLL.

Download location as usual.

Reply 102 of 156, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

yup...this seems to fix the "stuck" cursor problem I've been having. But introduces another problem - mouse speed now depends on the scaling factor: x2 scaling -> 1/2 mouse speed. Can this be easily fixed? I've looked at the code but I don't have a slightest idea what to look for... 😜

Reply 103 of 156, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

Yes, well... cursor speed is supposed to be like that. It is most apparent in windowed mode: If you scale x2, the mouse must cross twice as much screen space to move from one edge of the window to the other edge. Thus, the mouse is, in a way, half as fast.

I can imagine this is a bit unexpected when the mouse is grabbed, but the pointer should move exactly as fast as the native mouse pointer (at least in well-behaved games, X-Com is an example).

Just for experimenting, I will upload a different SDL patch (look for somethin with your nickname in it) to the archive directory with a little change. Try it and tell me what you think.

Reply 104 of 156, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

hmm...I'm not seeing any differences in the diff file compared to 14-09 release - same code just different file timestamps, are you sure you uploaded the correct file?
Also, I've done some more testing, I might be incorrect. Mouse speed probably does not depend on the scaling factor, just that the cursor is a *lot* slower than native one. With hwscale=3.0 (and a 320x200 game, window mode) I have to move my mouse almost 1.5 times the width of the mouse pad to get across the screen...

Reply 105 of 156, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

I've uploaded a new version, which changes mouse behaviour slightly, and documents possible traps. Gulikoza, please reevaluate, and read the README 😉

Reply 107 of 156, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

I don't know how it is with win32, I juts looked at the SDL sources and saw that drivers switch mouse behaviour in relative mode (== when mouse is grabbed), which is probably the source of your problems. In the X11 driver, I saw some env vars being used, perhaps win32 has that too, just not documented?

I can't leave the patch as it was before, since then the mouse is unusable on X11 systems with high scaling factors (fullscreen is x4 for me).

Reply 108 of 156, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

I would be very surprised if Windows used an environment variable that had something to do with mouse behavior. More likely it would be in the registry.

A cross-platform fix would be optimal, although I don't see the point -- I don't understand why anyone would care about untrapped mouse cursor speed with DOSBox?

Reply 109 of 156, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

HunterZ, SDL uses environment variables exclusively - no registry. I'm talking about things that SDL and the SDL win32 driver does, not Windows itself.

Untrapped speed isn't any issue either - coordinates are reported in absolute mode then, and that's translated correctly. The problem is that the platform SDL-driver switches mouse speed when grabbing the mouse, and that is obviously done differently on each platform.

Reply 111 of 156, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

Just FYI: I'm still on the matter, I just lack a decent idea how to solve it. Rest assured that sooner or later the remaining mouse issue will be fixed. Such ideas usually happen on a sleepless night 😀

Reply 112 of 156, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

Sorry, I was away in Greece 😉

How about an #ifdef seeing that 09-14 and 09-16-"gulikoza" only differ in 1 if sentence? I still do not completely understand how the code works and I'll need a few days to get back into buisness 😀

Reply 113 of 156, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

Well, I guess the main problem is how people expect the mouse pointer movement. For a given amount of mouse movement, they probably expect

a) the same amount of pixels
or
b) the same percentage of the (DOS) screen/window

... regardless of scaling factor!

In full-screen mode, a) and b) are the same, so this applies to windowed mode only. I would expect that people like (a) better, since that is what the native mouse does. That was what I wanted to get. I still want to get that effect, but I don't know how to do this correctly (the problem is what I explained in a previous post).

Reply 114 of 156, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

Can SDL get the current coordinates of the unlocked mouse if DOSBox is in the foreground and the mouse cursor is over its window? It must be able to do this in a cross-platform way, since SDL programs like SCUMMVM have GUIs.

You could then sample the absolute position over time if you need to convert it to movement.

Reply 115 of 156, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

Hmm...it's really hard to make accurate tests how far the mouse cursor moves...now I have the feeling that with openglnb (& hwscale=2) the mouse cursor is faster than native cursor. It's also roughly the same speed with overlay, D3D and 09-16 openglhq. And this is the most important I think - to make mouse speed consistent across all output modes.

Reply 116 of 156, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

Hunter, when dosbox (or rather, SDL) grabs the mouse, it is switched into relative mode on purpose - the reasoning is that you can use a higher resolution/different acceleration then. And that's exactly what bites us.
Making SDL stop this behaviour would mean "dirty" patching in several locations, so this is no option for me. Although you might just have brought me on to something...

gulikoza, perhaps that's the best behaviour: Behave exactly like normal2x and all other scalers. I'll try some things.

Reply 117 of 156, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

Well, after some testing (and your valid reasoning that mouse movement should always be the same regardless of scaler), I have now uploaded the (hopefully) final version. It should be the same as one of the "fast mouse" experiments we had earlier. My tests show that now the mouse works exactly like in other scalers. A Win32 binary build is welcome, as usual 😉

Reply 119 of 156, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

Yeah, mouse was a little fast for my taste, but in the end it is exactly like it is in other scalers, so I should either quit complaining or set sensitivity in dosbox.conf 😉

Another update: I have optimized partial screen updates so that the mouse no longer laggs during fast movements in scummvm. dosbox should not be affected by that. Unfortunately, there is now a crash hidden somewhere - but that, too, should not affect dosbox or scummvm.