shupop - GPL_Force_Feedback

このページについて †

このページは、GEM+作者 Paul Thurston 氏による GPL Force Feedback - Theory and Guesswork を翻訳するものです。関連 RSC GPL Forum スレッドはこちら。

時間があるときに少しずつ自己確認しながら、としてまずは 2006-03-27 に少しさわりの部分だけ、書いておきます。今日書いた中でもすでに「そうなのか」というところがあるので時間をとって実機確認をしたいなぁ。

なお特に許可申請もしていないし、こうした掲載に問題はあるのかどうかも確認していません。ごめんなさい。

---

GPL Force Feedback - Theory and Guesswork †

序章(Introduction) †

In 1998 Papyrus released Grand Prix Legends. It’s physics engine was without peer in the simulator world. It was criticised for just two things; it’s difficulty and the absence of support for the new fangled Force Feedback steering wheels then making an appearance.

The next year Papyrus released the 1.1 patch. It contained bugfixes, better default setups and Force Feedback support. Compared to the canned effects in other simulators at the time it was a tour de force (excuse the pun). Despite the fact that more recent software has taken the technology on and optimised it GPL’s implementation still compares more than favourably. It may not be as complex or customisable as others but properly set up it can provide a very accurate idea of the forces acting upon the car, which is the main point really.

The key phrase in the previous paragraph is properly set up. GPL only has three settings to configure force feedback but to get it right you have to find a fine balance between them that suits your set-up.

Welcome to my assorted theories.

（略）

簡単な方法(The Easy Way) †

The simplest way to get some FF settings is to try everyone else’s and find one you like. Here’s my contribution:

最も簡単なのは、いくつかの他の誰かの設定から好みのものを探すことです。たとえばこんな感じで。

[ Joy ]
allow_force_feedback = 1
force_feedback_damping = 30
force_feedback_latency = 0.125
max_steering_torque = 145

Just copy and paste the text in italics into your core.ini making sure you delete or comment out any existing FF settings. Alternatively you can change them in the Control section of GEM+. Sorted.

上のテキストの内容を core.ini の同じ内容の箇所に上書きしてください。

Many other people have published their FF settings and you can find numerous examples on the RSC forums. Try them too as they can differ substantially from my philosophy and you may prefer them. You can save different control sets in GEM+ and select them from a dropdown which makes it easy to switch between different sets.

多くの人がこれらの設定を公開しています。RSC フォーラムでもけっこう見つけられますよ。それぞれ異なった持論があるし、どれを選ぼうと自由です。

簡単ではないけれど(The Hard Way) †

Alternatively you can work out your own personal settings.

もうひとつの方法としては、自分自身で設定を変更してみることです。

The first thing to do is to set up the wheel’s force feedback settings in the Game Controllers section of Control Panel. Set the Power to 100% and damping and return to centre forces to zero. GPL doesn’t use these damping forces and it’s important not to confuse them with GPL’s force_feedback_damping setting in core.ini. If you set a non-zero value here it applies friction to the wheel, which interferes with what GPL is trying to do. That can be useful but for now just set it to zero and leave it all to GPL.

最初にすべきことは、コントロールパネルのゲームコントローラでフォースフィードバックを設定することです。強さを 100% 、ダンピングとセンタリングフォースはゼロにします。GPL ではダンピングフォースは使われません。しかし core.ini の force_feedback_damping 設定のことではありませんから混同しないでください。ここでゼロ以外に設定していると GPL がしようとしていることの妨げとなります。使い道はあるでしょうが、ここではこれらはゼロとして、すべて GPL にまかせることにします。

Changing the force level in the Game Controllers applet of Control Panel has the effect of scaling all the forces together, it’s a volume control basically. I’ve always preferred just leaving it at 100% and using GPL’s settings to adjust it but it is another tool in your armoury. I’d recommend you don’t increase it above 100% for Logitech wheels though as the forces become non linear.

