Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

16 New Car Smell

Gaming Setup

  • Platforms
  • Peripherals
    Steering Wheel

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @PJTierney I guess it's a complete coincidence that you resolved this long-standing bug within weeks of the DirtFix research, which detailed the underlying cause. I mean, otherwise you might have had to credit the author in some way.
  2. I fixed that in v1.3. Hot-plugging a controller temporarily re-enables the input polling so you can add or remove controllers in the game.
  3. @dougietodd: have you tried DirtFix? It should give the same benefits without having to unplug anything. It's not a Codemasters utility (I wrote it), but search around for comments from other users if you're unsure.
  4. @PJTierney I've written up some notes detailing why the input polling is causing the games to glitch. TLDR: a dinput8 critical section is stalling the main thread during message processing.
  5. If you experienced a crash with DirtFix v1.1, please try the new v1.2 release. This should resolve it.
  6. Glad to hear it's working for at least some people 🙂 Hopefully it's enough to get the polling changed in the original games -- ideally only reacting to PnP notifications instead of polling all the time. I saw some reports on Reddit of the utility causing the game to crash on startup. If that happens just uncheck the game to disable the fix for that game. I'd also be interested in any details you can provide of the crash, and I'll see what I can do to fix it.
  7. For other games to be affected they'd need to perform the same periodic input device polling, and I believe many games wait for PnP notifications before they look for changes. The DiRT games are only affected by the presence of game controller input devices, as that's the type they're looking for. I don't remember the problem always existing, so it's possible a change in Windows (10?) or the Steam overlay has introduced it. When I get a chance I'll dig into it further.
  8. I uploaded DirtFix v1.1 a couple of hours ago, and that's now been tested with DR, DR 2.0 and D4. Could you please try the update? v1.0 didn't work with DR 2.0 as it's a 64-bit app, and the first version only worked with 32-bit apps. I finally bought DR 2.0 to test it myself so I've seen it's active. It fixes my input-related glitches, and I hope the update works for others too.
  9. As discussed in the current VR thread, I've been having similar input glitch issues in Dirt Rally 1 that I've managed to work around. I've created a small utility that fixes it for me, and I'd be interested to know if it works for any of you too. Run the installer, then click OK to accept the default delay of zero. From that point just run Dirt Rally as normal and see if it's any better. It suspends the background polling that checks whether any game controllers have been added or removed, which is what seems to causes the spikes in CPU usage. I've only tested with Dirt Rally 1 (drt.exe), but I'm hoping that Dirt Rally 2.0 uses a similar mechanism so it also watched for when "dirtrally2.exe" is launched too. If someone can confirm the executable name for Dirt 4 I could try adding that too. Edit: oops, fixed links to be public.
  10. Yes, switching off my wheel clears the performance spikes. If I switch it back on I see a flurry of activity at the time I hear the device arrival notification, and the spikes return. I get the same behaviour switching my USB HOTAS on and off too. That's to be expected as the IDirectInput8::EnumDevices call the game makes passes DI8DEVCLASS_GAMECTRL, which is asking only for game controller devices. The DR2 performance graph posted in the previous thread looks suspiciously similar to what I'm seeing in DR1, so I suspect it's the same problem. I might have to pick up the new game early to check it here. In the meantime I'm going to keep looking into why/how the background input thread processing is hurting game performance.
  11. I have the 2 second stutter issue in the original Dirt Rally, which I've tracked down to it polling for new input devices. I suspect it could be the same in Dirt Rally 2.0, which I don't yet own, but I've been keeping a close eye on for VR. I'm using Windows 10 x64 v1903 with a Valve Index HMD and the current SteamVR beta. I captured a CPU snapshot of the spikes seen in the SteamVR Frame Timing window. That showed the activity was a call to DINPUT8!EnumDevices, which came from drt.exe via the Steam overlay hooks in GameOverlayRenderer.dll. Back in drt.exe it was sleeping for 2000ms and then looping back round to enumerate input devices, presumably to check if any new controllers had been plugged in. Editing the 2 second sleep to 10 second changed the frequency of the CPU spikes in the timing window, confirming it to be the source. Why it stalls everything so badly isn't currently known, but is probably a shared lock somewhere. Could someone in the development team check if it's the same issue with DR2? Ideally, could that thread only be polling in the menus and when the game is paused? If I get a chance I might knock up a utility to disable the device enumeration a minute after startup. Edit: For a quick test on the original Dirt Rally I've just hex-edited drt.exe and changed the sequence FF 68 D0 07 00 00 FF to FF 68 D0 07 00 01 FF. That causes it to enumerate devices only once and then sleep for a loooong time. As long as my wheel/pedals/shifter are plugged in when the game is started it's fine, and the game no longer glitches. It may be a different instruction pattern in DR2, and any module changes could trigger anti-cheat protection, so experiment at your own risk!