Mouse in SDL Ports (Choco, EE, Odamex, PRBoom)

[DevastatioN]

So I am having an issue with mouse deceleration in Odamex and Prboom, I currently have it working under Chocolatedoom and Eternity Engine. (Mouse deceleration is the opposite of acceleration, the faster you move the mouse, the less you turn.)

Since all 4 ports use SDL.dll, I'm have not many places to look for these issues. I've tried many different settings in most of these ports, and Odamex I've tried literally every combination with the staff members to fix this problem.

For information, I have 3 copies of ChocolateDoom, one with an SDL.dll from February 13, 2006, the second with an SDL.dll from June 27, 2006, and a third with SDL.dll from December 10, 2008. All versions of chocolate doom work fine with the mouse now.

I have some version of prboom with SDL.dll from December 10, 2008, and Prboom 2.5.0 with SDL.dll from December 30, 2007. Neither version of prboom works correctly and I get mouse deceleration. I have tried all other versions of SDL.dll from chocolatedoom and other places I could find them, and the problem still persists.

I have tried Odamex with all versions of SDL.dll from chocolatedoom, prboom, and anywhere else and the problem persists.

I have Eternity Engine 3.37.00 with the SDL.dll from December 27, 2009 and it works fine. I have tried a few other of the SDL.dll's and they appear to also work fine.

I have a logitech mouse and Mouseware... I have a second PC with a logitech mouse and no drivers, just the normal windows drivers and it experiences the same issues.

Anyone have any information on this, or has the same issue?

[myk]

You mean you like to apply deceleration but can't in PrBoom and Odamex?

If that is the case, you could try PrBoom+ instead of PrBoom, as it includes an acceleration setting among its extra features.

Odamex does have a set mouse_acceleration setting in the CFG, so you could try editing it or modifying it in the console, to a value under 1.

[Spleen]

I've found that mouse movement seems smoother in certain ports if you cap the FPS at 35.

[DevastatioN]

I guess I should be clearer... I definitely do not want mouse deceleraion, as it makes no sense to have it. I actually don't even want acceleration, as I havent used that in about 2 years now.

Unfortunately Odamex and Prboom are giving me this mouse deceleration, which makese these ports unplayable for me.

I always play FPS capped at 35FPS, but this would be a smoothness issue not a mouse issue.

The issue is, I want 5cm to do a 180 degree turn no matter how fast I move the mouse (no acceleration, no deceleration just a flat rate which is general). If I move my mouse twice as fast, I'll do half the distance. I've gotten to the point where I move the mouse my entire mousepad extremely quick, it'll do virtually no movement at all. It works in all other ports fine.

[myk]

Ah, yeah, using deceleration did seem a bit odd to me. You could try applying some acceleration (a positive acceleration setting.) Perhaps with the right quantity it may balance the deceleration out.

Be sure to try Prboom+ anyway, as it's maintained much more than PrBoom so it has less bugs and more optimizations. The mouse might behave properly without any tweaking.

Besides, now I see my previous advice would have been pointless had you wanted deceleration because the default (no acceleration) value for both ports is 0, which means they don't allow deceleration. Chocolate would allow it, as its "no acceleration" is 1.

[Ralphis]

I should note that I asked Devastation to post this as he wants to play on Odamex servers but has been experiencing this mouse problem that none of us on the team can reproduce. I suggested he try the other SDL engines to see what happens and those provided varying levels of success.

I guess ultimately the questions are, has anybody else experienced any of these problems? What is so inherently different from EE/Choco's mouse code from Prboom/Odamex that would cause an issue like this to occur? If this was found by EE/Choco teams in the past, how was it corrected?

[Catoptromancy]

I find it a real hard time to get mouse settings right. When I do settle on a mouse setting its always pretty close, but never exactly how I like it. Zdoom based ports are the only ports where I can setup my mouse perfectly.

Its hard to pinpoint the very slight differences I dont like. Ive just learned to play with whatever is closest. This is most noticeable with really high sensitivity. I use about 8mm for a 180 so slight differences in mousecode are very noticeable.

I think its SDL related. Ioquake3 just feels off when I need exact precision not just in aiming, but in moving. Its mouse control is as hard as SDL doom ports to get pretty close but never perfect. Dfengine or Vanilla Quake3 feel fine.

[RestlessRodent]

DevastatioN said:

I guess I should be clearer... I definitely do not want mouse deceleraion, as it makes no sense to have it. I actually don't even want acceleration, as I havent used that in about 2 years now.

Unfortunately Odamex and Prboom are giving me this mouse deceleration, which makese these ports unplayable for me.

