Force Feedback software overhead ?

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

On 29 Nov 2001 02:59:29 -0800, [email hidden] (John Hartridge) wrote:

Quoted text (7 lines)

>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 :( >John

On 29 Nov 2001 02:59:29 -0800, [email hidden] (John Hartridge) wrote:

Quoted text (7 lines)

>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/

"Ruud van Gaal" <[email hidden]> wrote in message news:[email hidden]...

Quoted text (9 lines)

> 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.

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 "Mike Stanley" <[email hidden]> wrote in message news:nYqN7.247$[email hidden]...

Quoted text (14 lines)

> > "Ruud van Gaal" <[email hidden]> wrote in message > news:[email hidden]... > > 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

Quoted text (7 lines)

> 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. > > >

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 "Dave Pollatsek" <[email hidden]> wrote in message news:3c06af56$0$79553$[email hidden]...

Quoted text (13 lines)

> 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

Quoted text (22 lines)

> pedantic reason. > -Dave Pollatsek > MGI > > "Mike Stanley" <[email hidden]> wrote in message > news:nYqN7.247$[email hidden]... > > > > "Ruud van Gaal" <[email hidden]> wrote in message > > news:[email hidden]... > > > 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

Quoted text (8 lines)

> > takes the framerate from about 80 to about 30. > > > > Mike. > > > > > > > >

On Thu, 29 Nov 2001 16:04:50 -0600, "Dave Pollatsek" <[email hidden]> wrote: ... >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/

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... ;) "Ruud van Gaal" <[email hidden]> wrote in message news:[email hidden]...

Quoted text (8 lines)

> On Thu, 29 Nov 2001 16:04:50 -0600, "Dave Pollatsek" > <[email hidden]> wrote: > > ... > >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

Quoted text (21 lines)

> >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/

On Tue, 4 Dec 2001 21:43:59 -0600, "Dave Pollatsek" <[email hidden]> wrote: >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)

Quoted text (7 lines)

> 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... ;)

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/