totallybion.blogg.se

1. #Input delay smash ultimate how to#
2. #Input delay smash ultimate driver#
3. #Input delay smash ultimate code#
4. #Input delay smash ultimate windows#

This is the case of WinUSB (& libusbK), the driver used for Gamecube to USB adapters. There's a catch to the current implementation though: since the detection of major changes in controller state is done in response to a change in the stage, it works naturally well with devices that use a USB driver for which the mode of operation is to be notified a communication happened. I made a video explaining it more in details: This is what led to Kristal, a fork of Slippi optimized for long-distance netplay, using this netcode variation I just described, that I dubbed "subframe rollback netcode".

So I thought, why not change this ? And while we're at it, why not send important inputs that happen at any time between one frame and the next, so that if this input makes it in time, but the state of the next frame wouldn't have, this input doesn't wait an extra frame to be shown on the opponent's screen ? If we know, on average, 1.6ms before the next frame occurs what we're going to use for the next frame, then how about just sending it right now ? But that wasn't an option with the architecture in place: the game engine and netcode were tightly coupled, so that messages were only sent when a frame was built, with the inputs for that frame (and recent frames too). Using slightly old inputs on your end is one thing, sending slightly old inputs to your opponent is another: it's stupid. This added 1.6ms.Īnd that annoyed me a lot. Of course, doing anything but always sending the latest controller state you know about adds lag. This led to the Timing Dispersion Reduction developments, enhancements to Slippi (development started for Faster Melee - Slippi wasn't a thing yet) that fixed this, by adding a middleman between the game engine and the polling thread that fed the game engine inputs cherry-picked to be 16.67ms apart. Of course having frames that are 15 or 18ms long is a problem, as inputs done 16.67ms apart are no longer guaranteed to end up 1 frame apart. This, combined with possibly variable time taken between the emulator "waking up" and reading the controller state results in this:

#Input delay smash ultimate windows#

Windows is not a real time OS, and so asking to be woken up every 1/59.94s results in you being woken up approximately at that frequency. The main culprit was the fact that emulator frames don't actually last 1/59.94s. Adapter OC only did 90% or so of the improvement it should've done - which is already a lot, but I wouldn't be satisfied with reaching anything but what could be proven to be unimprovable on. Unfortunately, the input integrity on emulated Melee was still not as good as my models said it should be. This, along with my studies on what adapters (and adapter ports.) resulted in my writing the Adapter overclocking guide, which is now a setup step in all Slippi installation guides. As I inquired online about driver specifics, Sweetlow found my questions and reached out to me about HIDUSBF, which was precisely what I was trying to build. After learning the intricacies of USB, I looked into writing a driver that would oversample USB adapters. This kinda ended my already dwindling will to compete and I set out to fix this.

#Input delay smash ultimate how to#

I long searched why and how to fix it, but it would take a lot longer for me to figure that out.įirst, I quickly realized Melee emulation had the same kind of issues, which, aside from making the game feel bad, also meant player learning on PC would be fed wrong feedback during training i.e, be told they're too late when they're too early or vice versa, be told they're too early or late when they had the right timing, be told they had the right timing when they were more than a frame length off. That didn't work out (a video I took back then: ) due to the input integrity problems mentionned previously.

#Input delay smash ultimate code#

You'd define input sequences (with randomness, rumble triggers.) in a custom lightweight language (that I was going to call Commedia !) that would get transpiled to Arduino code to upload to an Arduino for it to spoof a Gamecube controller and run that, by holding each input it's supposed to do a frame, for 16.67ms. When Smash Ultimate released, I tried building a TAS-bot for people to train and explore mechanics with. I played competitively on it for years, in fact I got PRd in my country in 2019.ĭesigning and building this was a lot of fun (and saved me from the index finger-pain I had from using claw grip on Melee Peach), so I figured I'd keep going. It was one of the first digital controller for Smash to exist, and used a unique, non-modifier based way of converting key presses to game controller states, though that's a story for another time.