Urban Terror Forums: Optimized .exe; builds of ioq3 engine - Urban Terror Forums

Jump to content

 Login | Register 
Advertisement
  • (142 Pages)
  • +
  • « First
  • 94
  • 95
  • 96
  • 97
  • 98
  • Last »
  • You cannot start a new topic
  • This topic is locked

Optimized .exe; builds of ioq3 engine Rate Topic: ***** 17 Votes

With GoogleTranslate, Bumpy, dmaHD, iKALiZER, Raw Mouse, Bug Fixes, ..

#948 User is offline   n4n3rz Icon

  • Account: n4n3rz
  • Joined: 21-April 10
  • Posts: 45

Posted 25 July 2010 - 08:59 PM

right, i'm looking for said external OS utility

#949 User is offline   MerkyMerc Icon

  •   verified donor   
  • Account: merkymerc
  • Country:
  • Joined: 28-February 10
  • Posts: 1,267

Posted 25 July 2010 - 09:53 PM

Input stopped responding for me on in_rawmouse 1 as well. I noticed upon start up I had a little bit of time where I could move the cursor and when xfire popped up the input stopped. Disabling xfire in-game stopped this issue.

#950 User is offline   mitsubishi Icon

  • Account: mitsubishi
  • Country:
  • Joined: 28-February 10
  • Posts: 13,481

Posted 26 July 2010 - 12:21 AM

I saw xfire coming up and it didn't alter anything here.

The implementation of raw input is rather cookie cutter; you can do some minor adjustments and can deregister it (and re-register it during the course of the game) but to initially start it and have it give signals is generally a very predefined standard process can't easily be 'wrong' as soon as it works. Hence I'd imagine it's probable we're talking about xfire or driver or windows bugs.

Notice id software on quake3 live has raw input and have not set it to default to avoid quirks. I'm pretty certain they're confident the quirks don't come from their own implementation.

Also this technology is available only after XP and server 2003; It might behave better lately.

--

It might be interesting to see on what Windows version and what Mouse those issues occur.

This post has been edited by mitsubishi: 26 July 2010 - 12:48 AM


#951 User is offline   Kendle Icon

  •   verified user   
    www.urban-zone.org
  • Account: kendle
  • Country:
  • Joined: 28-February 10
  • Posts: 306

Posted 26 July 2010 - 08:09 AM

Windows XP SP3 + G3 laser @ 1000dpi and in_rawmouse 1 works fine for me. Can't say it improves anything but it works without issue. Perhaps you actually need a high definition mouse for this to work / make a difference ?

#952 User is offline   mitsubishi Icon

  • Account: mitsubishi
  • Country:
  • Joined: 28-February 10
  • Posts: 13,481

Posted 26 July 2010 - 08:44 AM

The main big fat difference I found which is in line with this good post by Obscure is that if in-game acceleration sensitivity is low it usually means mouse sensitivity is high and that will produce negative acceleration since internal cursor hits the edge of the window often and that process introduces delays. Of course, it will go away if driver sensitivity is set too low while DPI is still high. I do that anyway since without it in-game cursor (in UI) is very fast (on 5700). (I still don't know if that has drawbacks, meaning it will be better to have high DPI on high driver sensitivity but I wouldn't bet on it).

Other than that, there's theoretically higher chance to see lower latency since the path is shorter (and busier). Some people say they see it but I can't claim I do. It may be there and help of course, but I wouldn't be able to say "there it was! this wouldn't go like that without raw.".

--
directinput (in_mouse 1 (+ in_rawmouse 0 here)) also avoids negative accel but it has quirks and latencies (latencies also according to Microsoft).

--
The reasons Microsoft claims make raw input better for gaming.

This post has been edited by mitsubishi: 26 July 2010 - 10:18 AM


bullet_loaderAdvertisement

#953 User is offline   versus666 Icon

  • Account: versus666
  • Joined: 06-March 10
  • Posts: 46

Posted 26 July 2010 - 10:01 AM

View Postmitsubishi, on 26 July 2010 - 08:44 AM, said:

The main big fat difference I found which is in line with this good post by Obscure is that if in-game acceleration is low it usually means mouse sensitivity is high and that will produce negative acceleration since internal cursor hits the edge of the window often and that process introduces delays. Of course, it will go away if driver sensitivity is set too low while DPI is still high. I do that anyway since without it in-game cursor (in UI) is very fast (on 5700). (I still don't know if that has drawbacks, meaning it will be better to have high DPI on high driver sensitivity but I wouldn't bet on it).


Franckly I don't get it.
A long time a go I spent some of time studying game engine (mainly Q3) and the logic between sensitivity, DPI and screen resolution, so I'm quite puzzled when I read you:

"if in-game acceleration is low it usually means mouse sensitivity is high"
Ok, the user compensate the lack of acceleration but also loose a bit of accuracy. Understandable, why not ?

