Bug Tracker – Bug 399

Choppy mouse movements when walking/running

Last modified: 2009-12-30 19:11:19 UTC
Bug 399 - Choppy mouse movements when walking/running
Summary: Choppy mouse movements when walking/running
Status: RESOLVED FIXED
Alias: None
Product: Odamex
Classification: Unclassified
Component: Client (show other bugs)
Version: (old) 0.x Alpha
Hardware: x86 (Windows, Linux, etc) Windows (Any)
: P2 major
Assignee: Denis Lukianov
URL:
Depends on:
Blocks:
 
Reported: 2008-01-12 11:06 UTC by Dmitry Dementjev
Modified: 2009-12-30 19:11 UTC (History)
5 users (show)

See Also:

Attachments

Odamex with windows key hook enabled demo (1.85 KB, application/octet-stream)
2008-06-09 16:32 UTC, Russell Rice
Details
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 Dmitry Dementjev 2008-01-12 11:06:34 UTC
I run Odamex 0.3 at Windows XP in Single Player mode and experience a weird mouse behaviour.
If I run/walk and smoothly move my mouse, the player in game turns smoothly only for about 0.5 seconds, starting to turn choppily after that time.
If I don't run/walk, just simply move my mouse, standing still, everything is OK.
Switching standard/zdaemon mouse or dynamic/non-dynamic doesn't help.
My hands are pretty steady, my mouse is mx510 at 500hz, and I never experienced such problems in any game.
If that doesn't help to locate a problem, I can record two console logs with "show mouse values" turned on, for both turning and standing still and running.
Thank you for reading this.
Comment 1 Denis Lukianov 2008-01-12 18:02:02 UTC
Please post a configuration where this happens (logfile myconfig.txt; cvarlist):

If you have time, please post the mouse values logs as they might be helpful.

