Linking: some statistics (long)

Classic Fighting Games Ultra Street Fighter IV
1

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.

2

Software macro programs are not reliable enough to test things that require frame perfect timing.

3

ilitirit is right about the inaccuracy of the external program. Timing in such a manner doesn’t represent or align with the game’s frames.

It is not impossible on a mechanical level.

I’d like to clarify this:

The game reads input when transitioning from one frame to another. Also, moves are executed one frame after the relevant input for them is detected. While an input may be sent timewise to different parts of a frame, it doesn’t amount to anything that affects the gameplay really. More specifically, it is NOT a programming limitation that would in any way limit the ability to do 1-frame links consistently.

Example Input Breakdown
Frame 1: A button is pressed down.
Frame 2: Said button is registered by the game.
Frame 3: The move associated with that button comes out.

4

Couple points of clarification.

  1. you are correct it is not impossible on a mechanical level.
  2. practically it is a different story.

The problem is this.

  1. A frame starts
  • Interrupt: A button is pressed down, the button then waits in the buffer for 0-17 ms depending on when in the frame it was pressed.
  1. said button is registered by the game (17ms)
  2. the move associated with that button comes out (total frame count * 17ms.)

So a 9 frame move would complete in (9 + 1)*17ms + random(0, 17)ms

So if the move completes in exactly 170ms your window to connect the link is 171 - 187 ms. (1 frame window)
If it completes in 187 ms your window to connect the link is 187 - 204ms. (also a 1 frame window.)

The only way you can reliably hit the link is if you time yourself as close to 187ms as humanly possible. The closer to 187ms you hit the link, the greater chance of the link connecting. But, for every millisecond your off, your probability drops by 1/17%.

Note: This actually does bizarre things. Like in a 2 frame link, the 100% zone is actually in the second frame.

I don’t know what the button resolution of pro players is; however, I know that I would be thoroughly impressed if someone could beat 10ms.

So assuming your hitting the 187±5ms (10ms resolution) then your probability of the link connecting is actually about 85%. (The macro is at best capable of little more then 50%.) Point is, it’s still not 100%.

Also note, I’m not talking about plinking. I know that if you are doing that right, your probability shoots to like 99.5%.

5

Well, I see what you mean there. This type of limitation comes from the inherent granularity of a 60 FPS game; I would not necessarily describe it as a programming “issue”, though. But yes, the position of the window shifts depending on when the initial button press was made. This does not mean that it would be technically impossible to time, but as you pointed out, it would require a level of timing not humanly possible in order to achieve 100%. Having said that, I’m not aware of anyone that claimed they could.

However. Relying on timing alone would imply that a person has their eyes shut and the game on mute. Visual and audial cues might enable a player to reassess the timing of a link on the fly. Keyword being “might”, lol! It is a bit of a stretch, but who knows.

6

IMO the only tough one frame links are the ones that require you to pause and manually time it, i.e s.hp after Fei’s HK CW or Ryu’s cr.hp after his solar plexus move or whatever it’s called.

The ones that have kind of a rhythm are pretty easy for your muscle memory to handle after doing it enough, like Ryu’s jab or cr.mp > sweep, Vega’s cr.lp > cr.mp or Bison’s s.lk > s.hk.

7

Anywho yea, you got it dead on Shodan. If nobody else finds this info useful then so be it. But I know for me, I’ve spent the last like 6 months thinking that the hit window of a one frame link was 17 ms. So someone like me who can reliably hit something within 20ms shouldn’t have a problem performing them in training mode at least. (Trust me, you can drive a bus through 20ms.)

Now I know that the rhythm hit window on a 1 frame is more like 5-10 ms. Which well, is waaaaaay out of my league.

I’m curious now, wonder what the Guinness book of world records says the human limit for keeping time is. I’m curious if there is anyone out there who can keep a beat with less then a 5ms discrepancy.

8

I enjoy practicing my execution. alot.
but sf4 takes it a bit too far if you ask me.

9

Really interesting info—in retrospect it makes perfect sense but I think most people (including me) never thought about it that way.

I think this might change how players practice links. If 5ms is basically impossible but 20ms is relatively easy, then consistently hitting a 1-frame link is more about consistently plinking than it is about having perfect timing. New players should practice plinking consistently before agonizing about the perfect timing of their combos. Also, if you miss a link (especially without plinking) it doesn’t necessarily mean you were too slow or too fast—maybe you just got unlucky.

BTW, your math also applies to plinking I believe, but I think a hitting a very small window on a plink should be a lot easier because it’s just a mechanical process involving finger speed instead of timing. Nevertheless, if you’re right it’s mechanically impossible to plink 100% of the time. OTOH, it seems if you get “unlucky” as far as doing a successful plink, you would get lucky as far as the combo timing. In other words, if you are mechanically perfect you can do a 1-frame link 100% of the time, but not all of these successes will show up as plinks.

Really this seems like a programming issue—shouldn’t Capcom just sample inputs 120 times per second and allow 1/2 frame leniency? (Similar to a reversal window, but applied to all inputs and only 0.5 frames instead 4 frames.)

10

It’s not really a programing issue. It’s actually a computer issue. The problem is computers are by definition discrete state systems. They are incapable of interpreting a 1/2 frame leniency. So the only way to do that would be to run the game at 120 fps, then do some weird math allowing you to double the frames and map the entire game onto a 60 frame output. Which would raise the computational power needed to run the game considerably.

And any other way around it would fundamentally change the game. (Like you could time stamp the input then skip a frame based on when it came out. However, that might cause more problems then it solves. Also, this would require you to mess with the windows clock (or one of them, there are four.) )

