[BUG] Mouse Input problems

[kit89]

After hearing complaints about the Inputs on the latest release 0.7.7 I've attempted to try & re-create the problem others are suffering. Which I have managed to do so in Linux, specifically Kubuntu Hardy Heron.

The problem seems to arise when making sudden & quick moves, this can be easily noticed when doing a 180 turn as quick as possible, if you try this yourself you'll notice you only get 45, 90 degrees round before you suddenly stop.

I assume this could probably be just a buffer overflow as the stack doesn't have the space it needs to store all the locations of the mouse.

I also did test at 30 frames per second & 125fps. 30fps caused the problem to be more noticeable & I believe caused it to happen more regularly. Though that could just be because it isn't rendered smoothly compared to 125fps.

I noticed my com_hunkmegs was set well below the default (originally 64MB) so was increased to 128MB, this did not resolve the problem.

[kit89]

Okay after trolling the source files & trying to get a grasp of quakes input system I managed to make a respectable effort of resolving the problem. As Jackthompson stated before on another thread that the problem could possibly be caused my the engine trying to process through to many movements in the queue.

So as a quick fix I added that it clears the queue every time. Here's a test executable for testing. It's only for Linux users( I don't have a set up for Windows users).

The file that was modified is: sdl_input.c
Function: static void IN_ProcessEvents( void )
Modifying The mouse motion too:

Code:

			case SDL_MOUSEMOTION:
				if (mouseActive)
				{
					mx += e.motion.xrel;
					my += e.motion.yrel;

					Com_QueueEvent( 0, SE_MOUSE, mx, my, 0, NULL );
				}
				break;

The quick testing that I did seemed to have resolved the problem, making it very responsive.

[Mr. Oho]

Cool, nice to hear your looking into it

[andrewj]

Your change seems to just revert the change that occured from 0.7.6 to 0.7,7, which went from doing a Com_QueueEvent() call for every SDL_MOUSEMOTION event to doing a single Com_QueueEvent() call at the end of processing the SDL event buffer (summing each SDL_MOUSEMOTION in local variables).

EDIT: see here for the ioquake3 change in question:
http://svn.icculus.org/quake3/trunk/code/sdl/sdl_input.c?r1=1238&r2=1341

Now your change seems quite wrong, as mx and my are accumulating the mouse deltas without being cleared each time.

[kit89]

Thanks andrewj,

The new lines that queue the events (lines 730, 731) are still there in my modified code. I did a test by commenting these lines(While keeping the line I added) & I got similar problems to what was in 0.7.6.

It seems having Com_QueueEvent, in the SDL_MOTION case statement, & at the end resolves the problem.

Having one or the other, which is happening in both the revisions you posted causes different problems.

[fufinha]

Are you sure it's a mouse or input issue?

edit: just checked a previous issue I had and it is related to config. The effects are unpredictable movement, you feel it when you try a circle jump and it's like you've turned the mouse much faster than what you see on the screen. This particular issue is related to delag.

The cause of this is a noob admin. If you move to another server you take the problem with you because it's still set in your config. I removed it completly but there's a previous post with details, I havent had the same issue since. Just highlighting this as some people may find they suddenly have the effects of this and it's a nasty one for movement

[rancid punx]

my head hurts

[kit89]

Are you sure it's a mouse or input issue?

In short yes.

The problem is I cant find if this resolves the problem with everyone, unless people download the ioquake.i386 and test it. I tested the executable on my machine(Kubuntu) and it improved the mouse performance considerably. However without others to test I wont know if this is a good fix.

So any Linux users care to test the build in the 2nd post of this Topic?

[kernel panic]

I will. Thanks for the efforts. The new mouse input really is annoying, and playing with the old binary brings other problems like some invisible models.

[fufinha]

I do not have linux but if it didn't require code stuff I'd be chasing any linux people I come across into the server with my pokey-stick
I spent two hours online looking for people to simply test a couple of sounds by connecting to a server, us grunts have the same problem too

If Jack Thompson is helping out then he please ensure he has plenty of tea breaks and he eats properly.
 

[kernel panic]

It doesn't work for me. Sensitivity and/or mouse acceleration is absolutely changed. I think I read somewhere that the way these values are calculated changed or something of the like. I don't know, it might be just that, cause I didn't notice the infamous lag when turning quickly 180 degrees.

One simple question, though. Why does OA need to have the latest ioquake engine? If they screwed it up, can't it just use the previous version?

[fufinha]

newer = better

[CFQ]

----

[fufinha]

heheh..

This problem sounds quite brutal, I use windows and -1 for in_mouse? feels more normal for me. At 1 it feels like defrag localhost.

But this is a Linux issue right? Can the title please be edited if so I have short term memory loss and keep getting frights thinking theres hax and nasty stuff being done to a perfectly good engine. From 1.11 to 1.32 it has barely changed at all