rec.autos.simulators

by **John Hartrid** » Fri, 30 Nov 2001 19:59:29

Do all ff steering wheels have the same software overhead ie the
same loss of frame rate in games ? Or do some wheels affect
frame rates less than others ? I guess that in these days of
Gigahertz PCs it's not so important, but I only have a 366MHz
which I fear may suffer with a ff wheel. I would mainly use it
with F1 Cs 2000, NFS4 and Colin McRae 2, which run acceptibly
without ff, but I would hate to lose frames if I went to ff.

John

by **Andre Warrin** » Fri, 30 Nov 2001 21:08:20

>Do all ff steering wheels have the same software overhead ie the
>same loss of frame rate in games ? Or do some wheels affect
>frame rates less than others ? I guess that in these days of
>Gigahertz PCs it's not so important, but I only have a 366MHz
>which I fear may suffer with a ff wheel. I would mainly use it
>with F1 Cs 2000, NFS4 and Colin McRae 2, which run acceptibly
>without ff, but I would hate to lose frames if I went to ff.

No, it differs with each wheel. The MSFF was known to have quite an
impact on the fps, while the LWFF hardly had any impact. The Momo uses
slightly more cpu cycles than the LWFF. But I can't give you numbers
how much fps each wheel will cost you on your system :(

by **Ruud van Ga** » Fri, 30 Nov 2001 22:36:41

>Do all ff steering wheels have the same software overhead ie the
>same loss of frame rate in games ? Or do some wheels affect
>frame rates less than others ? I guess that in these days of
>Gigahertz PCs it's not so important, but I only have a 366MHz
>which I fear may suffer with a ff wheel. I would mainly use it
>with F1 Cs 2000, NFS4 and Colin McRae 2, which run acceptibly
>without ff, but I would hate to lose frames if I went to ff.

The FF stuff takes place mainly in the controller itself. That runs a
certain number of FF effects simultaneously. So the only thing is some
communication (which does seem THE actual bottleneck).

Although I'd think only the communication speed would matter, it seems
that in real life things don't work out as cleanly as that (wasn't the
USB MSFF slower than the gameport MSFF?).

Ruud van Gaal
Free car sim : http://www.marketgraph.nl/gallery/racer/
Pencil art : http://www.marketgraph.nl/gallery/

by **Mike Stanle** » Fri, 30 Nov 2001 22:45:45

Don't think it's just related to FF though. I've got an Interact PC PowerPad
pro (just an analog gameport joypad - no FF) and just polling it in my sim
takes the framerate from about 80 to about 30.

Mike.

by **Dave Pollatse** » Sat, 01 Dec 2001 07:04:50

Ruud is correct that the communication is typically the bottleneck. We
investigated why the MSFF wheels were so slow compared to the other USB
wheels; the main problem appeared to be that the MSFF drivers had to do a
complete cycle of communication with the device to send force feedback
commands--i.e., send a request to the device over USB, and wait for it to
respond. Whereas the other drivers, such as Logitech, were able to send a
force feedback command, and return control to the game program immediately
after. It was unclear whether this asynchronous behavior was due to a
difference in the hardware, or to the use of a helper thread to manage the
interaction with the wheel. Part of the problem is that DirectInput is
(foolishly, in my opinion) designed as a synchronous API, so the MSFF
drivers were more in the "letter of the law" even though nobody in their
right mind would want to incur such a hideous performance penalty for such a
pedantic reason.
-Dave Pollatsek
MGI

> > The FF stuff takes place mainly in the controller itself. That runs a
> > certain number of FF effects simultaneously. So the only thing is some
> > communication (which does seem THE actual bottleneck).

> > Although I'd think only the communication speed would matter, it seems
> > that in real life things don't work out as cleanly as that (wasn't the
> > USB MSFF slower than the gameport MSFF?).

> Don't think it's just related to FF though. I've got an Interact PC
PowerPad
> pro (just an analog gameport joypad - no FF) and just polling it in my sim
> takes the framerate from about 80 to about 30.

> Mike.

by **Dave Henri** » Sat, 01 Dec 2001 15:50:01

I was just gonna Say that Dave from MGI had discussed this subject several
months ago and....well....he re-inforced it himself. :)
way to beat me to it....
dh

> Ruud is correct that the communication is typically the bottleneck. We
> investigated why the MSFF wheels were so slow compared to the other USB
> wheels; the main problem appeared to be that the MSFF drivers had to do a
> complete cycle of communication with the device to send force feedback
> commands--i.e., send a request to the device over USB, and wait for it to
> respond. Whereas the other drivers, such as Logitech, were able to send a
> force feedback command, and return control to the game program immediately
> after. It was unclear whether this asynchronous behavior was due to a
> difference in the hardware, or to the use of a helper thread to manage the
> interaction with the wheel. Part of the problem is that DirectInput is
> (foolishly, in my opinion) designed as a synchronous API, so the MSFF
> drivers were more in the "letter of the law" even though nobody in their
> right mind would want to incur such a hideous performance penalty for such
a
> pedantic reason.
> -Dave Pollatsek
> MGI

