Why Is Forza Framerate Lower With a DD Wheel?

Problem

Some users report that they get a lower framerate in Forza when using a Direct Drive Wheel such as the AccuForce. Of the titles we support, the reports are exclusive to the Forza titles. Further research has shown this to be true and bug reports were filed with the Forza developers. This article attempts to explain why the issue occurs and what can/should be done about it.

Background - Why Does This Issue Only Impact Professional Grade Wheels?

Most direct drive wheels utilize the high performance, standards-based, USB HID Force Feedback driver that is developed by Microsoft and included with Windows 10 and Windows 11. This driver utilizes a direct, hardware-in-the-loop approach. A game can know exactly when its command is processed by the wheel. This is a very direct and low lag approach. 

Most consumer-grade wheels utilize a disconnected/circular buffer style of driver that is arguably not standards-based and is irrefutably a lower performance, higher lag approach. This approach is not a direct hardware-in-the-loop approach. In fact, the game can never be sure that a command it issued is processed by the wheel with this approach.

The illustrations below highlight the key differences between the two approaches:

The Consumer Grade Approach

Key Observations About The Consumer-Grade Approach

1. The game talks to the buffered wheel driver thinking that it talked to the wheel but it did not. The games instruction is left in the buffered wheel driver to be processed at a later time and in a different loop. This allows the game to quickly move on with other things.
   
   

2. There are two largely disconnected loops that run at different speeds. 
   
   

3. The second loop that sends data between the wheel driver and the force feedback wheel is typically slower than expected. We measured a popular consumer grade wheel at 250Hz. However, due to the potential for mismatched timing between the two loops, the effective rate could be as low as 125Hz. The two loop/disconnected nature ensures added lag regardless of the second loop update rate.
   
   

4. A game could possibly send updates that never make it to the wheel. For an extreme example, lets say that the game updates the buffered wheel driver 1000 times per second (1000Hz). We've already observed a consumer grade wheel driver communicating with the actual force feedback device at a rate of less than 250 times per second.  It's fair to conclude that the buffered wheel driver must drop or delay some instructions given to it by the game in order to keep up.

The Standards Based Driver Approach Used By Most DD Wheels

Key Observations About the Direct Drive Windows 10/11 Standards-Based Approach

1. When Forza sends a command, it is passed straight through to the hardware and is answered by the hardware.
   
   

2. This has the upside of the hardware being directly in the game loop and the game knowing precisely what the hardware is doing at any given moment.
   
   

3. This has the downside of Forza having to wait a few milliseconds for the roundtrip USB communication to occur.
   
   

4. This approach has the least possible delay between a games force feedback command and the wheel receiving/executing it.
   
   

5. This approach shouldn't allow the game to send commands faster than they can be communicated of USB and processed therefore it is not losing instructions sent by the game.

Why Does The Issue Only Happen With Forza Titles?

Normally a game will have a processing thread just for force feedback and input devices. By doing so, the force feedback and input device processing can never impact the game graphics or physics loop performance.

The Forza titles would appear to be running the force feedback processing in the same processing thread as their physics and/or graphics.

Should A Few Milliseconds Really Slow Forza Down That Much?

It depends how many different force feedback effects the game is using and regularly updating. Each effect utilized will add a few milliseconds of delay.

There are no industry standards that define the behavior of "canned effects" such as dampening, spring, sawtooth effect, etc.. As a result, simulation games typically won't utilize the many "canned effects" and will instead make their own calculations and sum those up into a single effect called the "constant force effect".

I have not investigated this, but it is highly likely that Forza is regularly updating a large list of canned effects, which would greatly contribute to the performance issue.

We can look back in time to games like GTR2 (which probably pre-dates the common use of a separate force feedback thread and runs force feedback in the same loop as graphics like Forza appears to) and we can see that GTR2 is not performing poorly with a proper direct drive wheel driver. The logical conclusion here is that GTR2 is not utilizing a large list of canned effects and likely has a few spare milliseconds in its game loop. The few milliseconds needed for GTR2 to update hardware in the loop is inconsequential because it has the time and performance to spare.

Possible Solutions

1. SimXperience could create a buffered driver similar to that of consumer-grade wheels. This would solve the issue with Forza, but would reduce performance for most other games because it will add lag. This would also negate the possibility of future games using a more advanced force feedback approach that requires them to know the exact state of the wheel at 500-1000Hz.
   
   

2. Microsoft could alter the driver in Windows 10/11 to not be a true hardware-in-the-loop driver and instead behave similarly to consumer-grade wheel drivers. This will also limit future innovation and reduce performance for most other games due to unneeded lag.
   
   

3. The Forza developers could take advantage of modern processors and put their force feedback code in another processing thread.  This would likely solve the Forza performance issue with proper direct drive wheel drivers and not compromise performance for other games.