Com_QueueEvent: overflow when moving high poll frequency mice during loading

[llbraughler]

This occurs when moving the mouse during loading with a high frequency mouse (for example, a Razer Deathadder running at 1000 Hz). The console is spammed with Com_QueueEvent: overflow.

[ec-]

Modern mice have hi-frequency polling that feeds game engine with a lot of data during movements. So if you have 1000Hz mouse - even 250ms frame delay may cause such overflow. Solution is simple: you should combine all sequential mouse moves (but not key events!) in one event - it is safe because engine uses accumulated delta anyway. With such approach it is almost impossible to cause such overflow except that you can click 100 times per second or so fix.txt

[ensiform]

I just have it print once instead of spamming in OpenJK. The fix @ec- has made looks interesting though.

[ensiform]

@ec- I just tested your patch in OpenJK and it causes the mouse to not function very well if at all. The mouse just moves a couple of pixels when moving my mouse around. Sounds like the code isn't actually set up to handle delta very well?

[ec-]

@ensiform I can't tell anything about OpenJK code but for Q3 doesn't matter how complex are your 'painted' mouse fugures between two rendered frames because it will use accumulated delta in result. Also notice that in ioq3/derivatives that delta readed before wait-loop so it adds another <1000/com_maxpfs>ms lag which may confuse even more

[ensiform]

@ec- Its the same code, still a Q3 derivative. CL_MouseEvent and CL_MouseMove do the same thing regardless

We do have the change for moving the input sampling on the other side of the loop: https://github.com/JACoders/OpenJK/commit/ba25e504f2f9c879e91268795919f35182553d3b

[zturtleman]

Fixed in https://github.com/ioquake/ioq3/commit/be1c71d36306637490348a128ecc2245b909c5da.