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

    FPS & Stuttering (PC, non-VR)

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

    FPS & Stuttering (PC, non-VR)

    @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.
  3. 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.
  4. 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!