コントロールパネルのゲームコントローラでフォースレベルを変更するのは、フォースの全体的な強さのレベルを一緒に変更することになります。つまりマスターボリウムですね。でも私はいつもこれを 100% のまま、GPL 側だけで設定変更を行っていました。Logitech のハンドルコントローラではこの値を 100% 以上に設定しない方がよいでしょう。フォースの出方が非直線的になってしまうのでお勧めしません。

I’ve always looked on the return to centre setting as a cop out; If you need it then you’ve not set the core.ini parameters correctly. It’s certainly not realistic for the wheel to return to the centre when the car’s stationary. Get the other settings right and it’ll return to centre on it’s own.

もしセンタリング機能を必要としているなら core.ini をうまく設定できていない、という記述はこれまでにも多く見ました。静止状態のクルマでハンドルがセンターに戻ろうとするのは確かにリアルではありません。センターに戻ろうとする他のセッティングを見つけてください。 訳者注：走行中のフォースについて、センタリング機能が有効なのを前提に設定しない方がよいよ、ということかな

If you have a Logitech wheel you may be using the Logitech Profiler to give different Game Controller settings for different games. If you are using GEM+ you’ll need to set up profiles for each carset exe. Not difficult but easy to forget and it has confused better people than me in the past.

もし Logitech のハンドルを使っているなら、Logitech プロファイラでゲームごとに異なった設定を行うことができます。これは 65MOD や 69MOD なども使っているなら、異なった exe ごとに設定する必要があるということです。難しいことではありませんが忘れやすいので気をつけましょう。

I don’t use the profiler. My machine is set up purely for GPL so I don’t need it and I don’t like having more running than I actually need. It’s an essential tool for people who use multiple sims though and gives other facilities like programmable buttons so it’s worth looking into if you haven’t already.

私はGPLしかプレイしないのでプロファイラは使っていませんが、複数のタイトルをプレイする方には有益なツールだし、ボタンに対してプログラミングできるので、まだ使ったことがないのであれば、使ってみるだけの価値はありますよ。

設定(The Settings) †

There are three parameters to play with: force_feedback_latency, force_feedback_damping and max_steering_torque.

GPL がフォースフィードバックの表現に使うのは、反応時間、減衰力、最大トルク、の 3つのパラメータです。

GPL uses vector forces to simulate feedback from the front wheels. It calculates the forces acting on the front wheels of the car depending on the wheel’s angle of travel and velocity then works out which direction and what amount of torque it needs to apply to the steering wheel to move it accordingly. There you are, simple eh?

GPL はフロントタイヤからのフィードバックをシミュレートするために、フォースによって向きと大きさを表現します。フロントホイールが動く角度や速さによって作用するフォースを計算し、その結果としてステアリングをそれだけ動かすにはどの方向にどれだけの力が必要なのかを導きだしているのです。

Of course nothing’s ever that simple in this life and there are quite a few variables to consider, all of which affect the sort of feedback you’ll get when you’re driving. The three settings are stored within GPL’s core.ini file and I’ll deal with them in turn.

難しいことではありません。考察すべきはたった 3つの設定値だけだし、それらがどう作用するのかはドライビングすれば得られるのですから。じゃぁ、その 3 つの設定値は core.ini ファイルに保存されているから、順番に見ていきましょうか。

最大トルク(Maximum Torque) †

You need to find a nice level for the forces through the wheel. Without that it will be more difficult to determine values for the other settings. Too high and the wheel will just jump about in your hands, too low and you can’t feel what’s happening. You need to find a happy medium.

まずはハンドルから伝わるフォースの強さを好みの強さにします。これなしでは他の値を決定することもできません。フォースが強すぎるとハンドルを握っていられないし、弱すぎるとインフォメーションを感じることができなくなってしまいます。ちょうどよいところを見つけなくてはいけません。

max_steering_torque in CORE.INI determines the maximum level of the Position forces GPL will send to the wheel. GPL uses this figure to scale the forces it calculates from the front wheel vector. That means that a high number will give weaker forces and a low number stronger ones.

core.ini での設定値 max_steering_torque によってハンドルに伝わる最大トルクが決まります。この値によって、フロントホイールに作用するベクトルから計算されるフォースのスケール比率が決定されるのです。大きな値は弱いフォース、小さな値は強いフォースとなります。

