Jump to content

Search the Community

Showing results for tags 'acceleration'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Calculator & Converter
    • Supported Games
    • Unsupported Games
    • Technical Discussion
    • Feedback, suggestions and bugs
  • General
    • General Gaming Discussion
    • Hardware
  • Off Topic
    • Off Topic Discussion

Product Groups

  • Converted Subscriptions
  • Subscriptions
  • API Access

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

Found 2 results

  1. Basic overview and equations: The sensitivity curve is a function of mouse input velocity against a value by which input is multiplied. This value is calculated as the ratio between output and input. [outputx, outputy] = [inputx, inputy]*somefunction(sqrt(inputx^2+inputy^2)/time) acceleratedsensitivity = sensmultiplier(1+accel*sensmultiplier(inputvelocity)) outputvelocity = acceleratedsensitivity*inputvelocity Method explained with my settings as an example: Without any acceleration, static sensitivity is 0.029375. Dividing this by 2 gives a minimum sensitivity of 0.0146875. Set acceleration to 'Linear' with 'Cap Type' set to 'Both'. The initial input cap is arbitrary. Setting the output cap to 2 sets the current maximum sensitivity as the original static sensitivity. Choose an input speed that seems like a good threshold between tracking and flicking aim via 'Charts > Show Last Mouse Move'. Calculate the acceleration value such that the accelerated sensitivity at 400 counts per millisecond input speed is equal to the original static sensitivity. In this example, 400 counts per millisecond is reasonable at 25600 counts per inch. Set 'Cap Type' to 'Input' and calculate the appropriate acceleration value such that accelerated sensitivity is equal to original static sensitivity at the chosen input speed. Set the calculated acceleration value. Try it with and without the sensitivity cap. Moving your sensor over a distance of 10 inches in one second at 1,000 counts per inch results in 10,000 counts per second, which is equivalent to 10 counts per millisecond. At an input speed of 400 counts per millisecond at 25600 counts per inch the mouse speed is 15.625 inches per second. To find the input speed that maintains mouse speed at a different counts per inch value, multiply the desired mouse speed by the new counts per inch value to determine the new input speed value. Known bugs and issues with solutions and explanations: If you're experiencing spinouts with acceleration enabled, try navigating to 'Advanced > Device Menu', then manually enter the polling rate you are using. Otherwise, leave the option at the default of 0. Please read more details below. "The standard way to accurately calculate the input speed for an accel function is not only to take the distance in each packet (i.e the (x,y) counts value) but then also the time taken to send the update. In most cases, this is 1ms, but of course this varies due to the realities of chosen polling rate and consistency, and slow hand speeds causing inputs to arrive below the polling saturation point. The usual way to do this would be to call a windows time function like QueryPerformanceCounter() which has microsecond precision to take the exact value between two concurrent frames to accurately calculate the input speed. A mouse that has a very variable polling consistency could send an input that arrives much earlier than anticipated, as such, we could get a spike in input speed in one update. For example, polling rate of 1ms at 10 counts distance input, the random poll arrives at 0.4 milliseconds after previous poll, this then gives us 10/0.4 = 25 input speed, where the user would be expecting an output of 10 - if you had a steep accel curve, this input would manifest itself as a sudden increase in output velocity. RawAccel does something clever in that it takes some steps to prevent this by setting a minimum time between frames, as well as a maximum. However, since it needs to allow for 8000hz mice, this has to be set quite low by default. Setting a polling value in the device menu replaces the automatic calling of the QPC() function entirely and instead just divides every input by (1000/polling rate set). This would mean that you couldn't get sudden spikes in input speed anymore, but you also couldn't get any sensitivity values on a curve below 1 counts per millisecond, which is usually desired for accuracy. Although some people say that they prefer this behaviour, it is not recommended to do this unless you have issues." - TheNoobPolice
  2. Hello community ! I have one more issue to nag about in C.S 1.6. DPI Wizard, I'm aware you're already working on monitor match at different FOVs, but I need to address another problem, unfortunately. And that is the following: The game has horrible mouse acceleration, mostly negative thus making small adjustments in aim almost impossible to handle ( more of this I will explain thoroughly in another post + a possible fix for it ). I will keep it short - when attempting to match the sensitivity of CS:GO in CS 1.6 and converting it with the 360 method, all good ( almost ); but moving the mouse across fewer degrees ( 90, 45, 30 ) on the screen, results in a 10 to 20% "loss" in sensitivity. To clarify it, imagine you need 9cm to move across a 53.13 degree field of view & about 30 to do a 180 turn. But, upon testing it, I realized that the 9cm required movement isn't 9, but closer to 7/8, whilst the value for a 180 turn remains unchanged ( almost, as the acceleration sux ). Is there anything that can be done for it ? I've read some forums, and I ain't the only one that realized the issue, a lot of peeps said to decrease the sensitivity to about 20% of your initial one. Have a wonderful day, Munty
×
×
  • Create New...