I always play FPS capped at 35FPS, but this would be a smoothness issue not a mouse issue.

The issue is, I want 5cm to do a 180 degree turn no matter how fast I move the mouse (no acceleration, no deceleration just a flat rate which is general). If I move my mouse twice as fast, I'll do half the distance. I've gotten to the point where I move the mouse my entire mousepad extremely quick, it'll do virtually no movement at all. It works in all other ports fine.

Does this happen in ReMooD 0.8a and/or 0.8c (http://remood.game-host.org/auto/win32/)? Uses SDL.

[DevastatioN]

I have just tried the version of Remood remood_r1093-win32_mingw32.7z from the website, and I do have the same issue.

I tried using the SDL.dll which is working in chocolate doom with Remood, and I still have the same issue.

I have the same issue in Prboom+.

[RestlessRodent]

Are you running 98 or another OS?

Also what mouse settings do you use? You could also check the registry for potentially negative acceleration.

[DevastatioN]

Nothing in the registry seems to have anything to do with mouse deceleration, and it's only on certain ports that use SDL.dll.

I am testing under WindowsXP, I have this issue on two machines confirmed, and a few other people are having the same issues as well.

It appears to be an issue between SDL.dll and Logitech mice specifically, however there are ports with SDL.dll that work. So I assume something in the code is getting wonky on certain points on how they render the data from SDL.dll.

[Catoptromancy]

http://www.gamers.org/pub/idgames/themes/TeamTNT/boom/prboom202.zip

This is a direct from DOS port of boom. First version of prboom and before SDL was added. Might be good to experiment with.

[RestlessRodent]

Try an alternate driver possibly, set the environent variable SDL_DRIVER to windib. See if that works.

[entryway]

GhostlyDeath said:

Try an alternate driver possibly, set the environent variable SDL_DRIVER to windib. See if that works.

There is no support for SDL_DRIVER environment variable in SDL. And 'windib' is default value for SDL_VIDEODRIVER variable if a port does not fuck with it. At least PrBoom does not touch it at all. PrBoom+ forces it to 'directx' (if you have 'default' in cfg) for win9x only.

[DevastatioN]

The interesting thing is that this is happening on multiple machines and to different people, some with Logitech drivers and some with windows drivers. So far there seems to be no coherent rhyme or reason as to why.

I will check with the others, but I'm pretty sure it's the same consistent ports (Prboom, Odamex) with the issue.

It'd be nice to have a whole bunch of people with MX510 and different drivers to test this as well. I have not yet tried on my 3rd or 4th machines that do not use a logitech mouse, nor have I tried under a Win98 box.

It'd be interesting to see the ports that don't work, merged with the mousecode of an engine that does work just to see the results.

[Grader]

Hi.
Having the same issues here with latest versions of choco & prDoom+
The bug can be easily reproduced:
set resolution to 320x200 and fullscreen, then try to move mouse fast
as you usually do to rotate 180 degrees.
The game won't - you'll end up much less or with no rotation at all.

So, I got deep into the code... Both into choco & sdl 1.2.14.
Made a simlple mods to the choco's code to see how much of an
x movement is recieved.
And you know what? It is limited to the resolution:
for 320x200 it is [-160;159], for 800x600 it is [-400;399]
and so forth... So, if the mouse responsiveness (dpi) is high,
like logitech g5/g9, the game becomes unplayable,
unless you set hi-res, like 1600x1200+...
Bug appears when mouse cursor coords try to go over "screen limit" -
movement is just trimmed.

Choco and prDoom+ behave simularly in that aspect,
so it is the SDL problem.
Digging into SDL sources now, trying to take off those limiters,
but there's no luck for know...

[Ramon_Demestre]

I remember having the same problem (with resolution detail) on an XP machine some time ago.
To solve it i had to decrease desktop mouse sensitivity a lot however it was with a BT58 model at 80Hz and with MS drivers

[myk]

Grader said:
Choco and prDoom+ behave simularly in that aspect,
so it is the SDL problem.

What happens if you use the original DOS executable in the Windows command line (with -nosound)? Is a high-dpi mouse affected by the low resolution there?

[Grader]

myk said:

What happens if you use the original DOS executable in the Windows command line (with -nosound)? Is a high-dpi mouse affected by the low resolution there?

DOS exe works ok.
Anyway, I've tested it more and found out that:
1) logitech BT58 = FAIL, it "slips" even in windows;
2) prDoom+ has those mentioned problems and I found two solutions:
a) set higher resolution;
b) set lower "master" sensitivity via mouse drivers
(works fine with razer diamondback, logitech g5 & g9 have built-in feature - DPI switch)
3) choco-doom both have this problem and not, depending
on the video driver selected (!!!):
a) DirectX = fine, no problem, except that it feels kinda laggy even when played solo;
b) Windows GDI = BUGGED, lowering sens in drivers and getting resolution up helps. YET has faster responce and no lag.