This is what it says in the 1.1 readme file:

バージョン 1.1 の readme ファイルでは次のように書かれています。

“max_steering_torque is the level of torque actually computed in the game that will give the maximum force level on the device. Setting this to a higher number will reduce the force you feel. Setting this lower will increase the forces you feel, but will tend to clamp them, so you will not feel the car loading up on a hill, etc. Sorry about the bogus units (although they are at least a unit of torque).”

"max_steering_torque はそのFFBデバイスでの最大のフォースレベルを計算するのに使われます。この値を大きくするとフォースを減少させます。小さな値はフォースを増大させますが、むしろ締めつける傾向があるので、丘を急激に登ったりする際の感覚は得られなかったりするかもしれません。たしかにトルクの単位ではあるのですが、実際の単位としてのトルクではありません。"

You need to find a level that gives you enough information of what’s happening at the front wheels without making it so strong that it exceeds what the wheel can deliver. That’s not as easy as it sounds because there’s no easy way to tell when the wheel reaches its limit.

ハンドルが伝えられる範囲を超えない強さで、フロントホイールがどうなっているか十分にインフォメーションを得られる最適なレベルを見つけることが必要です。ですがハンドルのリミットを把握する簡単な方法はないので、実際にはこれがけっこう難しいのです。

For now set force_feedback_damping to zero and force_feedback_latency to the default of 0.08. Start with a max_steering_torque setting of 150. Use somewhere like the inside kerb at Crowthorne (Kyalami’s turn one) which deflects the wheel when you hit it at an angle. You’re looking for a value where you can clearly feel the movement but not so strong that you can’t control it. Remember though, reduce the number to increase the force and vice versa.

今のところはまず、force_feedback_damping をゼロにして、force_feedback_latency もデフォルトの 0.08 に設定しておきましょう。max_steering_torque の値は 150 から始めましょう。キャラミのターン 1 'Crowthorne' のイン側に縁石など、ある角度で接触すればハンドルがそれるようなところで試します。明確にその作用を感じられて、なおかつコントロールできないほど強くない、そういう値を見つけましょう。フォースを大きくするには逆に設定値は小さくすることを覚えておいてくださいね。

Don’t get too anxious about finding the exact perfect level. It’s likely that after you’ve optimised the other settings you’ll want to change it anyway.

後で微調整はできますから、今ここで正確さや完璧さに対して悩む必要はありません。

レイテンシ=反応時間・待ち時間(Latency) †

Without a shadow of a doubt latency is the most important setting to get right. It’s also impossible. From the 1.1 readme again:

Latency, 反応時間が理解すべき最重要項目であることは疑いの余地のないところです。しかしこれはまた不可能的なものでもあります。GPL バージョン 1.1 readme から再び引用します。

“force_feedback_latency can be used to try to reduce the lag in force buildup. If you swerve back and forth at speed, you might notice that the force does not seem to match what the car is doing--it is a little out of phase. The default value seems to work best with the Microsoft wheel, other wheels may require some tweaking. Generally, the lowest number that works for you is probably best. Try 0.0, then move it up if the force seems out of phase. If you set it too high, you will begin to get unwanted spikes in the force levels.”

"force_feedback_latency はフォース発現ラグを減少させることに使われます。スピードを上げたり下げたりしたとき、クルマの動きに対してフォースがマッチしていない -- フォースの発生が若干ずれているように、感じるかもしれません。デフォルト値は Microsoft のハンドル用で、その他のハンドルでは調整が必要でしょう。一般的には、設定しえる最も小さな値が良さそうです。ではまず、この値を 0.0 に設定して試してみましょう。それでフォースのずれを感じるようなら大きくしていきましょう。なお、この値を大きくしすぎると、好ましくないフォースレベルの急上昇が発生してしまうので注意してください。"

Get it wrong and the forces will be out of phase with GPL by the time they reach the wheel. This causes many undesirable side effects like weaving down straights and the car swinging from oversteer to understeer mid corner. Not good. The worst part is that it is constantly changing as you drive so there is no correct figure; the best we can do is find a good average.

