So fun fact, there's a modern fighting game that uses this exact kind of frame skip: Skullgirls. You can see in early footage that the game originally ran much slower. They implemented frame skip in response to feedback asking for the game to be sped up. I know several different values were tested and in the end the game ended up quite a bit faster, and with frame by frame playback you should be able to see certain moves skipping frames occasionally. No clue how they avoided the issues with 1 frame inputs etc, might be cool to look into
lol thanks for the plug! I just saw the video and tweeted about it too. Lemme go find out how our frameskip works 🤔 Also incredible work, Veri7as! So awesome that you went so deep and solved this decades long mystery, and even cleared up an official blog post!
Just found out how our frameskip works: we skip every 5th frame! I think I remember back in the day that we tried testing a variety of different frameskip patterns but this one felt/looked the best and is 20% faster than our original speeds.
Edit: Had some free time and checked SFA3. In the rendering subroutine there is a copy paste of the input taking code that it branches to when it is on a skipped frame before it returns, so at some point between SFA2 and SFA3 they did fix this bug. Edit 2: got Kyle to check out vsav and he found that it is the same as SFA2 (misses inputs). It's been several years but I remember that when reverse engineering a few cps2 games that in vsav the input skip during frame skips was fixed. I also remember the skipped inputs existing in SFA3 and Jed has told me they used the same engine, so I don't entirely trust my memory. If it was fixed in vsav though that would explain why the article thinks that it didn't skip inputs though. You might be interested in checking that out.
@@disdownloadnetvictim Yeah it certainly could have been fixed in the console ports, but I don't know if they were. I'd doubt it though since it wasn't fixed for MVC2 and or any of the other games I know that have easy ways to check for it.
@@nodthenbow as far as ST for dreamcast goes, the stage speed bug was fixed afaik so i'm curious about it. I wonder if there were any changes in zero 2 alpha / alpha 2 gold as well.
This video is NICE. Ive read those articles on frameskip in the past, but its nice to see someone get down to the gritty details of it for once. PLEASE do not be afraid to go DEEP with the code talk in future content! I would love to hear more about how these games function. Even for a casual watcher like me, that stuff is very fascinating, and showing off examples of the code in action and its implications really helps make it easy to digest. It seems like this video is somewhat of a first for your channel, I hope to see much more from you, I think you've got something unique in the fighting game content space here.
Wow! Thank you for diving into the code so thoroughly! I've been fascinated by Capcom turbo modes for a while and a few years back I was completely obsessed with a VSav turbo 3 combo (Sako special) and was convinced that at least on the latest console ports, that the 3,3,3 skip was causing this pattern of a 50% failure since it hinged on a double frame perfect input (2 on, 2 off), which just so happened to be exactly spaced when non-turbo'd so that the 1st skipped frame covered 2nd possible frame as well, when trying to account for the 1st one. On Twitter when talking about Turbo, Damdai linked to that seminar article you mentioned, and after reading it I was sure either it was either incorrect or that the emulation wasn't doing something correctly. After some time I was finally able to try VSav on a cab at Turbo 3 and had what felt like marginally more success with the combo, I chalked it up purely to the tiny speed difference in the games Hz, since consoles and emulators mostly seem locked to 59.94/60, vs arcade hardware which generally ran a bit slower, and can fluctuate based on stage/effects and such. I hope this video is the nail in the coffin, or leads to further dissection of hardware/emulator adjustments if needed. Thanks for the hard work!
It's actually kinda insane that it's been almost 3 decades since Street Fighter 2 Turbo allowed you to select your speed, and it's only now that someone actually looked into the code of these games to see how works. There really is a large gap in code-level knowledge of how fighting games in general function, especially here in the youtube-sphere. Simply fantastic video Veri7as! I hope one day this can explode in views, and we can see more stuff like it. It really helps to pull back that "mistique" you mention in the closing section Cheers
This was great! Very in depth, the amount of time and patience it must take to dig through this code and figure out what is happening is truly impressive. To then managing to clearly and simply explain all of this with illustration is top tier skill, it’s up there with Displaced gamers work which I enjoy for the same reasons.
>passion project with hundreds of hours of work 700 subs, 5K views >"SooOoO Uh GuYs i MaDe tHiS ViDeO tO ShOw yOu My 8 MiLLioN DoLLaR HoUse" 700 million subs, and more views than there are people on the planet
21:48 Crossing up charge characters when they are charging counts as two inputs for them. This means one can activate a super when the opponent crosses you up by simply releasing the charge state and then pressing diagonal + up. In the case of Charlie, this will activate Somersault Justice and for Chun-Li, Hazan Tensho Kyaku.
When I saw this video pop up I was working myself up to have to counter a bunch of "ingrained community wisdom", but you've covered the topic well. That skillsmith capcom blog article about the turbo frameskipping was a crucial turning point on the subject. I wonder if the SF2 series games don't have this 'doubling input' issue that A2 does - or indeed if A3 uses the same input parsing/skipping behaviour. There are people still creating input playback, emulator based tools which use the display frame count to trigger inputs, which is potentially not sufficient! Thank you for the research and video. I'd be interested in how the "unblockable" blanka ball/tiger uppercuts work in SF2HF too. BTW I make a cameo appearance at 3:39 in the video :D
Very cool. Back in the day I honestly thought capcom had just manually adjusted frame counts of each animation for every speed setting. Which in turn made me wonder what type of a calculation they used to figure out how to add or subtract frames to keep everything feeling consistent.
Been romhacking for over a year, and it's so viscerally great to see more people doing it, code and all. This is the most legit dissection i've seen on YT, love it to bits. Please do more! I vote "How Capcom games drew sprites to the screen", have a bunch of notes should ya choose to look in to it
We need more videos like this, really informative and indepth and fun to watch and follow. I did not have a degree on computer science but even my monkey brain was abel to follow. awesome video.
Great video. Would it be possible to get another that details how difficulty settings work in the SF series? I was interested to learn about the losing player in round 1 getting a damage boost in round 2, as even as a kid I noticed that if I lost round 1 the CPU would seem to go easy on me for a while then kick my ass in round 3. I'm curious what other changes happen though - does the game get easier after a set number of continues - I know this happens in 3S when losing to Gill but is it true for the other games or characters too? Something else I've sensed is that, at least beyond a certain level, the CPU doesn't appear to play better, it instead just seems to do more damage using the same techniques and patterns. I'd be really interested to know if these suspicions of mine have any basis in the actual code of the games, rather than me simply being superstitious.
Just realized you're the same guy that I've played on fightcade a few times. You've taught me a lot about alpha 2 through the lil fc chat lol I'm glad to have found your videos.
You did a fantastic job here. Factual and neutral presentation of retro fg design mixed with a very entertaining approach. And I'm glad guys like Maj were referenced and consulted, as he was one of the very few in our scene who sought to learn and share their factual findings for these games back in the day. We need more of this level of content.
Fun fact: If you find the RAM address for turbo speed (A few are known: ST and VSAV at the very least), and set it to always fire a frameskip via Lua, you can play the games much faster! Dammits algorithm for finding frameskip is very clever!
Just finished watching. Amazing stuff!!!!! Really happy to see other people digging into game internals! It's on my to-do list to figure out how to use the frameskip knowledge we now have to "reconcile" recordings in LUA training mode. Now that we know the values it should be easier (As noted, dammit's script can sometimes bug out, which is what I tried using on my last pass). Will be using your video as a reference when the time comes!
Subbed, fantastic video on a super interesting topic i personally talked a lot about with friends when it comes to discussing oldschool capcom games! I have revisited that turbo speed article countless times :D
A very detailed and insightful video, editing and transitions made it an even more pleasant watch. Great job, Veri7as I think another interesting topic to tackle would be programmable macros and whether they give significant advantage or not. I know some high level Alpha 2 players use macros, though no one is willing to confess. Programmable macros are even more prevalent in 3rd strike. It's especially baffling when you see a guy do ridiculous things such as kara sweep demon as Akuma or standing 720 consistently.
24:20 - I think this might be why Bug made the claim he did because the previous input is still being processed during the skipped frame, but as you mentioned, no new ones are being accepted. So technically, there is still an input being processed during those frames, and if we're reading it from that perspective, his statement isn't wrong -- just not quite what other people were talking about.
Beautiful video. Everything you showcased was very relevant. I wanted to comment on a few things: About the internal logic being skipped, it fundamentally doesn't make sense, since if you skip any processing it would be the same as doing nothing. The game would be in the same state after the "skip". It would be pointless to do this. Hitbox collision is not the only thing that happens in the game's logic. There are increments in whatever the current animation is, changes in character position, etc. Also, I'm not an expert in SFV nor alpha 2 so take this with a grain of salt, but frame data back in the day wasn't as important not only because it was largely unknown, but because the design of the game didn't put that much emphasis in it. For instance in modern SF if you block certain normals there's suddenly a very well defined mixup with something like frametrap vs shimmy. In old SF you block something and then the pushback is kinda huge. Even if you knew the frame data for these old games you couldn't really use it to your advantage in such a streamlined way.
What an incredibly slick video! Good shit. Glad frameskipping as implemented here isn't prevalent in modern fighting games. Nowadays the FGC enjoys precision, so I imagine a modern fighting game with dropped inputs 25% of the time wouldn't be too popular. Hell, people write off console versions of fighting games because they have more input delay.
I wonder why Turbo speed never became a bog-standard feature for Capcom's games? Sometimes I feel like even Mega Man and Resident Evil could in theory use it.
tbh this video and the outtro touch on a topic of fighting game design that I think maybe a lot of people fail to critique or even acknowledge. That topic is immersion. There were a lot of cases in the early days where people had a very ill-informed perspective on how fighting games work. Im talking like people believing you could mash vs meaties or block combos if you were "fast enough." Tbh i think this kinda takeaway was actually the intended design. Old fighting games often favored creating immersion by obfuscating the simplicity of the underlying systems. Nowadays I think the design is a bit more of a hybrid. They might not tell you how things operate under the hood as much, but it's more deterministic and standardized.
3:11 *SMASHES LIKE BUTTON* In all seriousness, great video, very comprehensive while still being easy and fun to watch, would love to see more deep dives like this in the future.
This might be the wrong place to ask this but I was thinking: Since higher refresh rate monitors exist now, would it be reasonable to modify these games to still play at turbo speeds but without skipping frames? (Obviously not for any kind of mainstream market, that's too small a niche, but I'd be quite curious to see it)
In Super Turbo (and probably a lot of other games) different stages run at different speeds. Are there extra frames skipped on fast stages, or does something else make this happen?
I always found it hard to completely have control of SFA3 gameplay, and knew deep down something wasn't adding up as I didn't feel that with SNK games. Now I understand what is going on. Although that doesn't explain my losses against some gods of CAPCOM games in places like Fightcade 😄😄. Maybe I still need to get better myself
Just curious about player input-at 12:32, I see that for P1, the joystick directions correspond to 1, 2, 4, and 8, and the 6 buttons go to 1, 2, 4, 16, 32, and 64. Notably, the button values skip 8, and 128 is simply unused. But also, since 1, 2, and 4 are used twice, it can be assumed that joystick input and button input aren't in the same byte. (Necessary anyway since you couldn't keep all 10 in one byte.) I'd like to wager a guess that input in total is stored in 3 bytes. Byte 1: Bits 1\2\4\8 are player 1 joystick, and bits 16/32/64/128 are player 2 joystick. Byte 2: 1\2\4 = P1 jab\strong\fierce; 8 = left coin switch; 16\32\64 = P1 short\forward oundhouse; 128 = P1 start button Byte 3: Same as byte 2 but with player 2's P\K buttons, start button, and right coin switch Does anyone know if this is right? I find this kind of thing fun to think about
@@Veri7as Right, I totally forgot P1 and P2 were kept in 2 separate places in memory. But 2 hex digits = 1 byte, so by writing 6 digits there, you're saying it's 3 bytes just for 1 player's input? 1.5 bytes for current frame and 1.5 bytes for previous frame would make sense
Thanks for this. I've been wondering how this could be accomplished without major compromises since I tried them several years ago. I never would have guessed that cutting out sprite updates gives you enough overhead to run the game logic at double speed. Still not a fan of this feature, though, since in every case I'm left wondering which setting the game's community uses and which I should play on. And some games have a LOT of speed settings.
So one question about the input buffers: during a skipped frame, does the "last frame" input get updated? Or is it such that if you hit heavy punch right on the frame, the game will process two frames of "pushing heavy punch for the first frame"?
The heavy punch gets processed on the skipped frame as it if was pressed like normal, but the next frame processes it as if it's being held down, not being pressed again.
@@Veri7as okay, so it acts completely identically except that it doesn't check the controller registers again I wonder if that was because they were concerned about over polling the inputs for some reason
So, the heretical take: running normal mode on an emulator at accelerated display speed on a high refresh monitor would be superior to running on original hardware. There's no longer dropped input or animation frames, despite running at the turbo game speed. This would be a good implementation for re-releases.
I think that since input logic is affected by skipped frames, tournaments will have to ban turbo or require the slowest turbo speed to reduce the chances of missed inputs as much as possible.
Good video however this technique must have been improved in SFA2 I could have sworn at times my inputs were not read at times during Super Street Fighter 2 Turbo
When you are knocked down, you are already at a disadvantage, and doing a reversal already requires frame perfect timing and carries the huge risk the opponent will block, how does a 1/4 chance that it just flat out won’t work make the game any more fun? I do think that randomness has a place in fighting games, but as far as I am concerned it’s only a good thing in a competetive environment if it lets players make a calculated risk, there is a reason why Smash Bros. players worship the number 9 and despise tripping. At least in the case of the reversals, it just seems to me like too much risk for what you get and interferes with the other knockdown situation strategies. To be clear I’m not saying that it’s unacceptable, it’s a minor bug in an old 90s fighter that people (myself included) enjoy anyway. I’m not super versed with Alpha 2 so if I got anything wrong let me know.
one of the worst ideas capcom ever had. which speed was the standard? and some speeds made the game unplayable. iirc, sfa3 arcade had like 8 turbo speeds lol. didn't make any sense. all in all, GREAT video.
![ค้างคืนโรงเก็บกระสวยอวกาศร้างกลางทะเลทราย [Around The World Ep. 3]](http://i.ytimg.com/vi/E5bWZQhABJE/mqdefault.jpg)
So fun fact, there's a modern fighting game that uses this exact kind of frame skip: Skullgirls.
You can see in early footage that the game originally ran much slower. They implemented frame skip in response to feedback asking for the game to be sped up. I know several different values were tested and in the end the game ended up quite a bit faster, and with frame by frame playback you should be able to see certain moves skipping frames occasionally.
No clue how they avoided the issues with 1 frame inputs etc, might be cool to look into
I did not know that. It would be super interesting to see their approach to a turbo speed.
lol thanks for the plug! I just saw the video and tweeted about it too. Lemme go find out how our frameskip works 🤔
Also incredible work, Veri7as! So awesome that you went so deep and solved this decades long mystery, and even cleared up an official blog post!
Just found out how our frameskip works: we skip every 5th frame! I think I remember back in the day that we tried testing a variety of different frameskip patterns but this one felt/looked the best and is 20% faster than our original speeds.
The issues with skipped frames can easily be avoided with input buffers. Idk if skullgirls used that though
@@Unit_00 INPUT BUFFER HELPS, BUT STILL WON’T COVER YOU IF YOU NEED TO PRESS THE BUTTON EXACTLY ON THE FRAME AFTER SKIPPED FRAME.
=)
Edit: Had some free time and checked SFA3. In the rendering subroutine there is a copy paste of the input taking code that it branches to when it is on a skipped frame before it returns, so at some point between SFA2 and SFA3 they did fix this bug. Edit 2: got Kyle to check out vsav and he found that it is the same as SFA2 (misses inputs).
It's been several years but I remember that when reverse engineering a few cps2 games that in vsav the input skip during frame skips was fixed. I also remember the skipped inputs existing in SFA3 and Jed has told me they used the same engine, so I don't entirely trust my memory. If it was fixed in vsav though that would explain why the article thinks that it didn't skip inputs though. You might be interested in checking that out.
is there a possibility this could be changed/"fixed" in certain console ports like ssf2x for dreamcast
@@disdownloadnetvictim Yeah it certainly could have been fixed in the console ports, but I don't know if they were. I'd doubt it though since it wasn't fixed for MVC2 and or any of the other games I know that have easy ways to check for it.
@@nodthenbow as far as ST for dreamcast goes, the stage speed bug was fixed afaik so i'm curious about it. I wonder if there were any changes in zero 2 alpha / alpha 2 gold as well.
Not gonna lie, I watched your video at turbo speed but it was very informative and well researched. Good job!
Incredible analysis. Thank you for sharing this information
This video is NICE. Ive read those articles on frameskip in the past, but its nice to see someone get down to the gritty details of it for once. PLEASE do not be afraid to go DEEP with the code talk in future content! I would love to hear more about how these games function. Even for a casual watcher like me, that stuff is very fascinating, and showing off examples of the code in action and its implications really helps make it easy to digest.
It seems like this video is somewhat of a first for your channel, I hope to see much more from you, I think you've got something unique in the fighting game content space here.
Wow! Thank you for diving into the code so thoroughly! I've been fascinated by Capcom turbo modes for a while and a few years back I was completely obsessed with a VSav turbo 3 combo (Sako special) and was convinced that at least on the latest console ports, that the 3,3,3 skip was causing this pattern of a 50% failure since it hinged on a double frame perfect input (2 on, 2 off), which just so happened to be exactly spaced when non-turbo'd so that the 1st skipped frame covered 2nd possible frame as well, when trying to account for the 1st one. On Twitter when talking about Turbo, Damdai linked to that seminar article you mentioned, and after reading it I was sure either it was either incorrect or that the emulation wasn't doing something correctly.
After some time I was finally able to try VSav on a cab at Turbo 3 and had what felt like marginally more success with the combo, I chalked it up purely to the tiny speed difference in the games Hz, since consoles and emulators mostly seem locked to 59.94/60, vs arcade hardware which generally ran a bit slower, and can fluctuate based on stage/effects and such.
I hope this video is the nail in the coffin, or leads to further dissection of hardware/emulator adjustments if needed. Thanks for the hard work!
It's actually kinda insane that it's been almost 3 decades since Street Fighter 2 Turbo allowed you to select your speed, and it's only now that someone actually looked into the code of these games to see how works.
There really is a large gap in code-level knowledge of how fighting games in general function, especially here in the youtube-sphere.
Simply fantastic video Veri7as!
I hope one day this can explode in views, and we can see more stuff like it. It really helps to pull back that "mistique" you mention in the closing section
Cheers
This was great! Very in depth, the amount of time and patience it must take to dig through this code and figure out what is happening is truly impressive. To then managing to clearly and simply explain all of this with illustration is top tier skill, it’s up there with Displaced gamers work which I enjoy for the same reasons.
>passion project with hundreds of hours of work
700 subs, 5K views
>"SooOoO Uh GuYs i MaDe tHiS ViDeO tO ShOw yOu My 8 MiLLioN DoLLaR HoUse"
700 million subs, and more views than there are people on the planet
Really cool video, thanks for the effort. Will pass it around.
21:48 Crossing up charge characters when they are charging counts as two inputs for them. This means one can activate a super when the opponent crosses you up by simply releasing the charge state and then pressing diagonal + up. In the case of Charlie, this will activate Somersault Justice and for Chun-Li, Hazan Tensho Kyaku.
Great in depth video.
I’d love to see more content on ST, around nuisances and quirks.
When I saw this video pop up I was working myself up to have to counter a bunch of "ingrained community wisdom", but you've covered the topic well. That skillsmith capcom blog article about the turbo frameskipping was a crucial turning point on the subject. I wonder if the SF2 series games don't have this 'doubling input' issue that A2 does - or indeed if A3 uses the same input parsing/skipping behaviour. There are people still creating input playback, emulator based tools which use the display frame count to trigger inputs, which is potentially not sufficient! Thank you for the research and video. I'd be interested in how the "unblockable" blanka ball/tiger uppercuts work in SF2HF too. BTW I make a cameo appearance at 3:39 in the video :D
Very cool. Back in the day I honestly thought capcom had just manually adjusted frame counts of each animation for every speed setting. Which in turn made me wonder what type of a calculation they used to figure out how to add or subtract frames to keep everything feeling consistent.
This video was posted 2 days ago and only had 1k views? What a shame, this is very informative and entertaining.
Been romhacking for over a year, and it's so viscerally great to see more people doing it, code and all.
This is the most legit dissection i've seen on YT, love it to bits. Please do more! I vote "How Capcom games drew sprites to the screen", have a bunch of notes should ya choose to look in to it
Holy shit dude. Future legend. Mad respect.
We need more videos like this, really informative and indepth and fun to watch and follow. I did not have a degree on computer science but even my monkey brain was abel to follow. awesome video.
Great video. Would it be possible to get another that details how difficulty settings work in the SF series? I was interested to learn about the losing player in round 1 getting a damage boost in round 2, as even as a kid I noticed that if I lost round 1 the CPU would seem to go easy on me for a while then kick my ass in round 3.
I'm curious what other changes happen though - does the game get easier after a set number of continues - I know this happens in 3S when losing to Gill but is it true for the other games or characters too? Something else I've sensed is that, at least beyond a certain level, the CPU doesn't appear to play better, it instead just seems to do more damage using the same techniques and patterns.
I'd be really interested to know if these suspicions of mine have any basis in the actual code of the games, rather than me simply being superstitious.
top notch quality content bro, keep it up!
Just realized you're the same guy that I've played on fightcade a few times. You've taught me a lot about alpha 2 through the lil fc chat lol I'm glad to have found your videos.
great video, and I never really knew exactly how these worked, and now I do!
You did a fantastic job here. Factual and neutral presentation of retro fg design mixed with a very entertaining approach. And I'm glad guys like Maj were referenced and consulted, as he was one of the very few in our scene who sought to learn and share their factual findings for these games back in the day. We need more of this level of content.
God thank you so much for this, it's been bothering me since I was like four
Fun fact: If you find the RAM address for turbo speed (A few are known: ST and VSAV at the very least), and set it to always fire a frameskip via Lua, you can play the games much faster! Dammits algorithm for finding frameskip is very clever!
Just finished watching. Amazing stuff!!!!! Really happy to see other people digging into game internals! It's on my to-do list to figure out how to use the frameskip knowledge we now have to "reconcile" recordings in LUA training mode. Now that we know the values it should be easier (As noted, dammit's script can sometimes bug out, which is what I tried using on my last pass). Will be using your video as a reference when the time comes!
This is a setting I've always just accepted and never questioned 👍
This is gold. Love your work ❤️
Great research on an obscure topic. Thanks for this!
Monumental! Kudos bro
Subbed, fantastic video on a super interesting topic i personally talked a lot about with friends when it comes to discussing oldschool capcom games! I have revisited that turbo speed article countless times :D
A very detailed and insightful video, editing and transitions made it an even more pleasant watch. Great job, Veri7as
I think another interesting topic to tackle would be programmable macros and whether they give significant advantage or not. I know some high level Alpha 2 players use macros, though no one is willing to confess.
Programmable macros are even more prevalent in 3rd strike. It's especially baffling when you see a guy do ridiculous things such as kara sweep demon as Akuma or standing 720 consistently.
Dude this is a banger video
Well done!
SF2 turbo on the snes was my jam when i was a kid.
Instant sub
24:20 - I think this might be why Bug made the claim he did because the previous input is still being processed during the skipped frame, but as you mentioned, no new ones are being accepted. So technically, there is still an input being processed during those frames, and if we're reading it from that perspective, his statement isn't wrong -- just not quite what other people were talking about.
Which statement made by Bug are you referring to?
Beautiful video. Everything you showcased was very relevant.
I wanted to comment on a few things:
About the internal logic being skipped, it fundamentally doesn't make sense, since if you skip any processing it would be the same as doing nothing. The game would be in the same state after the "skip". It would be pointless to do this. Hitbox collision is not the only thing that happens in the game's logic. There are increments in whatever the current animation is, changes in character position, etc.
Also, I'm not an expert in SFV nor alpha 2 so take this with a grain of salt, but frame data back in the day wasn't as important not only because it was largely unknown, but because the design of the game didn't put that much emphasis in it. For instance in modern SF if you block certain normals there's suddenly a very well defined mixup with something like frametrap vs shimmy. In old SF you block something and then the pushback is kinda huge. Even if you knew the frame data for these old games you couldn't really use it to your advantage in such a streamlined way.
This was amazing.
Well, this is interesting information. I hope to see the technicality behind the coding.
that was great
Hey! I know those transitions! Cool video. I definitely learned some things
What an incredibly slick video! Good shit. Glad frameskipping as implemented here isn't prevalent in modern fighting games. Nowadays the FGC enjoys precision, so I imagine a modern fighting game with dropped inputs 25% of the time wouldn't be too popular. Hell, people write off console versions of fighting games because they have more input delay.
Thanks! Just to be clear, inputs are never dropped.
Awesome video, subscribed 👍
I wonder why Turbo speed never became a bog-standard feature for Capcom's games? Sometimes I feel like even Mega Man and Resident Evil could in theory use it.
tbh this video and the outtro touch on a topic of fighting game design that I think maybe a lot of people fail to critique or even acknowledge. That topic is immersion.
There were a lot of cases in the early days where people had a very ill-informed perspective on how fighting games work. Im talking like people believing you could mash vs meaties or block combos if you were "fast enough." Tbh i think this kinda takeaway was actually the intended design. Old fighting games often favored creating immersion by obfuscating the simplicity of the underlying systems.
Nowadays I think the design is a bit more of a hybrid. They might not tell you how things operate under the hood as much, but it's more deterministic and standardized.
Great!
Based End of Ze World voice clip
Do you have a soundcloud or something of the artist who made said music for you video? I can't find them at all.
iantaggart.bandcamp.com/
End song is called "Wilderness of Mirrors" on the "...but he who causes the darkness" album.
I added a Spotify link in the description too.
@@Veri7as Thank you very much.
3:11 *SMASHES LIKE BUTTON*
In all seriousness, great video, very comprehensive while still being easy and fun to watch, would love to see more deep dives like this in the future.
This might be the wrong place to ask this but I was thinking:
Since higher refresh rate monitors exist now, would it be reasonable to modify these games to still play at turbo speeds but without skipping frames? (Obviously not for any kind of mainstream market, that's too small a niche, but I'd be quite curious to see it)
In Super Turbo (and probably a lot of other games) different stages run at different speeds. Are there extra frames skipped on fast stages, or does something else make this happen?
I always found it hard to completely have control of SFA3 gameplay, and knew deep down something wasn't adding up as I didn't feel that with SNK games.
Now I understand what is going on.
Although that doesn't explain my losses against some gods of CAPCOM games in places like Fightcade 😄😄. Maybe I still need to get better myself
Just curious about player input-at 12:32, I see that for P1, the joystick directions correspond to 1, 2, 4, and 8, and the 6 buttons go to 1, 2, 4, 16, 32, and 64.
Notably, the button values skip 8, and 128 is simply unused. But also, since 1, 2, and 4 are used twice, it can be assumed that joystick input and button input aren't in the same byte. (Necessary anyway since you couldn't keep all 10 in one byte.)
I'd like to wager a guess that input in total is stored in 3 bytes.
Byte 1: Bits 1\2\4\8 are player 1 joystick, and bits 16/32/64/128 are player 2 joystick.
Byte 2: 1\2\4 = P1 jab\strong\fierce; 8 = left coin switch; 16\32\64 = P1 short\forward
oundhouse; 128 = P1 start button
Byte 3: Same as byte 2 but with player 2's P\K buttons, start button, and right coin switch
Does anyone know if this is right? I find this kind of thing fun to think about
The video is only showing where P1's inputs are stored. FF849A would be directions in the first 2 hex digits and buttons on the next 2.
@@Veri7as Right, I totally forgot P1 and P2 were kept in 2 separate places in memory.
But 2 hex digits = 1 byte, so by writing 6 digits there, you're saying it's 3 bytes just for 1 player's input?
1.5 bytes for current frame and 1.5 bytes for previous frame would make sense
Thanks for this. I've been wondering how this could be accomplished without major compromises since I tried them several years ago. I never would have guessed that cutting out sprite updates gives you enough overhead to run the game logic at double speed. Still not a fan of this feature, though, since in every case I'm left wondering which setting the game's community uses and which I should play on. And some games have a LOT of speed settings.
I honestly never notice any difference. Maybe it's like a reverse placebo or something.
So one question about the input buffers: during a skipped frame, does the "last frame" input get updated? Or is it such that if you hit heavy punch right on the frame, the game will process two frames of "pushing heavy punch for the first frame"?
The heavy punch gets processed on the skipped frame as it if was pressed like normal, but the next frame processes it as if it's being held down, not being pressed again.
@@Veri7as okay, so it acts completely identically except that it doesn't check the controller registers again
I wonder if that was because they were concerned about over polling the inputs for some reason
Out of interest, does anyone know the default speed for ST tournaments are ?
Maximilian Dood sent me lol
Normal or Turbo, Manual or Auto..am i playing street fighter or ridge racer?
So, the heretical take: running normal mode on an emulator at accelerated display speed on a high refresh monitor would be superior to running on original hardware. There's no longer dropped input or animation frames, despite running at the turbo game speed.
This would be a good implementation for re-releases.
Should Capcom bring back turbo mode?
I wonder how hard it'd be to make a hack or something that'd let it run at 80fps, and not needing to skip any frames
How come SF4 & 5 Never had a Speed Select?
I think that since input logic is affected by skipped frames, tournaments will have to ban turbo or require the slowest turbo speed to reduce the chances of missed inputs as much as possible.
I don’t believe anything should change for tournament standard speeds. No inputs are missed/dropped by turbo speeds.
I am very interested to see top players play the fixed version
How noticeable will it be?
Would I notice it? I'd feel better knowing this was fixed
What fixed version?
@@Veri7as There might not be one yet, but i'm sure at some point it will be fixed
I'm playing the slowest speed always, doesn't get boring to me
Good video however this technique must have been improved in SFA2
I could have sworn at times my inputs were not read at times during Super Street Fighter 2 Turbo
So is thus why st vegas scarlet terror is so much better than in CE?
I doubt turbo speeds have anything to do with making scarlet terror better.
When you are knocked down, you are already at a disadvantage, and doing a reversal already requires frame perfect timing and carries the huge risk the opponent will block, how does a 1/4 chance that it just flat out won’t work make the game any more fun?
I do think that randomness has a place in fighting games, but as far as I am concerned it’s only a good thing in a competetive environment if it lets players make a calculated risk, there is a reason why Smash Bros. players worship the number 9 and despise tripping. At least in the case of the reversals, it just seems to me like too much risk for what you get and interferes with the other knockdown situation strategies.
To be clear I’m not saying that it’s unacceptable, it’s a minor bug in an old 90s fighter that people (myself included) enjoy anyway. I’m not super versed with Alpha 2 so if I got anything wrong let me know.
Reversals are already incredibly hard to execute in Alpha 2. Frameskipping makes them marginally harder. But not to any meaningful degree.
one of the worst ideas capcom ever had. which speed was the standard? and some speeds made the game unplayable. iirc, sfa3 arcade had like 8 turbo speeds lol. didn't make any sense.
all in all, GREAT video.
I watch TH-cam on 1.75 turbo speed.