So me and a friend has a bit of a discussion about linking. In particular the ever difficult 1 frame links. The argument was whether or not it was possible to (without plinking or any other form of aid) get 1 frame links 100% of the time. I have spent enough time working with games, screens, and input commands on a few other projects to understand that this is absolutely impossible, however, argument alone is not enough to get my point across. So I ran an experiment.
I play Juri, and she has a few fairly links that I tested here.
s.lp, c.hp (1 frame link)
s.lp, s.hp (2 frame link)
s.lp, sc.mp (3 frame link)
- all of these assume the frame on this site is correct.
** after testing, I’m confident the s.lp frame data is not. I’ll explain later.
I tested this on the PC version of SSF4:AE, my benchmark runs at about 100 fps.
I used a Macro program called AutoHotkey (since there are some people on here who have strong feelings about Macro’s I won’t be posting the script I used.)
The theory behind linking is that there are these entities called frames, and if you press the right button on the right frame your move will connect. The game is supposed to run at 60 fps so that gives 1000ms/60 about 16.66 ms a frame. (17 is good enough). This means that there should be a 17ms time period that you can press a button and get a 100% chance of connecting a 1 frame link.
The macro program is set to perform the s.lp then wait a certain period of time before performing the second move. I varied this delay between 240ms (~14 frames) and 330ms (~20 frames) for each link. Each link was automatically performed 20 times, and I recorded how many of them actually connected. (frame data claims full animation of s.lp is 12 frames. If I’m reading it right.)
Here are my results.
I hope they make sense. But the first thing you will notice is that there isn’t this magical point where every single move will connect every time. In reality the moves form a distribution. Almost nothing connects before 260ms (~16 frames, which makes me suspect the full animation of s.lp is actually 15 or 16 frames.) Then there is about a 20ms (~1 frame) “fuzzy area” where moves have a roughly 50-50 chance of success. This fuzzy area exists both at the beginning and the end of the distribution. (Standard game design practices put this grey area at about one game loop, which we might call a frame.)
The reason for this is simple. The problem is this 17ms time period has a distinctly random element to it.
The game stores inputs as you press buttons. But only executes those inputs whenever it updates the game, which is 60 times a second. If you input a command just as the frames update, the game won’t recognize the command till the next frame update. However, if you input the command right before the frame updates, your command will be executed right away. This results in about a 17ms (1 frame) variance depending on how synchronized your command is to the game loop.
So if your hit zone is 17ms, and there is a random variance of 17ms. Your chances of connecting are roughly 50-50.
This is not a hardware issue (although, actual lag will make things worse.) This is a programing issue. There are ways around it which could possibly be implemented if the hardware was known ahead of time. (such as running the game faster then 60fps.) But unless someone knows how to put a macro program onto an arcade machine, It can’t be tested. Anywho, that is it for now.