Actually, that's exactly why I stucked with the bug in the first place - I've switched the driver, liked faster responce of it and kept it.

Anyway, it's definitely SDL bug that appears when Windows GDI driver is used.
I guess it should even be bug reported...

[Porsche Monty]

I couldn't reproduce any of these. As for Chocolate Doom specifically, GDI (which I avoid like plague) definitely makes mouse movement "faster" here, and by faster I mean "more accelerated", not "more responsive" as I don't get any noticeable lag no matter the driver.

XP Pro SP3 and incredibly cheap, ancient optical logitech mouse + XP's generic PS/2 mouse driver.

[entryway]

Grader said:

set resolution to 320x200 and fullscreen

Lowest resolution I can set is 800x600

[Grader]

Acceleration is, of course, disabled -
mouse_acceleration 1.000000
mouse_threshold 0

[entryway]

Grader said:

Acceleration is, of course, disabled -
mouse_acceleration 1.000000
mouse_threshold 0

If you want to disable acceleration, you should disable it in Windows
http://prboom-plus.sf.net/accel.png

[Grader]

entryway said:

Lowest resolution I can set is 800x600

:)
Resolution can be set via chocolate-doom.cfg.
320x200 was used to confirm the theory behind the bug.

Anyway, 640x480 should be available via setup.
High DPI mouse (razers, g5/g9) + 640x480 + prDoom/choco(GDI) = 180 angle rotation fail.
Tested on core2duo E8400 / geforce 275gtx / WinXP SP3 / razer daimondback
and core2duo E6300 / geforce 8800gt / WinXP SP3 / logitech g5.
A friend of mine tested it on his rig with g5 too and also confirmed "slips" when GDI driver is used.

[Grader]

entryway said:

If you want to disable acceleration, you should disable it in Windows
http://prboom-plus.sf.net/accel.png

Man, I've modified choco's sources to log mouse movements,
don't you think I know that kind of stuff too? ;)
It was disabled for years already :)

[DevastatioN]

Hey,

Thanks very much for doing so much research into this.

I just tried -directx today for odamex, and do not appear to have any issue. It's clear without -directx I do have an issue though.

If there's anything I can do to help you test let me know.

[Jodwin]

Grader said:

Anyway, 640x480 should be available via setup.
High DPI mouse (razers, g5/g9) + 640x480 + prDoom/choco(GDI) = 180 angle rotation fail.
Tested on core2duo E8400 / geforce 275gtx / WinXP SP3 / razer daimondback
and core2duo E6300 / geforce 8800gt / WinXP SP3 / logitech g5.
A friend of mine tested it on his rig with g5 too and also confirmed "slips" when GDI driver is used.

Just chiming in that I was able to reproduce this in prBoom+ as well. Not so big an issue for me since I don't use high DPI on my MX518, but still certainly noticeable in the extreme case (320x200 resolution).

[Grader]

DevastatioN said:

Hey,

Thanks very much for doing so much research into this.

I just tried -directx today for odamex, and do not appear to have any issue. It's clear without -directx I do have an issue though.

If there's anything I can do to help you test let me know.

Yep, odamex also has this flaw - tested it with logitech g9 today.
And yes - -derectx helps.
Btw, there did you find command line switches for odamex?
Distro doesn't have it and I browsed http://odamex.net/ for half an hour without luck =)

Also tested logitech setpoint software - it does allow lowering sensetivity.
So basically "Windows GDI" SDL driver is also playable,
providing you lower sensitivity via supplied drivers and set resolution 1280x1024 and higher.
I guess using old optic mice like MX510 with 1280x1024+ is also a solution.
But I'm goning to report this bug to SDL developers anyway.
Unfortunately, it is well may be design flaw of windows gdi and not the SDL problem at all.

[entryway]

Grader said:

But I'm goning to report this bug to SDL developers anyway.
Unfortunately, it is well may be design flaw of windows gdi and not the SDL problem at all.

What do you want to report? All is correct there. 'DIRECTX' mode uses DINPUT and that's because it does not even bother about real cursor position. WINDIB works differently and cursor position follows real cursor so it is limited with resolution.

[Grader]

entryway said:

What do you want to report? All is correct there. 'DIRECTX' mode uses DINPUT and that's because it does not even bother about real cursor position. WINDIB works differently and cursor position follows real cursor so it is limited with resolution.

So you are saying that when WINDIB is used there's no way around to "free" the cursor?