> > > The FF stuff takes place mainly in the controller itself. That runs a
> > > certain number of FF effects simultaneously. So the only thing is some
> > > communication (which does seem THE actual bottleneck).

> > > Although I'd think only the communication speed would matter, it seems
> > > that in real life things don't work out as cleanly as that (wasn't the
> > > USB MSFF slower than the gameport MSFF?).

> > Don't think it's just related to FF though. I've got an Interact PC
> PowerPad
> > pro (just an analog gameport joypad - no FF) and just polling it in my
sim
> > takes the framerate from about 80 to about 30.

> > Mike.

by **Ruud van Ga** » Sat, 01 Dec 2001 23:30:29

On Thu, 29 Nov 2001 16:04:50 -0600, "Dave Pollatsek"

...

That's like going back to polled joysticks. So then you're dependent
on the controller's CPU speed, not good.
An idea might be to handle DirectInput in a separate thread, where it
just puts out the latest FF result to the controller, where the
physics thread only stores the results in a variable. But I don't
really know if DirectInput is threadsafe like that. Being synchronous,
you'd expect it not to be. ;)
The inputs would then perhaps be done in the physics thread as usual,
to maintain a solid number of inputs per second (like it should be,
although I must say I haven't done this in Racer yet). Note that my
gameport MSFF wheel can handle 200fps ok, where I do seem to input
states and send out FF to the wheel at the same rate. Which seems ok,
but I'll have to check if mouse vs. wheel doesn't give a big
difference.

Ruud van Gaal
Free car sim : http://www.marketgraph.nl/gallery/racer/
Pencil art : http://www.marketgraph.nl/gallery/

by **Dave Pollatse** » Thu, 06 Dec 2001 12:43:59

Yes, the re-entrancy issues were why I was hesitant to put it in a seperate
thread. Actually the polling and sending was within our physics thread, so
it shouldn't have impacted the graphics thread; however our physics thread
was a high-priority thread (because it was also doing software sound mixing
and network access), but my fear was that the driver was locking out all
threads during the "pause". This was with DirectX 7, it's possible things
have changed with DX8, but I haven't seen our MSFF wheel since we moved
offices...
Ahh... it's kind of nice working on the PS2 again where you measure
controller overhead in microseconds instead of milliseconds and get to write
your own USB drivers... ;)

> On Thu, 29 Nov 2001 16:04:50 -0600, "Dave Pollatsek"

> ...
> >Part of the problem is that DirectInput is
> >(foolishly, in my opinion) designed as a synchronous API, so the MSFF
> >drivers were more in the "letter of the law" even though nobody in their
> >right mind would want to incur such a hideous performance penalty for
such a
> >pedantic reason.

> That's like going back to polled joysticks. So then you're dependent
> on the controller's CPU speed, not good.
> An idea might be to handle DirectInput in a separate thread, where it
> just puts out the latest FF result to the controller, where the
> physics thread only stores the results in a variable. But I don't
> really know if DirectInput is threadsafe like that. Being synchronous,
> you'd expect it not to be. ;)
> The inputs would then perhaps be done in the physics thread as usual,
> to maintain a solid number of inputs per second (like it should be,
> although I must say I haven't done this in Racer yet). Note that my
> gameport MSFF wheel can handle 200fps ok, where I do seem to input
> states and send out FF to the wheel at the same rate. Which seems ok,
> but I'll have to check if mouse vs. wheel doesn't give a big
> difference.

> Ruud van Gaal
> Free car sim : http://www.marketgraph.nl/gallery/racer/
> Pencil art : http://www.marketgraph.nl/gallery/

by **Ruud van Ga** » Thu, 06 Dec 2001 21:25:17

On Tue, 4 Dec 2001 21:43:59 -0600, "Dave Pollatsek"

>Yes, the re-entrancy issues were why I was hesitant to put it in a seperate
>thread. Actually the polling and sending was within our physics thread, so
>it shouldn't have impacted the graphics thread; however our physics thread
>was a high-priority thread (because it was also doing software sound mixing
>and network access),

Cool, I've been wondering about my UDP writing, which is all in one
thread, together with the physics. I'm used to Unix and Amiga systems
which then output their data using a separate OS thread, so you don't
get to bother with delays, but on Windows, hm. ;-)

Does the physics thread set aside a state snapshot for the graphics to
draw? In my sim a physics thread would play with the numbers that the
graphics is still trying to draw, so I just linearly call
physics-graphics. (I'm still assuming 1 CPU)

Lol, I wouldn't be happy to write USB drivers just to poll a
controller. :)
Those low-level days are gone for me.

Ruud van Gaal
Free car sim : http://www.marketgraph.nl/gallery/racer/
Pencil art : http://www.marketgraph.nl/gallery/

rec.autos.simulators

Force Feedback software overhead ?

Force Feedback software overhead ?

Force Feedback software overhead ?

Force Feedback software overhead ?

Force Feedback software overhead ?

Force Feedback software overhead ?

Force Feedback software overhead ?

Force Feedback software overhead ?

Force Feedback software overhead ?

Force Feedback software overhead ?