Sonic UltraSaturn low fps/slowness new working workaround

[Jobima1st]

dont know if this getting better because of last hidhide fixes of PadForge, but seems I find another (better) fix that make me use Virtual Xbox 360 Controller of PadForge aside from the old #350 (reply in thread) fix that dont let me use any Virtual Controller anyway

for now I only test with bluetooth, and the fix is:- start PadForge with Virtual x360 then start the game (it will be slow) then switch to Virtual dualsense in PadForge and you will see the game is work fine now but you cant control it, now switch back to Virtual x360 and it will not be slow! and you can control it!

@hifihedgehog any idea why? and if that finding can help fix the problem from the root?

the game is free and portable (just extract) and can be downloaded from https://www.sonicfangameshq.com/forums/showcase/sonic-ultrasaturn.2059

[Jobima1st]

and this can be partially automated using profiles

[hifihedgehog]

[Jobima1st]

thank you!

anyway, maybe other games will get the same problem so this discussion can help, until windows 11 is fixed (if ever since its microslop)

[hifihedgehog]

@Jobima1st The game is the cause, and this replaces my earlier answer, which named the wrong mechanism. I ran Sonic UltraSaturn on the bench tonight with a frame-time recorder and an API trace attached to it. Here is what it does.

The game polls a joystick that is not there, every frame. Sonic UltraSaturn is a GameMaker build, and its runtime calls the old Windows joystick function joyGetPosEx for joystick ids 0 and 1 on every frame. Both ids come back "unplugged" whatever controller is connected, virtual or real. Windows answers an unplugged id by re-scanning every HID device on the machine: a device enumeration, an open on each HID interface, descriptor reads, and the DirectInput calibration registry keys for each device. In the trace that was 60 to 300 full scans per second. That is the game's baseline cost and it happens with a real pad alone too.

Two devices with one identity make it collapse. The pair can be physical or virtual, in any combination: two of the same pad plugged in, one pad connected over USB and Bluetooth at once, or a virtual pad of the same model as a real one that is also connected. When two HID devices share the same vendor and product id, that per-call scan leaves a calibration registry key open for every device it visits, about twenty per call. The game's open handle count climbs by over a thousand a second, every later scan gets slower, and it settles at 5 frames per second. The game I traced had passed one million leaked registry handles. Measured on the same bench, minutes apart:

Virtual pad present alongside a real Xbox pad	Handle growth
None	flat
Virtual Xbox 360	flat
Virtual Xbox Elite Series 2	flat
Virtual Xbox Series (same id as the real pad)	+1,200 per second, 5 fps

The virtual and real Xbox Series pads share one identity, so that row is the pair. The other two rows have a virtual pad of a different identity beside the same real pad, and nothing leaks.

Why your workaround works. Your DualSense on USB and Bluetooth at once is two devices with one id, the double link from #384. Switching the slot to Virtual DualSense drops the radio link, the pair is gone, and switching back stays fast because the pair does not come back. Reopening PadForge without the pad removes the pair the same way. The next build carries the #387 fix, which drops the radio link on its own whenever the USB link builds.

What is and is not fixable here. The per-frame joystick polling and the registry leak it drives are in the game's runtime and in Windows. No controller tool can change what the game does with an unplugged joystick id every frame, so the fix belongs with the game's developer, who can rebuild on a current GameMaker runtime or stop using the legacy joystick functions. On your side, one controller identity at a time keeps the game out of the leaking path, and the next build takes care of the USB plus Bluetooth case for you.