ハンドルに伝わるまでにフォースの位相ずれが発生する、というのは間違った思い込みです。この要因はストレートでふらついたり、コーナー中にオーバーステアからアンダーステアへと転じたり、などといった多くの好ましくない効果からきています。悪いことにこれはドライブするたびに絶えず変化するものであり、正確な数字というものはないのです。平均的で良いポイントを探し出すことが必要です。

Imagine you’re braking for Parabolica. The back wheels lock and you get into a tank slapper. The force through the wheels is going to be swinging back and forth as you try to correct each slide. With incorrect latency the force GPL is sending to the wheel is out of date before it reaches your hands. The force feedback is in effect lying to you. It’s not really what you need when you’re trying to get the back end straight while heading towards a hedge with an Eagle by your right rear wheel…

パラボリカでのブレーキングを思い浮かべてください。リアホイールをロックして挙動を乱しました。スライドを修正しようとしたら、ハンドルから伝わるフォースはサインカーブのように大きくなったり小さくなったりします。適正でないレイテンシ設定がされていた場合には、ハンドルを握る手にそのフォースが伝わる前に期限切れになってしまい、そのフィードバックは正しくないものになってしまいます。

On a Real Car (TM) the wheel upright is connected to the steering arm. That in turn connects to the rack, which when moved laterally turns the pinion fitted to the bottom of the lower end of the steering column. Halfway up that column is usually a universal joint and at the top is the steering wheel itself.

Real Car(TM) (※トレードマークが付けられているということは単に「実車」ではないものを表している？)では、ホイールアップライトはステアリングアームに接続しています。そして次にラックギアに接続され、横方向の動きはピニオンギアによってステアリングコラムに通じています。ステアリングコラムにはユニバーサルジョイントがあってハンドルにつながっています。

Think about what would happen if you kicked the front wheel. The turning motion of the hub pushes (or pulls) the steering arm. That moves the rack. The teeth on the rack turn the pinion which turns the steering column and hence the steering wheel.

フロントホイールを蹴とばしたらどうなるかを考えてみましょう。ホイールハブが向きを変える動きはステアリングアームを押したり引いたりします。ラックが動きます。ラックギアの歯がピニオンギアを回転させ、ステアリングコラム、ハンドルを回転させます。

In an ideal world this would all be instantaneous but in reality at each joint there is play. The steering arm is usually connected to the hub via rubber bushes. There are several universal joints in the system, each of which will have a little movement in it. There will probably be a little play between the teeth of the rack and pinion. There will even be an infinitesimal amount of twist in the metal of the steering column, way too small to be perceptible but it’s there. All that slack and friction has to be taken up before the movement reaches the steering wheel. In a properly engineered road car it’s too small to really notice. In a decent race car with rose jointed suspension and solid bushes it’s even less but it is still there. That’s mechanical latency.

You’re almost certainly way ahead of me here. With respect to GPL you can substitute the mechanical components for DirectInput, your wheel’s device drivers, Windows’ USB drivers, the PC’s USB hardware and your wheel’s USB hardware, firmware, motor, cogs or belts and steering shaft. Most commercially available wheels are mostly plastic so the tolerances at each joint will be much worse than on a real car. On one wheel I had the wheel even wobbled on the shaft!

GPL’s latency setting is an attempt to synchronise the moment that the forces arrive at your hands with the time the front wheels run over whatever’s causing the force to be generated. The value is in seconds and it represents the time it takes for a ‘force’ signal to travel from GPL to your hands. GPL’s force feedback then works that many seconds in advance so that the force arrives at the same time as the car does.

Obviously to do this perfectly GPL would have to be psychic. Dave Kaemmer’s good but there is a limit so it’s an approximation. I won’t pretend to have seen the source code but it’s probably some form of linear extrapolation based on the car’s vector and the track ahead. Obviously the further ahead it tries to calculate the less accurate it is likely to be but in my experience it works very well even at quite high latency.

So how much latency should you use? Well, everything I’ve written up till now has been based on verifiable facts with a seasoning of supposition and theory. This bit though is very much my own analysis. It’s analysis based on years using GPL and a great deal of experimentation but all does is make it educated guesswork rather than merely guesswork. In m y defence I’ll try and explain my working to get extra marks.