Anywho, the other way to theoretically practice links is to rely on visual input. The animations are naturally aligned with the game clock and therefore are immune to this variance. Unfortunately, unless you’re playing on a crt monitor, there is variance built into the output display. You can be perfectly accurate on one screen, then miss everything on another because even the good ones vary anywhere from 5-15ms. (I have two with about a 50ms difference between them but I know this community already knows about input lag.)

Also. This only applies to 1 frame links. If you work it out like I did above. 2 frame links actually have about a 17ms 100% zone (in the second frame.) and 3 frame links have a 33ms 100% hit zone (second and third frame.) In all cases, the first frame is to be avoided. So those ones you can practice without plinking. As for me, 1 frame links = plinking. I see no reason to practice otherwise.

And yea, plinking itself is a 1 frame link. However, if it succeeds and your withing the 17ms of the 100% sweet spot, your chances of hit just jumped to 100%. If your plink fails you still have a chance of the move connecting. So really plinking gives you 2 rolls of the dice. If both your plink and link are timed withing ±5ms of the sweet spot. Your chances of hitting the links are about 99.5%. (sucks to be the tournament player one the final match who loses the game because of the 0.5% probability.)

I would like to retract my word ‘impossible’ though. Somehow while working on this I got thinking about baseball. Hitting a baseball accurately at 95mph actually has smaller hit zones with much higher variance. Yet some people can do it consistently. Human ability never ceases to amaze me.

I’m not at all scared of the robot uprising.

11

Have you tried tool assisting like shown by Error1 here: [media=youtube]eWni6eDfvF0[/media] ?
I think he is much more consistent in this scripting then 50-50 you are talking about. I haven’t done it myself, but I think it is worth investigating.

12

I only watched the first few minutes, but Error1 starts off by scripting a plink, but they only show up as plinks about 60% of the time. That seems to match what Rec_rm was saying.

13

I’m actually playing around with a new clock. After some research I found that the standard windows clock actually times things at about 15 or 16 ms intervals. So my previous data is actually even worse then I thought. The new clock I’m working with actually claims a 1ms accuracy. I have no way of testing this though cause I need a clock to test a clock. However, this brings up some new ideas that I’m trying to figure out how to test.

If I was a really lazy programer. I would just use the standard windows clock to approximate 60fps. Here is the exact output of the windows clock trying to get 16ms ticks over 500ms (1/2s)

15 16 16 15 16 15 16 16 15 16 15 16 16 15 16 15 16 16 15 31 16 16 15 16 16 16 16 15 16

Notice, 29 frames. and one of them is huge. Now this IS NOT the street fighter clock, but it is an easy way to program. The absolute easiest way to time frames is to synchronize your updating with the system clock. However, 15 or 16 ms jumps actually puts you around 63 fps. So you have to add a correction every once in a while to compensate for this. Resulting in larger frames every once in a while.

(The actual system works like this. The program gives the OS a function call. Say “Run this function in 50ms.” Every ‘tick’ windows subtracts either 15 or 16ms from that. If the remaining time is 0 or less, the function is run. If it is say 1. The function is run on the next tick. So in the above example 31 represents two ‘ticks’ of the windows clock before it ran the next 16ms increment. )

I have no clue how street fighter does this correction, there are many ways to do it. However, right now I’m guessing that the actual frame size is similar to the windows system so 15 or 16ms. However, playing around has given me enough reason to believe that they can vary up to as large as 22ms. Right now I’m trying to think up a better way of measuring the frames more exactly.

PS. macros are still terrible at doing long combos, but the problem isn’t that they are not precise enough. The problem is that they are too precise.

Edit: New clock, 5ms accuracy. Crashes a lot. So interpret this with caution. Juri s.lp > c.hp 1 frame link. 20 trials for each delay. First value is delay, 2nd is how many times it connected. No plinking.

300: 0, 305: 5, 310: 6, 315: 10, 320: 15, 325: 12, 330: 9, 335: 0, 340: 1

14

I don’t understand, so your saying it’s impossible for a player to constantly get 1 frame links? Play makoto lol. Practice j.hp>mp^5 on a crouching Honda. 1 frame links seem hard cause they take effort :s (imo plinking adds to that laziness).

15

Tested this on my pstick (arduino x cthulhu setup). LP on F0, d+HP on F19 with 16666usec per frame.

Combo 39 times
Early 2 times
Late 5 times
Typo 4 times

So, almost 80% accuracy (and almost 85% timing accuracy when you ignore the typos).

I was somewhat surprised to see both early and late inputs, as most of the time I thought my pstick only varied by one frame. Visual inspection does confirm this is occurring.

One suggestion I would make, would be to use FRAPS to determine where you inputs are occurring. This might overcome the clock for a clock issue (although it may also impose an external source of lag.)

As to why the frame data for standing LP looks out, visually inspecting it LP appears to give about 8F of hit stun, which would explain why the input is later than F12.

(Thanks for giving me motivation to get off my programming ass and add the timing adjustment to my arduino sketch that I’d been meaning to do for a while :wink: )

16

Hey, just thought I would link you to this video by John Choi, showing that the cthulhu has between 1-3 frames of (variable!) lag when compared to the Eightarc/QANBA Fusion sticks, which are very likely lagless sticks. I’ve played on sticks using this board before and have noticed a definite amount of delay, similar to the delay between PS3 and 360 variants of Capcom fighters (2F) or slightly worse.
[media=youtube]E-Y0zFIvcPE[/media]

So your variance in results may be due to the variable delay on the cthulhu and not necessarily on the precision of your stick itself.