search

warvair / grafx2

Automatically exported from code.google.com/p/grafx2
0 stars 0 forks source link

Mouse sensitivy in fullscreen mode #159

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
When using fullscreen mode, you may notice that the mouse movements are
faster than normal if the resolution is smaller than your desktop
resolution, and slower if the resolution is bigger.
It becomes a problem in very low resolutions like 320x240, because mouse
reaches a speed of x3, hard to control.

I saw it on Windows, I don't know if it's the same on other OSes.

One walkaround is to use a higher resolution, and use double, triple or
quadruple pixel mode.

Original issue reported on code.google.com by yrizoud on 8 May 2009 at 7:30

GoogleCodeExporter commented 9 years ago 
It's a problem of SDL. Maybe 1.3 will help :/ or not.
Mouse coordinates are reported as integers in the desktop space: we know how 
many
pixels the mouse cursor would have moved if it was on the desktop. We get no
information when mouse movement is too small to move from one "desktop pixel" 
to the
next, so in resolutions higher than desktop this is completely unfixable.

In low resolution, if we apply a reduction to the received coordinates
(mouse_x*mode_width/desktop_width), it will seem to work. But in any cases 
there will
be scaling error, I think that it will control badly as the pixels will seem to 
have
uneven size, like 1 23 45 67 89.
We can compute the closest integral factor; then it will still be sometimes 
fast, but
at least it will be *evenly* fast, and in the worst case it will be not faster 
than
2x normal mouse sensitivity.

Original comment by yrizoud on 8 May 2009 at 7:42

GoogleCodeExporter commented 9 years ago 
Wasn't that already a problem in the dos version ? I think it was what the 
function 
"Sensibilite_souris" was doing, but I never rewrote this one, and someone 
decided to 
remove the stub (with a call to UNIMPLEMENTED macro) and all the calls to it.
I can't test if it also happens on linux, because my videocard will always use 
a 
"closest match" resolution in a very short list (640x480, 800x600, 1024x768, 
1280x800, 1440x900) and enforce a sqauare aspect ratio on pixels. As a result 
the 
screen appears unzoomed at the center of the display area and mouse speed is 
always 
consistant...

Original comment by pulkoma...@gmail.com on 8 May 2009 at 7:55

GoogleCodeExporter commented 9 years ago 
It's me who removed the UNIMPLEMENTED, as the message to stdout (in French 
language
and OEM font) puzzled a tester. A lot of dead code and obsolete INI settings are
still there, I don't forget (issue 23)

In DOS it wasn't too visible as useful modes were only between 320x200 and 
640x480.
I know it's only a problem if you have all conditions:
- use a CRT screen,
- use a friendly video card,
- set the settings in OS for some crazy resolutions (I used PowerStrip)
- actually try to use those modes for drawing.

Note that a side effect of the problem is that the mouse sensitivy is skewed
according to pixel ratio... When I draw a circle with the mouse (physical 
movement),
in 320x512 it draws a flat ellipse, in 640x240 it draws a tall one.

My proposed solution is not easy to implement, because we will no longer use 
the SDL
absolute mouse coordinates (they clip at [0-320]), instead we'll have to use 
the deltas.

Linux may have a workaround, by using environment variables
SDL_VIDEO_X11_MOUSEACCEL=1/2/0 and/or SDL_MOUSE_RELATIVE=0

Original comment by yrizoud on 8 May 2009 at 9:31

GoogleCodeExporter commented 9 years ago 
Started.
Note that my change affects only fullscreen, I keep the original mouse system in
windowed mode.
I have found an extra difficulty: video drivers that allow "portrait" modes, 
such as
400x640 (rotated screen). I have to detect them and swap height and width, or 
the Y
mouse sensitivy will be halved in these modes.
I have worked around this by ruling that if a mode has a ratio of 3:4, 9:16 or 
10:16,
it is a rotated mode.

Tested ok on the one computer that supports it: In 384x512, the mouse 
sensitivity is
reduced by 50% horizontally and vertically, which makes it identical to running 
1024x768.

Original comment by yrizoud on 11 May 2009 at 9:46

GoogleCodeExporter commented 9 years ago 
Gaaah, this really doesn't work...
Scaling the mouse movement linearly gives very imprecise results in some 
resolutions, so I have to use integral factors only (Mouse speed /2, /3 etc)
It's impossible to determine accurately the video pixel ratio, so my guesses 
often 
go wrong and make mouse sensitivity very different in X and Y axis.

I'm falling back on letting the user choose mouse factors, as it's the only way 
for 
user to really choose what he needs.
This setting will only affect fullscreen mode, since windowed mode uses 
directly the 
desktop accuracy.
I'll re-use the old settings in .ini (The two sliders in Settings screen), it 
shouldn't be too disruptive for most users since it's set at 1 by default: no 
scaling, like today.
For X and Y the available values will be 1-4 so mouse speed can be set to 
"normal", 
halved, /3, /4.

This is far from ideal, but I don't see any way to do better... the only 
solution 
for a heavy user of fullscreen modes is to select the closest values in Grafx2 
and 
then fine-tune his general mouse settings in his OS or window manager.

Original comment by yrizoud on 14 May 2009 at 2:20

GoogleCodeExporter commented 9 years ago 
Fixed in r819.
Maybe in the future we could store the setting for each resolution, in gfx2.cfg 
(it
only takes 4 bits, we can keep forward compatibility)

Original comment by yrizoud on 24 May 2009 at 10:51

GoogleCodeExporter commented 9 years ago 
Doesn't work anymore since r1553. When SDL is in absolute mode (in order to 
make tablets work), the 'relative' movement don't work anymore, it gets stuck 
on edges of the (invisible) physical cursor. This makes it impossible for us to 
get more "pixels" of horizontal or vertical movements.
I've made many tests; we require moving the mouse (SDL_WarpMouse), but it posts 
a mouse event that will include relative deltas and will cause a backward 
effect. I've tried posting a custom event to inform 'ignore next' but it's not 
reliable enough (queue not empty); I've tried avoid this problematic event by 
enclosing the call between a pair of SDL_EventState() to choke any 
MouseMovement, it almost works but randomly eats some button events too. I've 
tried delaying this re-centering by waiting until mouse release, it looks 
perfect for mouse, but tablet still causes a kind of hiccup and not always 
works - I guess it sends a batch of events at a time, not always in the same 
order.
Tablets are more common than low-res support, so in r1781 I removed all 
mouse-sensitivity code, until the time I get some genius idea...

Original comment by yrizoud on 18 Apr 2011 at 10:37