Everyone you talk to will give you their personal latency figure and describe their own patented technique which proves their value to be just right on their machine. They’re all wrong most of the time, including me. I’ll explain…

Let’s speculate on the path a force message has to take when travelling from GPL to the wheel you’re holding and the time it takes to complete each stage.

The timings are inevitably guesses but the theory behind them is sound.

Mechanical Latency †

The biggest numbers are those related to mechanical latency. If a motor is at rest it takes time to accelerate to the required force. If it’s already moving it needs to contend with inertia before stabilising on the new force which could be quicker or slower depending on the relative difference between the current vector and the new one. Better quality motors will respond more quickly and more smoothly with less ‘cogging’. A top quality motor though will set you back £50-£100 or more. How much was your wheel? How much of that do you guess was spent on the motor?

Probably even more significant is the play in the mechanism. Try this experiment. Lightly wiggle the wheel using one finger. How much play is there? If there is no play at all, get out of your Bentley, go indoors and try it on your computer setup instead.

Move the wheel to the left to just take up the slack without moving the motor. Imagine an anticlockwise force came through the wheel now; the mechanical latency due to play in the transmission would be zero because the slack’s already been taken up, you’d feel the force immediately. If the force were a clockwise one however the motor would have to take up the slack before you felt a force at the wheel. The latency would vary depending on the force being applied, a light force will move the wheel more slowly than a powerful one.

Mechanical latency will be lower on better built wheels. Ball race bearings make an enormous difference as does a decent transmission system but you really need to have both. The old ballrace modified Logitech Red is probably still the best FF wheel ever made for GPL. The ballrace modification really tightened up the motor drive and the clever wire transmission gave a tight, play free transmission without gear cogging. It was too expensive to make though. It’s replacement the MOMO Force was ballraced throughout but used nylon cogs to transmit power from the motor to the shaft that wear and develop play. Mine has about 1-2 degrees of play and has done since it was new.

The Act Labs Force RS had a superb motor drive and belt system but threw it all away by having a plastic shaft bearing. Actually bearing is a grand title for a hole in the front of the case lined with silicon grease. One large ballrace where the shaft went into the case would have made it a world beater.

There are currently in development a couple of high end force feedback FF wheels and it will be very interesting to see how good they are. The price will put them way out of reach of the average enthusiast though. Engineering does not come cheap.

So, mechanical latency is impossible to calculate exactly because it varies at so many levels. Proper engineering would reduce it a great deal but the current crop of commercially available wheels are simply not good enough. Another thing we can definitely say about mechanical latency is that it is an order of magnitude more significant than latency added by the software, which is why it’s still an issue despite the vast increases in computer speed. Software latency does still matter though and we need to consider it.

Software Latency †

Windows is a Pre-emptive Multi Tasking Operating System. It shares out the system’s resources more or less fairly to any number of programs running simultaneously. It uses a prioritisation system to ensure more time critical jobs get the processor when they need it and it works pretty well. That’s great for general purpose computing but GPL isn’t a typical windows application.

GPL is a single user application and doesn’t want to share. Its like a 4 year old, it wants 100% attention all of the time. Force Feedback is one of the most time critical aspects of GPL.

Modern processors are incredibly fast but they’re also extremely busy keeping the operating system running even before GPL gets a look in. There’s no guarantee GPL will get the processor’s attention immediately and any time it has to wait for the processor goes onto the latency. That time will of course vary depending on what else is running on the machine and how Windows decides to share the processor.

GPL does not send forces directly to the wheel; it calls one of the components of DirectInput. DirectInput is a big lump of program. It has to support every different kind of device it might ever encounter. It takes time to decide to send the message to device x on the USB port. That’s where the problems really begin.

With the notable exception of the Microsoft Sidewinder the first wave of Force Feedback wheels were connected to the PC via the serial port. 115KB/s of lightning fast data transmission. Then came USB and all the manufacturers dropped serial ports like a hot brick. Pity that as for our purposes the serial interface, properly configured was a better solution.

