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
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.
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.
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.
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.
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.
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.
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.
The Settings
There are three parameters
to play with: force_feedback_latency, force_feedback_damping and max_steering_torque.
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?
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.
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.
This is what it says in
the 1.1 readme file:
“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).”
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.
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:
“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.”
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.
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.
|
DirectInput API |
0.001 |
|
Wheel’s device drivers |
0.001 |
|
Windows’ USB drivers |
0.01 |
|
PC’s USB hardware |
0.001 |
|
Wheel’s USB hardware |
0.001 |
|
Wheel’s firmware |
0.01 |
|
Motor/Transmission |
0.1 |
|
Steering shaft flexure |
0.00001 |
|
Wheel flexure |
0.00001 |
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…