Is FBA emulator input detection like the arcade?

Classic Fighting Games Super Street Fighter II Turbo
1

I noticed that it seemed stupidly hard to get ppp or kkk lariats 100% of the time through pressing 3 buttons simultaneously. I tested and confirmed that there are instances where even if you delay one of the 3 button presses by 4-8 ms (small fractions of a frame), it is still possible for the lariat to not come out. This is because I believe FBA detects inputs by just checking the button states at the edge of every frame.

Does input detection for ppp and kkk moves work similarly in the arcade version of ST? Is it so obscenely strict that even if you delay one of the inputs by a small fraction of a frame, it is still possible for you to not get the lariat? Was getting cc activation (pp+k or k+pp) that fickle in arcade SFA2?

This input detection method also has other repercussions. If you tap a button and release it in less than a frame, it is possible for FBA not to recognize that the button changed state at all. This can commonly happen when you double tap a single button quickly with two fingers. One of your button presses (that you definitely pressed!) will simply get dropped by FBA. I even got one instance where I double tapped to cause two button events and not a single button input was registered in FBA. Did arcade ST work like this? I noticed that something was wierd when I would double tap for whiff into honda hands or raging demons, and I wouldn’t get the move even though I absolutely knew I executed correctly and the button input display in button masher showed I executed correctly.

I used button masher to test inputs which detects inputs through button events rather than just testing the state of buttons on the edge of every frame.
buttonmasher can be found at https://sourceforge.net/projects/buttonmasher/
I modified the program to log at what millisecond button events were detected and to have more accurate frame counting. The original source at that site has a significant bug where the frame counter is inaccurately timed for 60 fps, although it still detects inputs sequentially well besides that.

I also used the scrolling input display for fbarr to more easily see fba’s inputs. Unfortunately, the scrolling input display seems really buggy for me and will crash often if I do any quick movements or mashing that isn’t just testing simple button presses. fbarr - FinalBurn Alpha Rerecording - Google Project Hosting

2

All I know:

Arcade: one input for each button or direction, parallel data transfer. Read once each frame.

Videogames, PCs: inputs from all buttons and directions are stored through a latch, then sent to the machine through serial transfer, then used. PCs and newer consoles will have a driver that may add extra input delay, but much shorter than a frame. I have no idea what is the transfer rate for PCs, nor if there is either a polling rate or an interrupt each time one of the inputs changes.

Unless there is some emulation inconsistency, both will check the inputs once each frame. Arcade will check in the board itself, while other plataforms will check when the latch on the controller triggers. However, one can not be sure how much time passes between the inputs are stored at the latch and when the program/game actually has access to them.

3

It’s pretty easy to confirm as well that you can do 720s too fast for FBA to pick it up using buttonmasher even though you definitely did the input correctly. The best thing is just to not do them too fast.