Bug Tracker – Bug 1256

Odamex mouse laggy with high polling rate values

Last modified: 2019-04-06 22:10:15 UTC
Bug 1256 - Odamex mouse laggy with high polling rate values
Summary: Odamex mouse laggy with high polling rate values
Status: NEW
Alias: None
Product: Odamex
Classification: Unclassified
Component: Client (show other bugs)
Version: 0.8.x
Hardware: x86 (Windows, Linux, etc) Windows 2000/XP/Vista/7
: P5 normal
Assignee: Odamex Bug Reporter
Depends on:
Reported: 2019-01-27 21:59 UTC by Soul Sucka
Modified: 2019-04-06 22:10 UTC (History)
1 user (show)

See Also:


Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Soul Sucka 2019-01-27 21:59:32 UTC
There is a slight delay in the mouse movement when the mouse config type is set to ZDoom, messing up a lot of fast-reaction swingshots, for example. That delay doesn't seem to occur when it's switched to Doom (vanilla behaviour).

For reference, I'm using the 64-bit build of Odamex on Windows 7, my FPS is capped to 35, acceleration and threshold are both at 0, and my mouse is a Logitech G402 running at 1600 dpi.
Comment 1 Soul Sucka 2019-01-29 02:06:07 UTC
I've been told there is virtually no difference in functionality between the Doom and ZDoom mouse type configs, so I've taken it upon myself to test this further in hopes of finding out where the real issue lies. I've also updated the title accordingly.

My best guess right now is that the issue I'm having is a performance issue within Odamex. My mouse had practically no responsivity or inaccurate turn issues as soon as I lowered my resolution from 1080p to 720p. With that in mind, I decided to do some basic benchmarking on the starting room of D2M1 to see how many FPS I would get with unlimited framerate on.

Odamex 0.8.0:
110 FPS on 1080p
130 FPS on 1080p, 32bit video mode
190 FPS on 1080p, 32bit video mode, emulated 640x400
200 FPS on 1080p, 32bit video mode, emulated 320x200
240 FPS on 720p
260 FPS on 720p, 32bit video mode
330 FPS on 720p, 32bit video mode, emulated 640x400
400 FPS on 720p, 32bit video mode, emulated 320x200

Odamex 0.7.0:
160 FPS on 1080p
105 FPS on 1080p, 32bit video mode
210 FPS on 1080p, double horizontal & vertical detail mode
330 FPS on 720p
260 FPS on 720p, 32bit video mode
500 FPS on 720p, double horizontal & vertical detail mode

I didn't collect the FPS for the sake of knowing the FPS explicitly, but rather how "fast" the engine can work at, and it's evident that 0.8 runs somewhat slower than 0.7, which might have been the cause of my problem to begin with. If Odamex at 1080p is dropping to 40-50 FPS on detailed maps, then I wouldn't rule out the possibility of the port being less responsive/accurate with my mouse movement inputs in those events, even if it's just by a few dozen milliseconds. I realise the Doom engine sends and receives everything at 35 tics per second, so perhaps there is a separate buffer from Odamex (SDL2?) at work here, one that is being affected by these slight performance issues?

This is all just conjecture though, I am not familiar enough with SDL2 to know if this really is the case, but it is what makes most sense to me. I'll comment again if I discover anything new.
Comment 2 Soul Sucka 2019-04-06 22:09:51 UTC
I've finally figured out a solid root cause of the problem. For some reason, Odamex doesn't like that my polling rate is 1000Hz, so my mouse movement inputs are slightly laggy because of it. As soon as I dialled my polling rate down to 500Hz, movements became lagless and I was able to play fine again. The difference is like night and day, so there should be no doubt that this is where the problem lies, meaning my previous theories were off the mark and should be discarded as such.

As far as I know, this was not an issue in 0.7, but I could be wrong. A few other players have also been aware of this problem for a while, but there is no official bug report of it to speak of, so I'll do the honours and update the title again.