Tag: precision

How much FFB can you feel in GTR2? 1/1000th of a percent.

[This is a repost of a thread I started on RaceDepartment.com and just wanted to have on my blog, as well.]

Update 2018-01-25: I’m a fan of Simracing Youtuber Jimmy Broadbent and he recently noticed my RaceDepartment post How much FFB can you feel in GTR2? 1/1000 of a percent (also a blog post of mine) and posted a video about his direct drive experience on GTR2 using the force feedback settings I recommended in that post: GTR 2 – How Does It Feel With A Direct Drive Wheel? Check it out, he seems to like it! I’m really happy to help some people get more enjoyment out of this oldie-but-goodie game.

I thought the GTR2 fans would find these results on the precision of GTR2 FFB interesting. For the record, I run a SimXperience Accuforce direct drive wheel. Precision probably wouldn’t be as noticeable on belt/gear wheels.

I’ve been tuning force feedback and recording details on my blog and, in any game where I need to tune value ranges, I find myself doing bi-section searches and testing the result to find what suits me best for a particular FFB parameter.

Here’s my latest testing on this parameter in the UserData PLR file:

FFB steer force grip weight=”0.71696″ // Range 0.0 to 1.0, recommended: 0.4 to 0.9. How much weight is given to tire grip when calculating steering force.

Note 0.71696 is basically 71.696% given the 0.0-1.0 range. GTR2’s PLR files apparently have a precision of up to 5 decimal places or 1/1000th precision thought of as a percentage.

How did I end up at a super specific value like that? Well, here’s the bi-section search it took me to arrive at that value:

FFB steer force grip weight=”0.78000″, 0.785, 0.7875, 0.6875, 0.7875, 0.6875, 0.7375, 0.7125, 0.725, 0.71875, 0.715625, 0.7171875 (better), 0.71640625, 0.716796875, 0.7169921875, 0.71689453125, 0.716943359375, (0.7169189453125+ vs 0.7169677734375++), 0.71695556640625 (*, **, ***)

Yes, at every step I could tell the difference (note the “better” notation, and the “+” and “++” notations). I was choosing what gave me a better feeling of grip level while cornering.

Those last two values were (when rounded) really 71.697% and 71.696%: A 1/1000th precision difference that you could feel in the wheel.

Some might be skeptical, I understand, just be aware this is really only perceptible when you’re going hard like say for fastest lap in a qualifying session. Precision of ffb matters at that point.

Personally, I find it really fascinating to push an old game like GTR2 from 2006 this far and find out it can deliver that kind of fidelity on a modern direct drive wheel.

*Yes, to update those values I have to exit GTR2, edit the PLR, and start GTR2 back up again. A real pain but worth it when you start to feel the car as it was meant to be felt.

**My “bi-section searching” deviates from a strict bi-section search in that sometimes I experiment and try values that aren’t strictly a bi-section the previous two values. I find this can help when I’m frustrated with the feel and need to find my bearings with a bigger jump which I then narrow down again with a regular bi-section search.

***If you’re interested, I’ve attached my PLR so you can see all my modified FFB values. The car was HQ F575 GTC and the track was HQ Brno. I run 60hz vsync.

Credits

How to Round to Arbitrary Precision in any Programming Language

How to Round to Arbitrary Precision in any Programming Language: an AMultiply your rounding number by 10^y where y is the precision to round to. Call your language’s built-in round() method on this number. Divide the result by 10^y. Easy peasy. It also makes it easier to implement different rounding methods because you’re always dealing with the digit at the same location in the number.

How to Round to Arbitrary Precision in any Programming Language: Multiply your rounding number by 10^y where y is the precision to round to. Call your language’s built-in round() method on this number. Divide the result by 10^y. Easy peasy. It also makes it easier to implement different rounding methods because you’re always dealing with the digit at the same location in the number.

In javascript:

Then there’s Math.round() which you may not have or may not want to use and, if you’re rounding, at all, you’ll inevitably find yourself looking at various rounding methods. Since Math.round(), and usually all default round() methods in most programming languages, use traditional “half up” rounding, you may find you need a different method, like banker’s rounding which is “half to even”.

To accomplish a different rounding method, create your own round() function, apply the appropriate power to your number. Then, subtract the integer portion of the number. You are left with the fraction portion of your number: This gives you the rounding digit as your final number. With this number, you can then decide whether to truncate the original number or add 1. Once you’re done that, you can then remove the power manipulation you did in the first step and now you’re left with the final rounded number.

In javascript:

The functions Math.floor() (floor and ceiling), Math.pow() (exponentiation), and the modulus operator, are usually already available for most modern languages, under the same names, and don’t really have a need to be re-implemented compared to the need to re-implement rounding. Implementing your own functions for these is usually relatively trivial, however.

There you go! Arbitrary precision rounding in any programming language and, thrown in for good measure, how to implement a different rounding method to boot!