> You both believe that the effects created in the coin-op
> arcade simulator "Hard Drivin'" (if possible to re-create on
> a PC) wouldn't help sim drivers control a car?
If the effects were dynamically sophisticated and subtle, IE: slight
changes in tire adhesion, it would be a help... but the software is
no-where near this level from what we have experienced... and in my
opinion this is not the fault of the software developers. The PC chip
can only handle so much information in real time, especially with the
GUI overheard of Windows. Plus, the real effect of physical force
feedback should be on the car chassis to be realistic, because this is
the way you experience it in real life.
I believe that the 'lack of FF in GPL' discussion is causing many to
overlook the tremendous advance represented by GPL: A true 3-D physics
engine with full independent modeling of all four wheels. This is a
tremendous advance over the previous 2-D physics engine. Sierra/Papyrus
should be applauded and supported because this step promises to advance
the sophistication of driving software towards greater realism over the
coming years. Car handling will only get better and more dynamically
realistic.
Think of what could easily have been a more 'mass-market driven'
alternative:
Simplified driving model to make it easier to spend limited processor
resources on flash...
Flashy graphics with Hollywood-style explosions and superfluous
helicopters flying overhead, maybe because the corporate marketing folks
saw this held the attention of the kids in the consumer focus group...
Outside-of-car only views (arcade all the way + less programming)...
and simple FF to shake your booty when you ram the other cars... (NFS
anyone?)
You are right! As it stands right now, we don't even see a large enough
market to justify releasing an ECCI/FF wheel unit at the price it takes
to make it happen... (and an even lesser chance of doing a motion
platform).
In the big picture, we believe that it really does not matter what ECCI
says or does with FF. Our few hundred systems a year is but an invisible
speck in the mass marketplace. It is the mass market giants like
Thrustmaster, CH, Microsoft, and the big software developers that will
determine its fate. And the millions they will need to commit will need
to be supported by sales volume at a given price... or it won't happen.
respectfully,
Andy Cers
ECCI
P.S. The new CDS4000 system will be posted on our website in about 7 to
10 days. Also, ECCI-fans, PLEASE
refrain from E-mailing us asking for info on this unit until AFTER the
website is updated...
> > You both believe that the effects created in the coin-op
> > arcade simulator "Hard Drivin'" (if possible to re-create on
> > a PC) wouldn't help sim drivers control a car?
> If the effects were dynamically sophisticated and subtle, IE: slight
> changes in tire adhesion, it would be a help...
That describes Hard Drivin' pretty accurately. Find one and try
it if you haven't. It blows away the Sega FF systems that are
in the arcades now.
I think Jim Sokoloff made it pretty clear that he thinks
the current I-Force system is able to create sophisticated
dynamic effects. After reading the I-Force documtentation,
I have to agree.
I'm not disagreeing that hardware needs to improve, or
arguing that a $500 wheel won't be better than a $200
wheel, but it has to start somewhere. If there are
$200 wheels out there, then support the damn things :)
In the I-Force scheme, all the main cpu will need to do is monitor
a few software parameters in the simulator, and shoot them through
a serial port 40 times a second. Probably car speed, slip angle,
coefficient of friction between the tires and track surface, and
rotational velocity of the tires, would be all that needs to be done
dynamically. That is surely an insignificant load on current cpus,
compared to the vastly more complex 200 Hz model physics model in GPL.
All of the dynamic effects transmitted through the wheel are handled
by a separate processor on the wheel itself, relieving the main cpu
of the all the work related to creating and monitoring the dynamic
FF effects.
Yes but we will probably never have that for home use.
No one is overlooking the advance that GPL represents (except maybe
for Mak). But the added realism of GPL deserves a more advanced
feedback system than the tire squeal/hand-eye coordination we've been
using in racing sims for ten years
You are going overboard here. No one is asking for that - certainly
not me. On-board force processors on FF wheels should limit the
amount of FF-related work the main cpu has to do. And, "dynamically
sophisticated and subtle, IE: slight changes in tire adhesion" effects
amount to more than just "hand-candy" or flash.
Yes, you are definitely right about that - it's the larger manufacturers
and software developers who will drive it. The point, though, is what
support the simulation software developers give to currently available
hardware.
--
Pat Dotson
IMPACT Motorsports
> > If the effects were dynamically sophisticated and subtle, IE: slight
> > changes in tire adhesion, it would be a help...
> That describes Hard Drivin' pretty accurately. Find one and try
> it if you haven't. It blows away the Sega FF systems that are
> in the arcades now.
I suspect anyone who's contemplating building FF wheels for a living
has tried Hard Drivin'... :-)
The key points left open in the I-Force docs (with good reason of
course as I imagine they are "implementors' prerogative") are:
"How often can the model parameters be changed?"
"What is the frequency of the control loop for the feedback?"
"What does the Bode plot and transfer function look like for the
feedback loop?"
"How much peak force is available?"
"How much continuous force is available?"
"Over how many discrete steps can the force be applied?"
Keep in mind I'm not knocking I-Force in any way, but sure, the
I-Force **API** is very complete. I could research spaceflight a few
weeks and author an excellent high-level API for sending a manned
spacecraft to Mars; doesn't mean it's feasible to do so... :-)
Q2. is the one that I think is the most troublesome, unless the FF CPU
has access to the actual control positions at a MUCH higher frequency
than the game polls the joystick... ("Pilot Induced Oscillations"
anyone?)
Those can all be (over short timesteps) reduced to mass, spring
constant, spring center, damper constant and damper center. I-Force
actually allows spring/damper constants to be different for positive
and negative excursions; nice but not relevant if your timesteps (Q #1
above) can be small enough.
True.
Not only is this "nice" from a CPU-load standpoint, it's MANDATORY to
get stable system behavior at high "virtual" springrates. If the main
CPU has to be in the control loop, you have no hope of getting a
"correct" and stable system which can simulate strong springs.
---Jim