"that will produce negative acceleration since internal cursor hits the edge of the window often and that process introduces delays"
From what I remember the so bad named 'negative acceleration' is just the HARDWARE mouse sending too much datas to the HARDWARE buffer when moved fast so some moves are skipped and it seems like the cursor is slowing and/or jumping.
I'm even more puzzled when you talk about the 'edge of the window'... The data is processed by the engine and then decide if it should 'step' in ( m_pitch, m_yaw etc), I don't remember any kind of 2 dimensional system projection behaving like if a cursor was moving on the screen. And producing delays relative to an 'edge'... Do you have a link ?

"it will go away if driver sensitivity is set too low while DPI is still high"
Well... Isn't driver sensibility just the same than windows sensibility (being between mouse and Windows, but not providing any acceleration, just translating hardware DPI to software DPI)? Using low driver sensitivity with high mouse DPI is quite pointless don't you think ? Because faints movements would not be converted to pointer movements : you LOOSE accuracy on slight movements even though it seems more fluid with high speed movements.

Anyway "high DPI on high driver sensitivity" just seems to me like heresy : you get crazy uncontrollable movements AND a nearly total loss of accuracy, whatever the kind of movements you do (also I remember there was a fuss a year or two ago about a very high CPU usage due to high DPI mouse movements, I don't know if it's fixed now, my own simple tests show a very negligible impact on CPU usage, don't know if some mouse/systems are still affected).
Or I really missed something obvious.

This post has been edited by versus666: 26 July 2010 - 10:11 AM


#954 User is offline   mitsubishi Icon

  • Account: mitsubishi
  • Country:
  • Joined: 28-February 10
  • Posts: 13,481

Posted 26 July 2010 - 10:12 AM

'if in-game acceleration is low' is a typo, I meant sensitivity.
--
To see negative accel punch you in the face, get a 5700DPI mouse on very high driver sensitivity[e.g. 'Speed' in Logitech settings] and try to move in game when game's sensitivity is low.
--
It can't be hardware-related only since it goes away on raw or direct input.
--
OS sensitivity is not respected in raw input according to Microsoft though it gets quirky if I choose 'use OS native drivers' in Logitech. Apparently it's not respected in raw if that option isn't checked and it's respected if it is checked. In non-raw it appears to go only with driver's sensitivity in those mice. It's quite confusing (and it doesn't seem standardized).

This post has been edited by mitsubishi: 26 July 2010 - 10:41 AM


#955 User is offline   versus666 Icon

  • Account: versus666
  • Joined: 06-March 10
  • Posts: 46

Posted 26 July 2010 - 12:06 PM

View Postmitsubishi, on 26 July 2010 - 10:12 AM, said:

'if in-game acceleration is low' is a typo, I meant sensitivity.
--
To see negative accel punch you in the face, get a 5700DPI mouse on very high driver sensitivity[e.g. 'Speed' in Logitech settings] and try to move in game when game's sensitivity is low.
--
It can't be hardware-related only since it goes away on raw or direct input.
--
OS sensitivity is not respected in raw input according to Microsoft though it gets quirky if I choose 'use OS native drivers' in Logitech. Apparently it's not respected in raw if that option isn't checked and it's respected if it is checked. In non-raw it appears to go only with driver's sensitivity in those mice. It's quite confusing (and it doesn't seem standardized).


So the negative accel you describe is just a buffer overflow ?

Logitech drivers are really a mess, I owed one, I saw the strange behavior with the driver, never installed it anymore, it seems they still haven't improved that in 10 year ^^

#956 User is offline   mitsubishi Icon

  • Account: mitsubishi
  • Country:
  • Joined: 28-February 10
  • Posts: 13,481

Posted 26 July 2010 - 01:51 PM

The idea is that the quirk occurs when the internal cursor used on non-raw and non-directinput mouse has to recenter itself when it hits the edge of the window. Raw and Directinput do not use cursors of the desktop and hence they don't hit such edges. Other ways to reduce the effect is higher resolution since it has more pixels to move.

#957 User is offline   versus666 Icon

  • Account: versus666
  • Joined: 06-March 10
  • Posts: 46

Posted 26 July 2010 - 03:01 PM

Is there a reason to use a will-fail-non-raw-nor-Directinput-method with an high DPI mouse, other than maybe an hypothetical compatibility ? I don't think any 'competitive mouse' would have a problem to run in RAW mode and 'basic mouse' with limited DPI won't get any advantage from RAW even if they do support RAW, so classic mouse support method is fine and do not fail... I don't see the problem.
Even if it's about mouse acceleration change between modes don't cl_mouseAccelOffset and cl_mouseAccelStyle can be used to fine tune ?

This post has been edited by versus666: 26 July 2010 - 03:08 PM


  • (142 Pages)
  • +
  • « First
  • 94
  • 95
  • 96
  • 97
  • 98
  • Last »
  • You cannot start a new topic
  • This topic is locked

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users

Advertisement


Copyright © 1999-2024 Frozensand Games Limited  |  All rights reserved  |  Urban Terror™ and FrozenSand™ are trademarks of Frozensand Games Limited

Frozensand Games is a Limited company registered in England and Wales. Company Reg No: 10343942