Urban Terror Forums: In_mouse 3 / Raw Input @ Urban Terror 4.2? - Urban Terror Forums

That would be an AWESOME implementation to have!!

http://www.esreality...post&id=1565939

This is windows-only and would probably take significant modification to get working on other os's. Still this change would be a welcome change as I don't particularly care for mouse input going through the os before getting to the game. Without this patch, make sure your in_mouse is -1. This will disable Direct Input, removing its delay and other issues. It will be nearly the same thing this patch applies with the exception of some sensitivity/acceleration issues.

You should make this request to ioQ3 developers. After all ioUrT gets most - if not all - of its code from ioQ3 project.

That will also make this benefit other games based on ioQ3 code.

Quote

I guess there's a way to work that out at least for Linux.. since its based on EzQuake..

Quote

Quote

d0ne! lets see what pple have to say there!

I suspect they'll say they use SDL.

Their code doesn't even have the same -1 with old quake3, it's a simulation of it on SDL.



And how do you know that's lower latency?

I wouldn't be surprised if -1 is already the fastest it can get.

Let alone I'm not even sure if 1 (on windows) is even slower. Though it does create gameplay problems here for sure.

"in_mouse 1", using DirectInput, is buffered. It isn't just grabbing the current coordinates coordinates of the mouse on the screen like "in_mouse -1" does. "in_mouse -1" simply grabs the mouse coordinates, figures out the change since the last time it grabbed them, then resets the mouse to the center of the screen again. This "in_mouse 3" hooks the mouse using Windows API calls and gets the raw data from the mouse.
What does this mean?

• DirectInput with newer mice can fill up the buffer in a hurry. -
        Yes, DI was not designed for your fancy 500-1000hz laser mouse. This causes missed clicks or buttons that "stick down".
  
  
  
• DirectInput introduces a delay in mouse input of ~12ms as it buffers the input....a small delay.....but it's there.
  
  
  
• "in_mouse -1" with a high sensitivity mouse can cause the mouse to hit the edge of the screen causing a sort of "clipping" in which your mouse sensitivity is effectively capped lower than it should be. -
        Lowering system mouse sensitivity and raising in-game sensitivity should fix this.
  
  
  
• "in_mouse 3" is not effected by system sensitivity and accelleration because it doesn't care about screen coordinates like "in_mouse -1".
  
  
  
• "in_mouse 3" does not exhibit "clipping" as there is no screen edge to hit and stop the mouse.
  
  
  
• "in_mouse 3" has no acceleration by the system. If you have come to rely on system accelleration you will have to tweak your cvars (cl_mouseaccell) to get the same feeling.

Imagine that, DirectInput, a Microsoft creation kinda sucks.......who would have thought?

I'm not convinced any of the modes is better or worse since they may differ from system to system, and recent ioq3 versions use SDL, all those making the issue complex.

Nevertheless, I'd like this hack to be included if only in the interest of choice. Well, unless it's proven someone screwed up and it's nothing different.

Quote

Agreed. "in_mouse -1" is good enough for me. It's fast, and when set up properly, works just fine with no issues at all. More options are always nice. If ioq3 were to include it I'm sure it would be a welcome change for the UrT community (or at least some people) but it is not anything that needs any specific attention for addition to ioUrbanTerror as input is currently just peachy.

It's largely a nerds/e-sporters option. e.g. I disable any OS acceleration transference to the game in logitech's settings, that may make it equivalent or exactly the same to using the above hack. If I had the above hack, I'd just use it anyway.