Bug Tracker – Bug 1256

Odamex mouse laggy on high video resolutions

Last modified: 2019-01-29 02:06:07 CST
Bug 1256 - Odamex mouse laggy on high video resolutions
Summary: Odamex mouse laggy on high video resolutions
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
URL:
Depends on:
Blocks:
 
Reported: 2019-01-27 21:59 CST by Soul Sucka
Modified: 2019-01-29 02:06 CST (History)
1 user (show)

See Also:

Attachments

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 CST
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 CST
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.