Thanks for reporting this issue
Comment 2 Denis Lukianov 2008-01-12 18:02:52 UTC
remove cc's
Comment 3 Dmitry Dementjev 2008-01-12 23:52:06 UTC
(In reply to comment #1)
Here's cvarlist (I removed some colors and chatmacros)
A  * mouse_acceleration "2"
A  * mouse_threshold "0"
A    vid_winscale "1.0"
A    fullscreen "1"
     ticker "0"
     vid_fps "0"
A    snd_crossover "0"
A    con_midtime "3"
A    conscrlock "0"
A    con_scaletext "0"
A    con_notifytime "3"
A    print_stdout "0"
A    rate "10000"
A    cl_predict_players "1"
A    interscoredraw "1"
A    cl_freelook "0"
  S  teamplay "0"
  S  allowcheats "0"
  S  itemsrespawn "0"
  S  monstersrespawn "0"
  S  scorelimit "0"
  S  allowfreelook "0"
  S  allowjump "0"
  S  fragexitswitch "0"
  S  allowexit "0"
  S  fastmonsters "0"
  S  nomonsters "0"
  S  timelimit "0"
  S  fraglimit "0"
  S  infiniteammo "0"
  S  maxplayers "0"
  S  friendlyfire "1"
AU   cl_team "blue"
AU   cl_skin "Base"
AU   cl_gender "male"
AU   cl_color "40 cf 00"
AU   cl_name "MANSLAY"
AU   cl_autoaim "5000"
A    wipetype "1"
A    displaymouse "0"
A    m_side "2.0"
A    m_forward "1.0"
A    m_yaw "1.0"
A    m_pitch "1.0"
A    lookstrafe "0"
A    invertmouse "1"
A    cl_run "1"
     chasedemo "0"
A    deathmatch "0"
A    skill "4"
A    usehighresboard "1"
A    configver "30"
A    ui_transblue "0"
A    ui_transgreen "0"
A    ui_transred "0"
A    show_messages "1"
A    revealsecrets "0"
A    novert "1"
A    mouse_type "0"
A    mouse_sensitivity "14"
A    dynresval "1"
A    dynres_state "0"
A SL weaponstay "1"
     r_drawflat "0"
A    r_columnmethod "1"
A    screenblocks "10"
A    r_detail "0"
   - r_viewsize "848 x 404"
A    r_stretchsky "1"
A    crosshairscale "0"
A    crosshairdim "0"
     r_drawplayersprites "1"
A    crosshair "1"
A    snd_channels "8"
A    snd_musicvolume "0.5"
A    snd_sfxvolume "0.5"
     noise "0"
A    hud_scale "0"
A    st_scale "1"
     idmypos "0"
A    gammalevel "5"
A    vid_defbits "8"
A    vid_defheight "480"
A    vid_defwidth "848"
A    lookspring "0"
     developer "0"
  S  speedhackfix "0"
A    filecompression "1"
   - port "10667"
A    chase_dist "90"
A    chase_height "-8"
A    forcewater "0"
Comment 4 Dmitry Dementjev 2008-01-13 00:02:32 UTC
(In reply to comment #1)
> If you have time, please post the mouse values logs as they might be helpful.

<NO MOVE LOG>
22 38 38 38 38 45 53 60 60 68 68 76 60 68 68 76 53 53 68 68 83 91 68 68 38 53 45 53 60 53 45 30 30 38 45 53 53 76 60 53 45 45 45 38 53 53 53 45 45 38 53 38 53 60 60 53 38 38 38 38 53 45 38 53 68 76 76 76 60 60 91 114 98 106 121 98 98 91 83 76 76 83 83 91 76 83 76 68 83 76 76 60 76 76 60 68 60 53 60 60 60 60 68 60 60 53 53 45 60 68 60 53 53 45 45 60 60 60 60 60 60 53 60 60 83 98

You see, I try to move mouse smoothly, and every value is just about near 60.

<+MOVEMENT LOG>
60 15 22 60 91 106 114 152 45 60 60 106 98 15 30 45 76 91 106 144 22 76 91 144 174 197 7 60 60 68 114 129 136 45 68 98 136 136 152 45 76 106 129 159 144 22 53 76 114 121 129 15 30 60 83 76 76 7 22 30 60 83 114 114 7 45 83 106 114 121 129 15 53 76 76 114 114 15 30 60 76 98 129 129 83 38 68 106 121 167 15 53 68 98 129 152 7 22 60 68 121 167 159 30 45 76 98 144 182 7 68 68 121 129 167 197 30 68 83 98 129 144 7 22 60 76 60 76 83 15 15 38 60 76 114 114 45 53 91 91 136 15 38 60 76 106 121 129 22 53 76 83 98 98 15 38 60 91 152 152 167 45 83 136 174 159 30 212 98 121 159 15 38 68 91 114 121 144 15 45 68 83 91 91 7 7 22 38 76 83 91 7 38 38 68 76 83 7 22 30 30 76 76 83 15 30 60 76 98 91 121 45 45 60 83 76 15 30 53 53 76 91 106 22 53 83 98 91 106 22 38 60 76 91 114 7 22 38 83 91 129 121 7 22 38 76 98 83 7 15 45 60 68 98 114 15 22 38 53 76 68 68 7 30 30 22 30 30 7 15 22 53 76 83 98 22 38 60 60 76 15 30 60 68 98 91 15 15 30 45 83 98 91 22 22 45 60 91 114 15 22 91 129 106 121 129 22 30 45 60 76 91 7 15 38 53 60 91 98 15 38 53 68 76 60 98 30 45 68 106 121 15 60 83 121 159 144 7 22 38 53 83 114 91 22 22 53 68 76 76 7 22 53 76 68

Now you see the difference. I move the mouse just the same way, but this log clearly shows how it looks on screen - choppy. I think, the average here is still about 60, as I tried to move the mouse absolutely the same way as in previous test.
Comment 5 Denis Lukianov 2008-01-13 04:41:47 UTC
I'm suspecting joe's mouse fix in i_input.cpp:340. It probably assumes the SDL event queue to be a stack, when it is actually a queue. So perhaps when two events are queued (mouse followed by key), when the first is being processed the mouse warp is generated by this code, then second is mistakenly popped and the mouse warp is mistakenly processed.
Comment 6 Denis Lukianov 2008-01-13 04:45:36 UTC
One solution would be to SDL_PushEvent a meta-event just before the mouse warp so that the event code 'knows' to ignore the next event? Reassigning to joe.
Comment 7 Denis Lukianov 2008-01-13 04:51:57 UTC
Another solution might be to ignore mouse movement where the absolute coordinates are w/2, h/2?
Comment 8 Denis Lukianov 2008-01-13 06:06:47 UTC
The prior solution is still not thread safe (SDL might post an event between the meta-event and the mouse warp), so might suffer from the same problem, so I've implemented the latter (comment #7). Please test r514 to see if anything has improved.
Comment 9 Dmitry Dementjev 2008-01-13 07:56:53 UTC
It's still there :(
I can't get rid of it changing every mouse related cvars (i tried them all), even changing mouse rate.
Comment 10 Denis Lukianov 2008-01-13 09:34:40 UTC
[14:36]  <denis> hmm
[14:37]  <denis> well it could be sdl's key repeat thing
[14:37]  <denis> that would kick in after about 0.5s
[14:37]  <denis> but i don't see why it should delay/mess with mouse events
[14:40]  <denis> theres an easy way to prove it is that
[14:41]  <denis> because if you move to the left, then keep holding that key and briefly hit the right key,the repeats should cancel
[14:41]  <denis> then keep going and see what the mouse does
[14:41]  <Manslay> ok
[14:42]  <Manslay> exactly!
[14:42]  <Manslay> after short key tap
[14:42]  <Manslay> the mouse is smooth again
[14:43]  <denis> okay, so it's SDL repeating key stuff
[14:44]  <Manslay> but other SDL games somehow deal with that
[14:44]  <Manslay> as i have played some
[14:44]  <denis> what sdl version dll are you using?
[14:44]  <Manslay> right now i downloaded the latest
[14:45]  <Manslay> 1.2.12
[14:45]  <Manslay> 1.2.13 even
[14:46]  * denis looks at SDL_EnableKeyRepeat
[14:46]  <Manslay> better disable :D
[14:47]  <denis> but then it won't work in the console
[14:47]  <denis> guess we'd need to enable/disabled based on console state... wonder if anything else uses key repeats
[14:47]  <Manslay> seems unlikely
[14:48]  <denis> i'm still not sure why this would interfere with mouse
[14:48]  <Manslay> chatting + console
[14:49]  <Manslay> and disable ingame
[14:49]  * RedZTag (~RedZTag@125-239-9-121.jetstream.xtra.co.nz) has joined #odamex
[14:53]  <Manslay> after this one fixed i can proceed to multiplayer... maybe you'll see more bugs uncovered soon :D
[15:04]  <denis> enabling/disabling it is a pain, we're going to need our own repeat key generator methinks
[15:04]  <denis> hrm
[15:04]  <denis> hrmrm
[15:05]  <Manslay> then again, how is the mouse involved in that?
[15:36]  <CIA-5> denis * r516 /trunk/client/sdl/i_input.cpp: diable key repeats when console is up and menu is off
Comment 11 Denis Lukianov 2008-01-13 14:36:11 UTC
<Manslay> denis, i build the r520, and the mouse problem is still there :(

Then we didn't hit the nail on the head. Is SDL to blame? A good thing to try would be to write a test SDL application specifically for this.
Comment 12 Russell Rice 2008-01-13 19:35:05 UTC
does it do it in singleplayer?
Comment 13 Denis Lukianov 2008-01-13 19:38:19 UTC
all of this was tested in single player afaik
Comment 14 Dmitry Dementjev 2008-01-13 22:04:24 UTC
The problem persists on a clean WinXP, with default drivers.
And yes, all tests were singleplayer
Comment 15 Martin 2008-05-30 10:36:51 UTC
I tried Odamex 4.0 (build 460) on the czech server Liquid (map Entryway). I noticed that there is a weird bug: it is not possible to move across a map properly, because sometimes mouse does not allow to rotate properly, it is very brokenly and you cant do a quick reaction, aim properly etc. vain, my opponent in the game had the same problem, i guess it is a bug. This is the last thing to play great DM.
Comment 16 vain 2008-05-31 00:42:37 UTC
As Dmitry said in description, if you run/walk and move mouse, player turn choppily, if you don't walk and move only mouse, everything is ok. By the way I played with Titan build 860 (no 460 ;-).

(19:50:08)(@denis) does the problem happen in single player mode (new game in client)?

Yes, multiplayer and singleplayer too.
Comment 17 Martin 2008-06-01 06:32:51 UTC
I am sorry, yes vain is right, i thought build 860 of course :-). Anyway this the last thing to play odamex properly. This is the main bug IMO...
Comment 18 Russell Rice 2008-06-06 04:32:33 UTC
If you disable that windows button hook code in i_input.cpp, the problem isn't as severe.
Comment 19 Russell Rice 2008-06-06 17:48:29 UTC
Please test r920
Comment 20 Ralph Vickers 2008-06-06 19:06:28 UTC
Feels better to me, though I have zero hard evidence on my part to say that it is different after r920
Comment 21 vain 2008-06-09 10:09:05 UTC
Sorry for bad news, but this bug is still there =( I tested r931 on Windows XP Professional. Anyway, I make two demos, one in chocolate-doom and one in Odamex. First look at choco demo and after this on Odamex demo, when i trying do same thing.

Well, first demo in chocolate-doom
http://odamex.vain.cz/files/chocolate.lmp

no chance do same thing in Odamex
http://odamex.vain.cz/files/odamex.lmp
Comment 22 Russell Rice 2008-06-09 16:32:41 UTC
Created attachment 133 [details]
Odamex with windows key hook enabled demo

bugger, oh well

I made a demo after enabling the windows hook code, you can compare it to r931 odamex demo you made, you can tell it has improved though.
Comment 23 Russell Rice 2008-07-27 16:21:57 UTC
So what is the status on this bug, is it fixed or what?
Comment 24 ufon 2008-07-28 04:17:02 UTC
seems like the problem is still there, chopiness can be observed while turning running as of rev. 1030

(tested in xp pro with mx518 without setpoint)
Comment 25 Ralph Vickers 2008-08-29 11:49:48 UTC
I have done a fair amount of research on this today and, as has been discussed and expected, this appears to be an SDL issue. I have found two sources that may be of use in fixing the issue. The first of which directly references jerky movement in games like Doom using SDL. 

"How to collect all the pending keypresses and avoiding to 
have to discard all the mouse events? This is needed 
in any FPS game (DooM, Quake etc..) where the user uses 
both the keyboard and the mouse at the same time." 

followed by code. Please read: http://osdl.sourceforge.net/main/documentation/rendering/SDL-inputs.html

Person with similar issue in his SDL ported Quake engine: http://www.nabble.com/jerky-jittering-mouse-movement-td18495204.html
Comment 26 Ralph Vickers 2008-08-29 23:29:41 UTC
More research shows that the ioquake3 Dev recently found the cause of the issue and corrected it by providing a patch for SDL.

Please read more here: 

http://www.nabble.com/Poor-SDL-1.2-win32-mouse-input-(and-fix)-td18925142.html
Comment 27 ufon 2008-09-01 04:44:05 UTC
tested it today with the SDL library downloaded from here: http://offload2.icculus.org/~tma/SDL.dll (link provided by vain) and i don't see nothing out of the ordinary with the mouse other than bug #114 (sorry ;))
Comment 28 Mike Lightner 2009-12-30 19:11:19 UTC
SDL has been updated to include fixes for these issues.  I'm closing this bug until such time as it is required again.