Don’t get me wrong; USB is a superb way of attaching peripherals. It’s simple, robust, fast and universally supported. The problem is that USB is a shared interface, it has to cater for every type of device under the sun, any or all of which can be connected at the same time. These days people have devices hanging off it like a Christmas Tree; mice, webcams, printers, modems – you name it, it’s got a USB interface and is probably attached to your PC. And when it’s attached to it it’s talking to it. It’s a bit like trying to get a word into the conversation at a party. You have to wait for someone else to finish a sentence then try and get in before Mike the office bore goes off on one about Maureen from Admin and his expense claim.

Of course that’s an oversimplification because the USB subsystem acts as a referee and shares the time between devices. It stops Mike talking mid sentence so someone else can get a word in but the fact remains that you still have to wait for your turn and in GPL terms that’s extra latency. Worse still it adds an indeterminate amount of latency. And if you have your wheel connected via a USB hub you’re doing it all twice. Did you know that the USB ports on the front of your computer are actually connected to the main USB system via a hub which means they work differently? Until recently I didn’t. Always plug your USB wheel into one of the rear ports on the computer.

With the venerable old serial port you could turn off the buffering. That meant that if GPL sent data to the wheel the processor had to stop what it was doing and handle it there and then. Serial ports are not shared so there’s no queuing and the bandwidth available is perfectly adequate for the small packets of data involved in FF messages.

One of the support guys at Act Labs (Their support has always been superb – they’re Canadian) maintained that if you switched off the buffers you could turn the latency down to 0 in GPL. I never agreed with him on that score but when I tried it the wheel felt much more solid and the forces were more consistent.

It’s horses for courses. USB was designed to enable multiple simultaneous high bandwidth connections. We already know a serial port connection is perfectly adequate for a FF wheel so speed’s not the issue. It’s immediate delivery we need and USB wasn’t designed for that. Can I have my serial port back please?

To reduce the USB load on the system you could unplug all non-essential USB devices like printers, scanners, cameras etc. before you go into GPL. One way to do that would be to buy a USB hub and plug them all into that. Then all you have to do is disconnect the hub and disable all those devices in one go.

If you have a USB Modem you’re in trouble of course. When you’re online you now have two latency critical devices sharing the same interface. If you have broadband you could switch to an Ethernet based modem or router but that’s getting expensive. If you’re on dialup then a serial port modem might be better.

Finding a Figure For Latency †

The preceding hundred pages or so of pseudo scientific claptrap can be summed up in one sentence. The latency setting in GPL is a compromise and there is no correct setting because it’s continually varying.

You could take the view that you want accurate forces and accept the fact that they’ll be late. The disadvantage with this approach is that you’re risking PIO – Pilot Induced Oscillation. That’s where you end up weaving down straights as the forces being sent by GPL and those you’re feeling get out of phase. It’s the same effect as getting a tank slapper under braking. You can reduce the effect of this by using a lower power setting or increasing the damping in Game controllers. The extra friction makes it less likely that the weave will get out of control but also dilutes the useful forces you actually want to feel, like surface noise on a record or tape hiss on a cassette. If you don’t know what records or cassettes are ask your dad.

My favoured solution is to set latency to an estimated average figure. Using my estimates for the various stages that comes to about 1/8th of a second. I’ve been using 0.125 for about 5 years now. I don’t weave on straights unless I want to and locking rear wheels under braking doesn’t start the rear oscillating like a trifle in a centrifuge. It’s just as well as I’m not the most sensitive of brakers and spend half my life with locked rear wheels.

Alternatively you could try a setting in between. What you’ll end up with is a compromise between up to date forces and them arriving at the right time.

Don’t get paranoid about it though. I wouldn’t recommend that you spend several weeks testing different latency values and down to the seventh decimal place. You can if you like but you’ll probably have more fun if you spend the time racing.

I’ve never seen or found a foolproof way of finding the right latency. It comes down to experiment and experience. One tip is to turn damping to zero before you start. That way any errors will be magnified and so easier to spot. Look for a setting where the wheel self centres without oscillation, you can hold the line through a corner without weaving, brake in a straight line and correct power oversteer without the rear end snapping the other way when you lift the throttle.

