Excellent free software game. Thanks for continuing the releases and supporting open source.

I'm having a big issue with playability. It seems that my inputs keep lagging and then buffering which causes the menus and game play to go screwy.

Like If I press left 10 times and right 20 times... It will take 30 ticks to start going right.

Then the buffer keeps going and going so the inputs are delayed for a bunch of ticks. The menus become unnavigable.

I don't have any idea on what to do. I'm running Linux Kubuntu 8.04, FGLRX 8.4 with a Radeon 3870, Nexuiz 2.4.1 (hotfix).

I've tried the SDL and GLX builds with the same result. If there is any other information I can give, please let me know.

Actually i do not really understand your problem. What 'ticks' are there in the menu? It should be used via mouse mainly?!? But then again the menu should not affect playability. Are you sure your fglrx drivers are setup correcty? Also ati drivers are not really known to be well done. What FPS do you get? There is an option in the Settings/Video menu to enable the fps display.
Then what input drivers are used in your /etc/X11/xorg.conf ? A lot of people seem to have problems with the evdev drivers..

By 'ticks' I mean unit of time.

This 'buffering' as it looks to me happens on both the keyboard and mouse inputs.

It seems as though there is a very long buffer.

Another example. Keypresses L,R,U,D (left, right, up, down).

I input this over time while playing...

LLLUUURRRRRRRRRRRRDDDDDDDDLLLRLLLLLLLLUUUUUUUU

Theoretically, I should be at the last up in that string since inputs should happen in realtime. What actually happens is that my game would be somewhere back in that chain until more input events came through. It is so strange.

My xorg.conf

Code: Select all

Section "InputDevice"
        Identifier      "Generic Keyboard"
        Driver          "kbd"
        Option          "XkbRules"      "xorg"
        Option          "XkbModel"      "pc105"
        Option          "XkbLayout"     "us"
EndSection

Section "InputDevice"
        Identifier      "Configured Mouse"
        Driver          "mouse"
        Option          "CorePointer"
EndSection

Section "Device"
        Identifier      "Configured Video Device"
        Driver          "fglrx"
EndSection

Section "Monitor"
        Identifier      "Configured Monitor"
EndSection

Section "Screen"
        Identifier      "Default Screen"
        Monitor         "Configured Monitor"
        Device          "Configured Video Device"
        Defaultdepth    24
EndSection

Section "ServerLayout"
        Identifier      "Default Layout"
  screen "Default Screen"
EndSection
Section "Module"
        Load            "glx"
EndSection


Even If I took a video of the game, it would be useless without the seeing the inputs I'm doing at the same time.

I'll give another example.

If I move the mouse to the right, then to the left. The mouse will still drift to the right for a few 'ticks of time' while moving left. The same happens for every piece of input.

I'm at a loss to explain it well.

My FPS is fine, usually way above 60FPS. But that shouldn't have anything to do with inputs. Inputs should be a higher priority than the display (I'd think).

Ok this makes stuff a bit clearer, first thing to test is the option 'wait for GPU each frame' in the Settings/Video menu and then some other reported that renice'ing X, Nexuiz and applications important for input helped (like hal) reducing input problems. An other option to test in that regard might be 'Vertical Synchronization'

I'll try each of those options and report back.

By renice, what exactly do you mean?

Sorry for the doublepost...

I updated to 2.4.2 and set wait for GPU and vert sync. Still happens.

Sorry for the triple post!

But, I noticed if I turn down the graphics level the problem gets less and less.

So weird. Shouldn't inputs take precedent over graphics? Plus it doesn't explain why they get buffered instead of dropped or delayed.

I give up.

Have you tried those options yet? Seems a bit early to give up..

I have tried those options and it still happens.

I just saw that the update manager had an update for all the HAL modules. I'll d a reboot in a bit and see if it helped.

Well i never had problems even with old HAL versions. But maybe it helps.. But there were some other reports on input problems in the forum, maybe its worth searching for them.

I did, nothing has helped yet.

I honestly don't know how to give more information. Any logs or anything I should attach?

You know, I'm beginning to think this might be a SDL problem.

I installed UT2004 today and the mouse and keyboard don't work in game but work in the menu (???) and the menu exhibited the same craziness of buffering as Nexuiz...

How do I go about making sure my version of SDL is fine?

i've seen probably the same problem on a friend's notebook for the first time about a year ago and it's still present (i'm talking of debian sid here, so the problem survived many versions of different software). the notebook was a core duo thingy, with a nvidia gpu.

we managed to show off the problem as far:
in the menu, we could - only sometimes, not fully reproducibly - move the mouse to the right and nothing happened with the mouse cursor on the screen. a few seconds later we moved the mouse up, but on the screen the mouse cursor moved first to the right (which apperantly was the previous movement of the mouse) and the upward movement of the mouse cursor appeared delayed on the screen.
so, the input data from the mouse wasn't dropped, but somewhat blocked and delayed.

the same thing happened in another game, sauerbraten, too, but it did not happen in all games. as far as i can remember it did not appear in quake4.

a year ago, we managed to work around that problem, but neither my friend nor me can remember what we did, sorry!!! :( (i can remember what did NOT fix it: the gl_finish-thing, telling SDL to not use the DGA mouse input data and to different linux kernel versions)

try moving your config to outside of your nexuiz directory. I know it seems crazy, but that did the trick for me.

Fuddl: This is the EXACT same problem I'm having and I'm glad you experienced it... well, at least you fixed it somehow.

There is hope, then.

It must be a problem with SDL since if I use the GLX version and unselect the OS mouse acceleration in Nexuiz, the game is totally responsive except the mouse goes wonky (IE: goes in a direction very fast that shouldn't happen)... but it is responsive.

Now the goal of mine is to somehow debug SDL and figure out how to make it work.

Psychcf, I'll give that a show but I doubt that will work since UT2K4 does the same thing (itself being an SDL game).

[TSA] Psychcf wrote:try moving your config to outside of your nexuiz directory. I know it seems crazy, but that did the trick for me.

hm... this is so trivial, that i cannot remember if we tried that or not a year ago! ;)

if i get you right, you mean that fixed the bug aron and i experience? if so, it would be very interesting, which option(s) cause(s) this problem!

Fuddl wrote:if so, it would be very interesting, which option(s) cause(s) this problem!

I'm too lazy to run the diffs on the two configs, but maybe I'll do it for you

I always have problems with the mouse in games and emulators on my two machines when I don't set the environment variable SDL_VIDEO_X11_DGAMOUSE=0. The problems I have are a little bit different though: In my case, the mouse always jumps back to one particular point. There are more related environment variables like SDL_MOUSE_RELATIVE. It seems unlikely that those would help you since you say that your keyboard is affected as well, but I wanted to mention it anyway, just in case...

Rebecca: GENIUS!

That env variable solved the problem in Nexuiz and UT2K4 (SDL versions). Now the mouse still has the acceleration of the OS which is totally fine for me. All the inputs are working correctly thanks to that.

I have no idea what the mouse input would have some effect on the keyboard as well, ohh well.

Thanks for the help!