Starting with Hyper Fighting and Super Turbo, most Capcom fighting games have supported accelerated game speed settings. Since all Capcom titles already display 60 frames per second on the screen and sample controller inputs at a refresh rate of 60 frames per second, turbo speeds are implemented by skipping over frames. Increasing the frame rate would be impossible because most televisions wouldn’t support it.
Taking Capcom Fighting Evolution as an example, every frame is drawn and shown on the screen at the lowest game speed setting. Every 60 internal frames, the overhead match clock counts down one second.
Increasing the speed setting does not increase the number of frames shown per second, but rather causes internal frames to skip at regular intervals. At speed two, 1 frame skips for every 6 frames shown. At speed three, which is the default speed, 1 frame skips for every 4 frames shown. 1 frame skips for every 3 frames shown at speed four and 1 frame skips for every 2 frames shown at the maximum speed of five.
The game engine does not skip over frames internally, so an attack with one more startup than another will not suddenly trade with the faster attack if the game skips over its first active frame. Instead, the first active frame will not be shown, but the following frame will show the second impact frame with the faster attack winning cleanly. In other words, CFE runs at an internal speed of 75 frames per second on speed three.
Unfortunately, the game skips over input opportunities as it skips over frames. Therefore, some extremely difficult combos become impossible at higher speeds if the window to perform the follow-up happens to land on a skipped frame.
Normally this isn’t a problem for cancels because impact freeze provides a large margin of error. It’s usually not a problem for reversal timing either, because almost all Capcom games have a 2-frame reversal window which can narrow to 1 frame but never disappears. However, high turbo speeds wreak utter havoc on 1-frame links and other combo components requiring 1-frame input accuracy.
Some older games make combo life even more difficult by not following regular frameskip patterns. Hyper Fighting is an absolute nightmare because it has no base speed setting and frameskip fluctuates randomly at turbo speed. Sometimes a little variance can be helpful to combo video makers because it means more chances to bypass limitations, but Hyper Fighting runs so fast and skips so many frames that it feels like pure chaos. Surprisingly enough, this contributes to solid gameplay because it hinders the practicality of overpowered combos.
Increasing game speed also causes every game’s overhead match clock to count down faster, but of course the game displays 60 frames per real-time second regardless. Thus, the game clock only counts down using real-time seconds when using the non-turbo speed setting. (Hyper Fighting seconds aren’t real seconds, nor are CFE seconds at speeds above one.)
Apologies to anyone who was expecting the SF4 Gouken TACV today, but as i mentioned before, it won’t be done until next Tuesday at the earliest.
glad you talked about this, I don’t think many people outside the tool assisted combo makers know about it
ever since reading the SF2 randomness article forever ago i’ve wondered why turbo worked this way. wouldnt it be more efficient and keep every frame intact if the game simply moved faster, instead of cramming more frames into a second? for example, program the game where characters move at 100% speed on normal, 110% on turbo 1, etc.
then the game speeds up without any lost frames, right?
Even if Capcom somehow got a Dreamcast to output 66fps, your TV wouldn’t know what to do with the signal. That’s all standardized by international conventions. Nowadays there are more formats than there were in the days of interlaced NTSC, but even now you couldn’t increment frame rate like that.
input can be sampled at much higher speed to compensate the shorter input window.
i am not sure with the cps1 system. i bet cps2 is capable of fixing the problem.
Interesting read. Never knew that!
“…At speed two, 1 frame skips for every 6 frames shown. At speed three, which is the default speed, 1 frame skips for every 4 frames shown. 1 frame skips for every 3 frames shown at speed four and 1 frame skips for every 2 frames shown at the maximum speed of five…”
Does CFE really speed up that much? The speed changes you’re suggesting would make the game unplayable over some of the range. (In HDR the steps – besides the 0-1 step – correspond to an additional frame skipped per 32 shown and the skip pattern has a period that’s a factor of 32.)
“Unfortunately, the game skips over input opportunities as it skips over frames. Therefore, some extremely difficult combos become impossible at higher speeds if the window to perform the follow-up happens to land on a skipped frame.”
That seems implausible to me because dropping the ‘back’ command would cause characters to loose their charge. (It should also be technically easier to do turbo without dropping input.) Is it possible that the dropped input is caused by the controller loosing sync with the virtual frame rate?
You wouldn’t drop the back command, when the frame is skipped it’s like it was never there, so it’s still like you keep holding back continuously.
But when you’re doing a combo with a 1-or 2-frame window for an input and the frame where you’re supposed to make the input happens to get skipped, that’s when it gets in the way.
this affects gameplay in marvel, it’s why dr. doom’s sweep is unblockable sometimes
If you do that (like projectile slowdown does) then you end up doing very bad things for charge times unless you specially code those. It’s certainly possible, but it seems like it would be *much* easier to just run the game engine faster, and simply ignore the extra frames.
“Increasing the frame rate would be impossible because most televisions wouldn’t support it.”
But hey Maj (or anyone with the knowledge), could you confirm the window for reversals in SFIV? Is it also 2 frames?
great read as always
zero: Maybe it can work that way but the fact is it doesn’t work that way and there’s no way to change it unless you want to go back and hack the games, which probably isn’t easy because HDR would’ve done it.
Rufus: Yes, CFE speeds up that much and HDR is even faster. Held inputs are special because the game considers them held over skipped frames until you release it on a non-skipped frame. That solves the problems of blocking, charging, and holding buttons for specials like Rog’s TAP. Yes, very bad things happen when you skip frames, but they dealt with those problems by adding input leniency on cancels and reversals. Links and wakeup normal throws get affected the most. Chains too, but only if you’re trying to combo 8 jabs or something.
Bob Sagat: Let’s be careful how we’re phrasing this. The skipped frame doesn’t get lost. It’s still there and any interactions that occur during the skipped frame still count. It’s just not shown on the screen and you don’t get to input commands during it (with the exception of held commands being maintained as explained above).
Hope: Reversals in SF4 have a huge buffer window of 7+ frames. Sometimes it feels like over 10 frames. Plus SF4 doesn’t have speed settings so skipped frames aren’t a problem.
I’ve asked myself this question too and i don’t have a 100% definitive answer for all systems/titles, but my feeling is that the answer is no.
I know for a fact that turbo speeds skip display frames because you can go frame by frame using emulators and clearly see missing frames. Same thing with captured footage.
The input question is a little more tricky because if a game were to speed up its sampling rate, that wouldn’t change the output rate of a programmable controller. It would seem like frames are missing but maybe the controller is just out of sync with the game. However, i don’t think that’s the case because it also happens with all emulators i’ve ever tried, even when pausing and advancing frame by frame.
Like i said before, most things work fine even under extreme turbo settings. HF is arguably the best SF game ever and it’s skipping frames all over the place. It’s very easy for me to imagine Capcom (or any other game developer) saying, “Sucks we gotta do this but it works fine 98% of the time so ship it.”
i think you misunderstood me, maj. i mean speed the game up without increasing frame rate above 60 FPS. is that possible at all? or is it like running, its impossible to go faster without increasing your heart rate?
You mean write up completely separate sets of frame data for each turbo speed? I don’t know, that’s bordering on five different games for five different speeds. Sounds confusing to say the least. (And seems like too much work on their part cuz they’d have to test each one for balance separately too.)
fffffffffuuuuuuuuuuu… us scrubs tend to forget about frame data :p
Great article Maj. Technical, but important and enlightening.
7+ frames for reversal? That’s huge. it’s a pity there aren’t any reversal only moves in sf4.
do you really mean the reversal window? not the input window?
Um, i’m not sure what the difference is between reversal window and input window. But yeah, reversals are easy mode in SF4.
@N00b_Saib0t
NTSC Televisions aren’t set up to display more than 60 frames (fields, really) per second. So, even if you run the game faster, your TV won’t be able to display the frames. In theory it’s quite easy to run the game at more than 60 frames per second (i.e. overclock the game), and only send the most recently generated one when the next one is due. Something like this:
Normal Speed – the game and display each produce a frame every 5th tick.
1….2….3….4….5….6….7….8….9 (game)
1….2….3….4….5….6….7….8….9 (display)
Sped up – the game now produces a frame every 4th tick
1…2…3…4…5…6…7…8…9…0…1 (game)
1….2….3….4….6….7….8….9….1 (display)
The display is now not showing frames 5 and 10. (I think that this is the way that turbo works.)
This sort of speed up is probably easier to implement than one that keeps the input intervals at 60 per second. (Input sampling can trivially happen at higher speeds.) This sort of thing happens frequently. for example, with emulators that can’t display all of the frames the game generates.
An emulator’s frame-by-frame feature would ostensibly be hooked to the display v-sync that the game produces, so it too could be skipping frames 5 and 10. That said, it appears that something like AutoIt can send inputs at a faster pace and would allow testing of the hypothesis. (Although that also means testing the game’s effective sampling rate.)
@Rufus
Looks like the forum software doesn’t support pre tags.
Maj,
For combo video purposes with the 1 frame links, why not just execute at the native normal speed and then run a similar algorithm on the resulting video? Delete a frame every X frames to match the turbo speed you want.
Rufus: So … can you verify that theory?
image: That would work but it’s borderline cheating and sooner or later you’re bound to produce a combo with an input configuration that’s absolutely impossible at turbo speed. Then someone will call you out on it and your reputation will be screwed. Obviously people prefer seeing default speed combos over slowest speed combos, but i think the much bigger reason to stick with turbo speed is to prove that you can overcome the frameskipping obstacle for that particular combo. Otherwise you’re better off going with normal speed and ignoring the one or two minor complaints you’ll get.
@Maj
Assuming that’s directed at me – I don’t have an emulator setup at the moment. I’ll look into it.
@rufus
You weren’t saying anything I don’t already know, and you’re missing my point. Leave it at 60 fps, just make everything faster. As maj pointed out to me, this would require frame data for each individual turbo speed. I mean there are games with only one speed that are faster than sf4 that are only 60 fps, its entirely possible to do (isn’t sf3 faster with only one game speed?) But to have multiple game speeds without just making the frame rate faster is too much work.
No fair, you get to edit, and I don’t. ;)
FWIW In all of my testing, the display frame skipping in HDR is periodic:
Turbo 0: Skips no frame ~60 fps.
Turbo 1: Skips frames 1, 7 and 13 out of 19. ~71 fps
Turbo 2: Skips frames 1, 7, 13, 18, 24, 29 and 35 out of 39. ~ 73 fps. – this is probaby
Turbo 3: Skips every 5th frame. ~75 fps
Turbo 4: Skips frames 1,6,11,15,20,24,29,33, and 38 of every 41 frames. ~77 fps.
You’re probably already aware that television displays at 30 frames per second interlaced – each of the game frames corresponds to one of the fields.
With projectile slowdown, the frame doubling occurs before the frame skipping. (This is consistent with both the hypotheses — input dropping and sampling rate changes.)
Sorry about the editing thing. I know it’s annoying but comment editing is disabled by default and i couldn’t possibly keep track of everything if i enabled it. You’d be surprised how much spam this place gets already. The last thing i need is people being clever and posting relevant shit then going back and editing comments to add links to whatever annoying thing they’re trying to pimp out.
But yeah, projectile slowdown doesn’t support either scenario. The only way to prove that the game is increasing the input sampling rate instead of skipping frames is by doing something that should technically be impossible with frame skipping. It’s hard enough to think of something that qualifies, but executing it with 100% accuracy so you can actually test it is even harder. All i can say is good luck.
Btw all that CFE data was gathered while i was working on the CFE Official Fighter’s Guide. The game would skip frames on turbo speeds even when i was frame stepping. That’s why i think i’m right about this, but it might be different in other games, although Capcom tends to be consistent about these things across entire series.
@Maj
With sub-frame programmable input it should be possible to work out with tight link timing failure frequencies.
Out of curiosity,did you see interlacing artifacts while frame stepping?
@Rufus
Hmm, thinking a bit more on this – I’ll test if direction switching is instantaneous in HDR, if it is, then it should be possible to do the following test with a programmable controller:
Set the game to Turbo 3, and select Zangief:
Go forward for 3 frames
Go backward for 5 frames
(repeat)
If the game ‘overclocks’, and walking switches instantaneously, then he should oscillate, but stay in place. Since the number of shown frames is divisible by 4, if the game is duping the input for a frame and skipping, then it should steadily move him forward or backward.
Sub-frame programmable input would be the direct way of testing, but you’d basically have to build your own programmable controller to do it. And no, every frame was clear in CFE.
How do you know that Gief travels the same distance in 3 forward walking frames as he does in 5 backward walking frames?
It *could* be different in HDR, but T.Akiba’s walking speeds are here:
http://nki.combovideos.com/data.html
Obviously, this is testable by using Turbo 0.
Okay so assuming that’s accurate, wouldn’t you have to hold F for 2.4 frames and hold B for 4 frames at turbo 3?
Cuz if your programmable controller outputs commands at 60 per second, and you need 3F/5B at turbo 0 running at 60 true fps, then you’d need 2.4F/4B at turbo 3 running at 75 true fps, right?
3F/5B at turbo 3 is equivalent to 3.75F/6.25B at turbo 0.
@Maj
That’s the gist of it.
If the game is overclocked then, over the course of 40 ‘game frames’ there should be 15 forward frames and 25 backward frames – which should still be 0 net movement.
On the other hand, if the game is reading 4 full frames, and then duping input from the 4th to the 5th, then over 40 logical frames, there should either be 12 forward and 28 backward, or 16 forward and 24 backward moving ones – either of which leads to net movement – depending on where in the 5-3 cycle the duping is taking place.
Hmm it would give better signal to noise to use Blanka and do:
(backward)x4 (forward backward)*20
Which is a 44 real frame loop that should be net neutral with overclocking, and should give a net speed of +/- 330 if the game does input duping with a period of 4.
@Rufus
er… as speed +/- 7.5 per frame.
Something I’ve been wondering, a few people said that SSF4 feels faster than SF4, so if they simply increase the speed of everything, that would mean that all the current one frame links are gone right?
Also, with CFJ were you able to use frame stepping? Is that like a standard feature on debug consoles? (where can I get one?! lol)
Rufus: But your whole hypothesis is that the problem of skipped input frames lies in the programmable controller / emulator, not the game. If that’s the case then fractional frames will give you screwed up results without proving anything. You need to find test numbers that at least convert back to integers when you go from turbo to normal.
CPS2: The only way all one-frame links would be completely gone is like if the game is skipping every other frame and the first attack’s total frame count is odd. But the problem doesn’t come from speeding up the game. They can create a new base speed and adjust all frame data so that nothing skips (although there might be some changes because they’ll have to round off or otherwise adjust numbers). The problem is having a base speed that runs at max framerate and then putting turbo speeds on top of that. Regarding CFE, it was the disc that was special. It was a beta build that let you pause/unpause by pressing L3 then increment frames by pressing R3 (or vice versa, can’t remember).
Yeah. thought about it some more, and realized I need to turn down the stupid.
input sampling rate can not be tested via emulators. much has changed due to the difference between computer and cps. ps/2 keyboard sampled at 125Hz. and usb sampled at 1000Hz. I have no idea about how fast cps samples input.
@CPS2 I think they just make it feel faster by making focus quicker and walk and jump speed faster, I would be suprised if they made all the moves faster or removed frames.
So, I’ve done some testing, and XBox HDR seems to sample 60 input times per second regardless of the turbo setting.
Cool, thanks for going through the trouble of testing that. Mind sharing the details of your experiment?
I realized that I had a microcontroller that could be powered by the +5V that my SE stick gets from the XBox. The SE stick also uses a system where pushing a button or direction pulls a pin down internally, so adding a programmable interface was quite easy with stuff I had lying around.
I spend some time tinkering with a couple of other approaches, but ended up with a set-up where it was (effectively) hitting jab for about 1/125 of a second, then pausing and then repeating. On the same cycle, I had a pin that was being hit for 1/20 of a second.
With that set up, I ran the game on speed 0, and then speed 4, and looked at how often it missed or detected the 1/125 second pulse. If sampling rates go up with the turbo setting and are 60Hz at turbo 0, then they should be 77 Hz at turbo 4, so the rate of detection should be better at higher turbo settings.
I only did a small number of runs, so I might need to go back to make sure… but…
Running a round at Turbo 0, there were 55-56 pulses per round, and the game detected 27-29 of them.
Running a round at Turbo 4, there were 44 pulses per round, and the game detected 22 of them.
If the game did, indeed have faster sampling at higher turbo settings, then it would be expected to detect around 27 of the 44 pulses at turbo 4. I did run several rounds, so the difference is outside the 90% confidence interval.
@Rufus
This also suggests that ‘just frame’ links will have a 20% failure rate at Turbo 3 even with perfect execution. (Theory suggests those ‘just frame links’ might be cr MK -> standing far MP with Blanka or Guile which should only work if the Mk is the first hit of a combo.)
Sounds about right. In CvS2, you could record an input sequence in Training Mode like in SF4. If you recorded a successful one-frame link on default turbo speed, it would mess up on playback about a quarter of the time.