Latency can never be right but it can be wrong. Try to get it close though as the car becomes much more driveable and you can then concentrate on catching the Lotus in front rather than your own one’s rear end.

Damping †

GPL’s force_feedback_damping setting is mysterious, magical and much misunderstood. Happily it’s a lot easier to set than latency once you understand it.

Before we start don’t get confused with the damping setting in Windows’ control panel. That is something completely different and GPL doesn’t use it. I’m talking about the force_feedback_damping entry in core.ini.

The readme says:

“force_feedback_damping can be used to counteract the unwanted spikes. Guidelines for this number? Try anything from 0.0 to several hundred, maybe, but this also causes jumpiness if raised to excess.”

The question is how does it do it? Unfortunately the readme doesn’t tell us but one thing it does do is by send canned effects to the wheel to simulate road noise, sawtooth kerbs and the like. “Sacrilege” I hear you cry – “GPL doesn’t use canned effects!” Try this experiment.

Set damping to 90 and max_torque to 145. Go to a training session at Kyalami. As you come to the first corner lightly touch the inside kerb at Crowthorne (turn one) and note the wheel being pushed to the left.

Continue round Barbeque then get to the right of the track. At the fast left-hander (Jukskei Sweep, turn three) cut the corner with the left hand wheels, as you do you’ll feel the rumble strips as the left front wheel runs over the kerb.

Exit GPL and change force_feedback_damping to zero then try the same thing. The first thing you should notice is the lack of road noise through the wheel. What you’ll notice next is that Crowthorne feels exactly the same, the wheel is pushed to the left as before. That’s because the kerb at Crowthorne is a physical object in the track that actually deflects the wheel , triggering a force signal to tell you what the front wheel’s doing.

At Jukskei though you will feel nothing as you cut the corner, it’s just like driving over slippery tarmac. That’s because the kerb at Jukskei is a surface change rather than an object and you’ve turned off the surface forces by switching force_feedback_damping to zero.

There are two different types of force sent by GPL to the wheel. The forces controlled by max_steering_torque are calculated to move the steering wheel to tell you about the forces acting upon the front wheels. The force_feedback_damping forces on the other hand tell you what is underneath the front wheels; tarmac, rumble strip, grass, sand etc. Texture information if you like.

In essence the positional forces tell you about the shape of the track while the surface forces tell you about it’s texture. Just as with graphics it’s nice to have the textures on but you don’t need them to drive fast, in fact they can sometimes be a distraction.

Here’s where you have to make an important decision. Do you want to be as fast as you can be or do you want to imagine you’re driving a real car?

The surface effects tell you very little of importance. They help you determine the edge of the track under some circumstances but if you don’t know that then the screen saver’s probably kicked in. They’re a distraction and they dilute the important Position forces. One of the reasons we’re able to go faster than Clark and Gurney is that we don’t have the distractions of physical forces acting on us. The Surface forces add some of that back and as a consequence they make things a little more difficult.

A good quality passive wheel will make you faster than any Force Feedback wheel on the market, a joystick and pedals is probably even faster. GPL to many people is about realism though. To get as close as possible to the illusion of driving a real car you need to use a wheel and include the surface texture information.

The decision is yours and yours alone and is dependent on what you want from GPL.

The stated aim of force_feedback_damping is to damp out the spikes caused by the imperfections in the FF system. The readme says the following:

force_feedback_damping can be used to counteract the unwanted spikes. Guidelines for this number? Try anything from 0.0 to several hundred, maybe, but this also causes jumpiness if raised to excess.

I’ve never been able to decide whether damping does anything other than control the Surface forces. Adding noise to the signal would have the effect of damping out spikes by inserting a frictional element into it but it may be that there is in addition extra friction or spike suppression put onto the signal by GPL. It’s difficult to tell.

In the 90’s CD player manufacturers discovered that if you added a little white noise or ‘Jitter’ to the digital signal it made the music sound more natural. What it was doing was converting the distortion from even to odd order harmonic distortion, which the human brain can more easily filter out. Adding road noise to the FF signal possibly does much the same thing.

As an aside, something many people don’t realise is that a lot of the spikes in GPL’s FF are caused by asymmetric setups. Asymmetric camber particularly destabilises the FF system and you’ll get spikes through the wheel as you drive down straights. The balance of opinion has always suggested it’s because GPL treats the asymmetric wheels as a broken suspension. Using Symmetrical setups is historically correct anyway.

As a further aside, there was a theory that gained popularity a few years ago that max_steering_torque and force_feedback_damping had been transposed and values for both in the thousands were the way to go. I never bought into that and believe it’s based on a misunderstanding of what the force_feedback_damping setting actually does. Setting it extremely high will have the effect of amplifying the Surface effects to a very high level while setting max_steering_torque to anything over a few hundred effectively switches the main vector forces off. The combination of those two things will certainly give powerful force effects but you’re only getting the texture information and none of the useful ones.

My view is that it seems pretty likely to me that Dave Kaemmer wrote the Force Feedback section of the readme. He wrote the code and we know he used a Microsoft wheel, which is what the default settings are for. As such I think it’s fair to assume the readme is correct and the default settings representative of how the interface is meant to work.

The default value for damping is 40. Use that as your starting point and work your way up and down to find a level you like. You might find it easier to put max_steering_torque to a high figure like 500 to allow you to set the texture forces in isolation. You may find you have to increase it a bit when you turn the main vector forces back on but it should allow you to find a good basic level.

Other Considerations †

Although there are only three settings that directly affect the force feedback there are several other things which affect it indirectly.

The steering ratio in the setup affects the feedback because at higher ratios the forces will be amplified. This isn’t a problem in itself, in fact it’s quite correct but you should be aware of it if you use different steering ratios for different circuits.

The steering hack is a little more insidious. With it switched on GPL progressively increases the steering ratio the slower you go under 60 MPH and the feedback will be affected accordingly. It’s handy at places like Monaco to get round the hairpin but beware. As your speed drops the steering angle will change without you doing anything. It’s a bit like having someone else’s hand on the steering wheel as you slow down.

I prefer using non linear steering and an 8:1 steering ratio. That gives good control around centre but enough lock at the extremes to get round hairpins. It gives you the advantages of the steering hack but does it consistently. It also has the advantage that it works at high speed so you can catch some horrendous slides. I once got third in a league race at Monza because I managed to save a 150MPH slide at Curva Grande. Without 8:1 steering I would have been a smear of green paint on the Armco.

Of course the ideal from a realism point of view is to have realistic multi turn steering lock such as you get with the Logitech Driving Force Pro. I’ve not used one yet but I know Gary Tall has spent time trying to set one up and hasn’t managed to get it right yet. Mind you he does spend far too much time driving other inferior sims so he’s probably not trying hard enough.

Something noone links with force feedback is the graphics rasterisers. When you’re getting a full 36 frames per second there’s no difference. If the frame rate drops below that though in my experience you’re much better off with OpenGL than Direct3D.

I noticed it when I first switched to OpenGL and tried an offline race at Watkins Glen. Coming through the Esses in the middle of the pack I realised I had much better control of the car than the previous time I’d raced there. The only change I’d made was to switch to OpenGL so I switched back to Direct3D and tried the same thing. When the frame rate dropped to under 30 in the Esses the force feedback went very odd and the car became difficult to control. Switching back to OpenGL I still got under 30fps but the controls remained perfectly stable all the way round.

I suspect it’s because GPL was originally written for Rendition and 3DFX (Glide) cards. OpenGL is very similar to Glide so matches GPL very well. Direct 3D is a completely different API and the timings could be different. I don’t know if that’s the explanation but the effect is there, certainly with my GeForce 3. If you don’t get 36fps all the time with Direct3D then give OpenGL a try.

And that’s about it. Decide what you want from GPL and find yourself some settings that work for you. Hopefully the preceding pages will help you in your search.

Or alternatively just nick someone else’s settings. After having spent so much driving time reading this far that’s probably all you have time for…