I know it's just a small thing compared to the other work it took to create this video, but thank you for including captions. I have minor speech processing problems and captions help a lot. RUclips's automatic captions sometimes don't work.
Your comment is important to me. Sometimes I wonder if it is worth doing the captions (because my script gets edited, re-recorded, and patched together during production). I listen to the whole video after it is finished and edit a “published video” copy of the script to upload to RUclips. One person is reason enough to do it. Happy to help!
As someone who doesn't necessarily *need* the captions, I do learn better with them, especially for more technical information such as the content of your videos. Please continue with the captions.
As co-author of the current TAS of the game, I salute you sir. We extensively used this glitch througout the TAS in many crazy ways but, although I have a good idea as to how to exploit it, I never really understood the inner workings of the glitch. Please keep these videos coming!
Wow! This one took a long time to research and assemble. Thanks to Kosmic for the suggestion. I know we didn't dive into syntax or create any Game Genie codes this time around, but I found the topic fascinating and felt like Behind the Code was still compatible with it - even if I only showed some of the major code on a single slide. This video was made possible thanks to some amazing knowledge from SBDWolf and trisk. Thank you both so much for your patience and fast communication with me. Thanks to both of you and jay_cee for letting me use footage from your speedruns. Goodness knows I can't perform the scrolling glitch on a whim! Checkout these guys on Twitch! Tell 'em I sent ya. SBDWolf - www.twitch.tv/sbdwolf trisk - www.twitch.tv/tr1sklion jay_cee - twitch.tv/jay_cee jay_cee's World Record run (10m 45s 283ms) - ruclips.net/video/8r2u95rfGnQ/видео.html Hope everyone is having a great day. Thanks for watching.
I don't know about others, but what I enjoy most about Behind the Code is diving deep into the technical details / inner-workings and exploring what's possible and what happens when the logic or input (or both) is tweaked. That excitement is there regardless of the form the explanation takes. Looking at the actual code is something I haven't seen on many other channels, which I love. There's a lot of misinformation and mythology around NES-era tricks. The code itself isn't the be-all-end-all but is nice to see when it is there.
When you did the video on Battletoads, Jay_Cee was running that game, and I told him "have you seen displaced gamers video on Battletoads?" on his chat, and he told me "I don't know that channel, with that name, I will need to check it out" and now he is credited here :P
"I'm a programmer, not a speedrunner", which begs the question, how do speed speed runners discover this trick? My assumption: reverse engineers like you! (and the TAS creators).
I love this channel so much. Your breakdown of the code is so easy to understand and presented with enough context that pretty much anyone could grasp it.
Anyone watching these video's Please consider supporting Displaced Gamer on Patreon to Keep this content going. These videos are heavily edited with exceptional quality! Please help this channel grow...Thanks!!
Most of the time I'm letting RUclips run in the background while I focus on other stuff. These videos are a small minority where I basically drop everything I'm doing once I see one pop up on my feed.
@Sixfortyfive same. And if my mind wanders away for a minute, these videos are the only ones I'll *rewind* to catch that important detail I missed. It's like *every* detail is important to comprehend the next section.
Thanks so much for creating this! These visuals are perfect representations of the more abstract concepts of the glitch. This will for sure be my go-to video to recommend for anyone wanting a more granular understanding of how this glitch works. Fantastic job!
Just WOW. I love watching speedruns and sometimes I cannot comprehend what happens when they start firing their glitch sorcery. Great job explaining this particular one!
I was wondering how this didn't get triggered accidentally, but realized the double update of each block made it very unlikely to occur accidentally. The back-scrolling would have to be executed for the same block twice by chance. Top-notch visuals explaining how this works. I love this direction for emulators in supporting inspection and manipulation of game internals to clear the mystery around their operation.
Anyone watching these video's Please consider supporting Displaced Gamer on Patreon to Keep this content going. These videos are heavily edited with exceptional quality! Please help this channel grow...Thanks!!
Another brilliant video to demonstrate why I love this channel. As someone who initially knew nothing about computers, programming, or code this channel has really sparked my fascination and motivated me to learn more about it within the last year and a half. And the BTC series has made me appreciate the design that has gone into my childhood games more than the games themselves. Keep up the awesome work.
gotta give props for the extra work it takes to not only show off the trick, but actually build in extra things into the rom to show it off to help people understand better, the color swapping really helped me understand, great work!
Man I love these videos so much. It's so cool to see behind the curtain on the games I played as a kid. I have zero programing experience and it's still presented in a way that I can follow what's going on
Crazy after all these years I'm just learning about this. Crazy how people figure these things out. I still remember buying this game the first day it was released at Toys r Us.
Your channel and technical breakdown is by far some of the greatest content on RUclips. I have been in the infosec industry for quite a while, so deep-dives and disassembly of things is my lifeblood and forte. Great job as always.
Some people might be content with just the explanations of what assembly code does what, but what makes this channel next level as far as explaining how retro game mechanics work(ed) is going the extra mile with efforts like visualizing real-time hitboxes, tile draws, etc via emulator scripting and also explaining how to hook viewing related memory values in emulator memory watchers and other extremely helpful things like that.
God, I love these kinds of videos! -- You rock! -- Thanks for taking the time to go over some of these mechanics! It might be interesting to show how the Armor in a game like MegaMan X was done, or the items in A Link to the Past were "overlaid" and handled with animation one day!
16:35 The tilmap data does appear because you do the room backwards and the boss room is the next stage. The data is just next to the room before. The door is from the same room. With room I mean one of the 18 stages the game is build on. Some rooms are split in two sections and the game pulls the same level data but does check for the section by checking if the section is a even number or not for triggers to be used. I made a practice ROM for this game and you can visualize stairs there. The boss door does work but the devs did put the trigger 8 pixels into the ground/air to prevent it to be used. So far this could not be exploited in speedruning.
Another great video with in-depth and easy to follow explanations! I always look forward to seeing new videos from you in my feed. Thanks for all you do.
Awesome! Altough I enjoy retro speedruns I didn't know how the speedrunners know how the guts of the NES work and in this channel I discover gorgeous secrets from time to time. Thank you!
Wow, great content! For me, as a computer scientist and as someone who loves old games, this is the best RUclips channel today because of the innovative, technically deep and analytical content. Hugs from Brazil!
I remember watching Wolf the day (or maybe it was the day after) he'd discovered this application of the trick, and he was explaining it on his stream. It was pretty amazing that a giant chunk of time had been knocked off of a game that had been plateaued for so long. Very cool.
This is one amazing video. Explained in amazing detail. Imagine having to do this live every time you want to try for a world record. 14:15 actually made me go "OOOOOOOH, so thats how that works." I will subscribe bacause of this :D
Another great video! It's so cool to watch how the screen gets updated in code. I'm so glad I found this channel, I got inspired to try RAM watching on Mega Man X. I always liked playing as the other robot masters in Mega Man: Powered Up and thought it might be fun to try playing Mega Man X locked into one of the boss's weapons for the entire run. I eventually discovered several things: 1. The on-screen "lemon count" is controlled by a universal code: 7E0BDBYY, where YY = # of lemons that can exist on screen. All weapons use this code, so it's possible to rapid-fire Storm Tornadoes, but that eats up a lot of performance! 2. 7E0BDBZZ sets a weapon on X, where ZZ = a boss weapon where values are offset by 2. 0A is Storm Tornado. 3. Even with the above weapon code on, energy still gets consumed. Each weapon has its own code, 7E1F905C for Storm Tornado. The 5C sets its value to 92, which is the max energy a weapon can have. The only issue with codes 2 and 3 is that having any one of them on tells the game that X has defeated that boss. I still want to fight the bosses in their own stage with their own weapon, so my next step is to find out where codes 2 and 3 write to and see if I can find out how to prevent flagging a boss as beaten. Anyways, thanks again for this amazing content and keep up the good work!
YES! Thank you for tackling this one! Now I'm looking at Mesen's PPU Viewer for the title screen demo playthrough and seeing the columns loading in as you've described. The system seems much more fragile now that I look at it and see it happening in real time.
@@williamdrum9899 I am something of a hobbyist game programmer, myself (and I'm sure a number of other viewers of this channel are, too). I just have never gotten very far with low level assembly in the wild. At some point I'd love to try my hand at some 8-bit or 16-bit homebrew, though.
@@maverick_loneshark You should. It won't be easy though. Game consoles are harder than home computers since you have to do almost everything yourself, but they have the benefits of tile graphics and layering that computers dont have
I've seen this kind of level loading before! Years and years ago, I played bad dumps of SMB1 ROMs that exposed the scrolling right on screen, drawing/deleting chunks of graphics, either exactly like this, or at least very similarly. (I've also seen it happen when using some goofy homebrew GameGenie codes with SMB1, to make silly antics and fake "new worlds", heheh. Fun times!) As soon as you started showing how the graphics are loaded/unloading off camera - it was like a breakthrough, completely out of nowhere. I had *forgotten* I'd ever seen anything like that - but now that you've showcased and explain it in this video - I do believe I finally have some understand of just what I was witnessing, the whys and the hows, given I was totally baffled by it way back then, though morbidly fascinated with it occurring so unexpectedly. Thank you for this video! I truly enjoyed it.
Impressive breakdown and a well made video. When Nintendo power was the closest thing we had to cheat codes, discovering these bugs were monumental during gameplay were monumental.
Anyone watching these video's Please consider supporting Displaced Gamer on Patreon to Keep this content going. These videos are heavily edited with exceptional quality! Please help this channel grow...Thanks!!
This would be a fun one for an alternative video with additional deep dives on. I remember watching SBD and Thiagoch shortly after the exploit was found. Was a trippy experience to be sure
Thanks for the work you put into this. You made it understandable. Being a loooong time Castlevania fan (buying the first game when it dropped, yeah I'm that old), I never knew this was possible. But I was able to get it to work and I'm practicing speedrunning this game.
Super cool. I thought Castlevania had to be reaching the physical limits of human possibility but apparently not! So awesome to see games picked apart in this detail. I think diving into the mechanics (sometimes deeper than the developers) is one of my favorite parts of speed running. Especially when you see a game broken open like this. I think my favorite personal experience was breaking down bot arena 3 into an action combat game to try and shave down my time under 15 minutes (still haven't but it's a work in progress). Normal gameplay sees you just letting your bots fight and maybe telling them who to attack but, with very careful use of the movement commands and an understanding of how the ai is coded you can abuse slight differences in weapon range, pick apart much stronger bot teams with focusing fire and decreasing your opponent's damage efficiency, controlling (usually) two bots at the same time in this manner is what makes the run fun imo. You also have to try and improve your damage efficiency to keep the time for each battle down. Still working on strategy for the god run where I oneshot the first 4 battles but when I do it'll be awesome.
There are many different hacks that I would love to see with Castlevania 1. Can these be done? 1: Double jump. 2: Whipping as rapidly as you want. 3: Spawn whip upgrades when you already have the best whip, (what will happen?). 4: Movement not being locked in the stage advances. 5: Getting the boss orb from candles or regular enemies. 6: Getting the invisibility potion to never wear off. (Will it reset in stage advances or after the bosses?) 7: Getting invisibility potion from every candle. 8: Making holy water burn forever. 9: Adding the jumping sound from Super Mario Bros.
Great job as always. Very interesting glitch. You can see they tried to prevent it from happening from all the attempted overwrites on the same column. From the way you described it the only way I can think of to fix the glitch would be to use two block counters. One for the left and one for the right. With that they shouldn't have to redraw the same column so many times either - it can probably be done every 3 or 4 frames instead of 2. Haven't done the math...
Which brings another thought. The amount of memory reuse NES games had was astounding. Keeping it all straight in your head must have been insane. I'm surprised these games work at all to be honest.
Ah, I frickin love this channel, I still have plenty of content to go through but I always watch new uploads once I catch them. Would you mind listing the particular music tracks used in this episode?
9:30 Did you animate all of that by hand in AE, or were you able to use some sort of AE expression? Or was all that visualization built into the emulator you were using?
Back in the day when this kind of stuff happened while you were playing it screwed up your game hard and you were pissed. Now we've got people spending their free time learning how to intentionally cause these glitches for the sole purpose of... playing less of the game.
Absolutely amazing video, as always!! Your visualizations and explanations are unparalleled. Personally, I'd love to see more assembly walk-throughs, but that's mostly because I'm learning NES coding myself :) One question: Why is it updating each column twice?? Seems like a lot of extra work. Is it a workaround to the "bug" that it might not complete drawing the column the first round through due to player turning? I feel like it would've made more sense to queue a full column draw once (e g by having two ints -- one for which column we're currently drawing, and one for which to draw once we're done with all the rows), rather than changing mid-column...
i remember things like this accidentally happening when i played it way back in the day on the NES....i seem to recall a level with garbage on the right side and jumping and dying and might have done something where i climbed invisible stairs but it was so long ago.
Meanwhile, Megaman 1 did not put the scrolling on alternate frames. So you can lag the game by going to a scroll boundary and repeatedly move left and right quickly. The TAS uses that to cause lag, and there's a bug in the game that can sometimes cause incorrect code to be executed if a frame lagged.
Most impressive investigations here, sir 👍 Have absolutely no doubt - the next video's gonna be even more fascinating discovery! In the meantime I'd like to leave a suggestion for 1 of the following episodes: the trick behind Ocean Software's JP screen update with NO garbage graphics inside V-Blank column ☝️
Awesome breakdown! Can you please make a video about Contra Force? It was notorious for its slowdowns, I think it would be great to think of what optimizations could be done to make it less laggy
Nice video! Usually when you explain glitches, there is some tricky corner case where the code turns out to do the wrong thing. But in this case, I'm impressed just how off the solution is to begin with -- who would have thought that this would work? Just keep repeating reloading the level data and hope that all tiles will be hit before you get there -- it doesn't seem like the code was written to care about the fact that you can reverse direction at all. (I wonder if Castlevania was originally like SMB1, where you can't?) But maybe as you said the intention was to have separate block counters for left and right, then it should have worked. So if that was the mistake that created the glitch, it would still make some sense. I guess that the fact that it keeps reloading the same data for a while made the glitch uncommon enough in practice, so maybe no one noticed? One question: You say that each column is loaded twice. But the block counter only needs 6 steps to reload one column. Does it still repeat after 8 steps, and just do nothing during two of them?
They did know about it this is why they load the data twice. It is very unlikely to wiggle all the time what need to be done for this glitch to work. And you see how long it toke to be discoverd. I think this was the lazy solution and they did change it in later games.
10:28 I guess the tiles are not actually read back from VRAM, but the game has a separate buffer to read them from that is updated in sync with VRAM? As far as I understand it, reading from VRAM on the NES is not very practical (maybe except during vblank).
Yes, NES games generally keep a collision map in work RAM in sync with the contents of VRAM. One game that *does* have to read back from VRAM to handle collisions is Life Force--its main collision map uses just 1 bit per tile, so when a bullet is about to collide with terrain it has to read from VRAM to distinguish between destructible terrain (e.g. the cell walls in stage 1) and regular solid terrain. The Japanese version Salamander didn't have to do this because it had additional RAM in the cartridge, giving it room for a 2-bit-per-tile collision map.
So each block in a column gets updated twice during that column's life cycle? Can we assume that the double updates are a simplistic method the programmer used to prevent blocks from getting skipped under "normal circumstances"? (i.e. when the player is moving in both directions but is not intentionally trying to exploit the engine)
"The Belmont knows where he is at all times. He knows this because he knows where he isn't. By subtracting where he is from where he isn't, or where he isn't from where he is (whichever is greater), he obtains a difference, or deviation. The PPU subsystem uses deviations to generate analog video signals to draw the Belmont from a position where he is to a position where he isn't, and arriving at a position where he wasn't, he now is. Consequently, the position where he is, is now the position that he wasn't, and it follows that the position that he was, is now the position that he isn't. "In the event that the position that he is in is not the position that he wasn't, the game has acquired a variation, the variation being the difference between where the Belmont is, and where he wasn't. If variation is considered to be a significant factor, it may be given its own category in speedrun rankings. However, the Belmont must also know where he was. "The PPU logic works as follows: Because a variation has modified some of the information the Belmont has obtained, it is not sure just where he is. However, it is sure where he isn't, within reason, and it knows where he was. It now subtracts where he should be from where he wasn't, or vice-versa, and by differentiating this from the algebraic sum of where he shouldn't be, and where he was, it is able to obtain the deviation and its variation, which is called a 'glitch'."
I’m starting to sound like a broken record, but thanks again for the great content. I need stuff like this to distract me, I really appreciate it. Hope they are as fun to research and make as they are to watch.
This video shows how elegantly the original game was designed. It's tempting to think of old games as primitive, but the developers achieved so much with so little computing power
What amazes me is the fact Nintendo engineers had to figure all of this out from scratch in 1983 when they decided to make the Famicom/NES. It’s mind blowing.
Love this channel! Your content and a couple other chans have me learning 6502 assembly. Something I wish I had the resources to have learned as a kid honestly. Speaking of that time gone by, do you think the creators thought people would be playing, let alone analyzing its code 36 years later?
Gosh. That is an interesting question. While it is possible they wondered about longevity, I assume most were always looking to create the next thing and stay ahead of the game (no pun intended).
![Felix "Unfair" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/Oswujxm2Ag0/mqdefault.jpg)
Thank you for breaking this down!!
Thank you for suggesting it!
I know it's just a small thing compared to the other work it took to create this video, but thank you for including captions. I have minor speech processing problems and captions help a lot. RUclips's automatic captions sometimes don't work.
Your comment is important to me. Sometimes I wonder if it is worth doing the captions (because my script gets edited, re-recorded, and patched together during production). I listen to the whole video after it is finished and edit a “published video” copy of the script to upload to RUclips.
One person is reason enough to do it. Happy to help!
It also does wonders for many who have English as a second language, me included.
thanks from me as well
excellent video, i have been curious about this exploit! and absolutely thanks for the captions
As someone who doesn't necessarily *need* the captions, I do learn better with them, especially for more technical information such as the content of your videos. Please continue with the captions.
As co-author of the current TAS of the game, I salute you sir. We extensively used this glitch througout the TAS in many crazy ways but, although I have a good idea as to how to exploit it, I never really understood the inner workings of the glitch. Please keep these videos coming!
I love the visualizations. I think this is an excellent way to show exactly how this glitch works. Great work! Happy to have been part of this.
Thank you so much for your help!
Wow! This one took a long time to research and assemble. Thanks to Kosmic for the suggestion.
I know we didn't dive into syntax or create any Game Genie codes this time around, but I found the topic fascinating and felt like Behind the Code was still compatible with it - even if I only showed some of the major code on a single slide.
This video was made possible thanks to some amazing knowledge from SBDWolf and trisk. Thank you both so much for your patience and fast communication with me. Thanks to both of you and jay_cee for letting me use footage from your speedruns. Goodness knows I can't perform the scrolling glitch on a whim!
Checkout these guys on Twitch! Tell 'em I sent ya.
SBDWolf - www.twitch.tv/sbdwolf
trisk - www.twitch.tv/tr1sklion
jay_cee - twitch.tv/jay_cee
jay_cee's World Record run (10m 45s 283ms) - ruclips.net/video/8r2u95rfGnQ/видео.html
Hope everyone is having a great day. Thanks for watching.
I don't know about others, but what I enjoy most about Behind the Code is diving deep into the technical details / inner-workings and exploring what's possible and what happens when the logic or input (or both) is tweaked. That excitement is there regardless of the form the explanation takes.
Looking at the actual code is something I haven't seen on many other channels, which I love. There's a lot of misinformation and mythology around NES-era tricks. The code itself isn't the be-all-end-all but is nice to see when it is there.
When you did the video on Battletoads, Jay_Cee was running that game, and I told him "have you seen displaced gamers video on Battletoads?" on his chat, and he told me "I don't know that channel, with that name, I will need to check it out" and now he is credited here :P
didnt expect you to upload today. i was literally saving your videos just 5 hours ago
I thought it was really interesting, inspired me to try to create a Game Genie code to "unlock" the doors in the boss rooms.
"I'm a programmer, not a speedrunner", which begs the question, how do speed speed runners discover this trick? My assumption: reverse engineers like you! (and the TAS creators).
I love this channel so much. Your breakdown of the code is so easy to understand and presented with enough context that pretty much anyone could grasp it.
fr
Anyone watching these video's Please consider supporting Displaced Gamer on Patreon to Keep this content going. These videos are heavily edited with exceptional quality! Please help this channel grow...Thanks!!
Great video, thanks for having me!
Most of the time I'm letting RUclips run in the background while I focus on other stuff. These videos are a small minority where I basically drop everything I'm doing once I see one pop up on my feed.
Wow. Thank you. That means a lot!
@Sixfortyfive same. And if my mind wanders away for a minute, these videos are the only ones I'll *rewind* to catch that important detail I missed. It's like *every* detail is important to comprehend the next section.
@@DisplacedGamers for sure -- you and Retro Game Mechanics Explained are so info dense I have to pay attention
Thanks so much for creating this! These visuals are perfect representations of the more abstract concepts of the glitch. This will for sure be my go-to video to recommend for anyone wanting a more granular understanding of how this glitch works. Fantastic job!
Thank you for your video as well! It helped me get the ball rolling.
Just WOW. I love watching speedruns and sometimes I cannot comprehend what happens when they start firing their glitch sorcery. Great job explaining this particular one!
I was wondering how this didn't get triggered accidentally, but realized the double update of each block made it very unlikely to occur accidentally. The back-scrolling would have to be executed for the same block twice by chance. Top-notch visuals explaining how this works. I love this direction for emulators in supporting inspection and manipulation of game internals to clear the mystery around their operation.
8:16 tell that to the Digimon World devs, checking every frame if a digimon meets the requirements to evolve haha
The editing really is marvelous on these videos. The visuals are always there to explain what's happening behind the scenes!
As a fellow deep-dive channel, this content is truly invaluable. Fantastic breakdown and explanation here!
Anyone watching these video's Please consider supporting Displaced Gamer on Patreon to Keep this content going. These videos are heavily edited with exceptional quality! Please help this channel grow...Thanks!!
Another brilliant video to demonstrate why I love this channel. As someone who initially knew nothing about computers, programming, or code this channel has really sparked my fascination and motivated me to learn more about it within the last year and a half.
And the BTC series has made me appreciate the design that has gone into my childhood games more than the games themselves.
Keep up the awesome work.
13:00 Absolutely amazing breakdown... S-tier.
Thanks!
This I alike the ultimate epilogue to summoning Salts history of castlevania speedruns. I've been wanting this a long time.
gotta give props for the extra work it takes to not only show off the trick, but actually build in extra things into the rom to show it off to help people understand better, the color swapping really helped me understand, great work!
Man I love these videos so much. It's so cool to see behind the curtain on the games I played as a kid. I have zero programing experience and it's still presented in a way that I can follow what's going on
Learned a lot about 8-bit code and hardware from you!
Awesome! And thanks!
Crazy after all these years I'm just learning about this. Crazy how people figure these things out. I still remember buying this game the first day it was released at Toys r Us.
Visualisation is superb and helps a lot! Good job!
Your channel and technical breakdown is by far some of the greatest content on RUclips. I have been in the infosec industry for quite a while, so deep-dives and disassembly of things is my lifeblood and forte. Great job as always.
Some people might be content with just the explanations of what assembly code does what, but what makes this channel next level as far as explaining how retro game mechanics work(ed) is going the extra mile with efforts like visualizing real-time hitboxes, tile draws, etc via emulator scripting and also explaining how to hook viewing related memory values in emulator memory watchers and other extremely helpful things like that.
God, I love these kinds of videos! -- You rock! -- Thanks for taking the time to go over some of these mechanics!
It might be interesting to show how the Armor in a game like MegaMan X was done, or the items in A Link to the Past were "overlaid" and handled with animation one day!
didnt expect you to upload today. i was literally saving your videos just 5 hours ago
16:35 The tilmap data does appear because you do the room backwards and the boss room is the next stage. The data is just next to the room before. The door is from the same room. With room I mean one of the 18 stages the game is build on. Some rooms are split in two sections and the game pulls the same level data but does check for the section by checking if the section is a even number or not for triggers to be used. I made a practice ROM for this game and you can visualize stairs there. The boss door does work but the devs did put the trigger 8 pixels into the ground/air to prevent it to be used. So far this could not be exploited in speedruning.
Another great video with in-depth and easy to follow explanations! I always look forward to seeing new videos from you in my feed. Thanks for all you do.
Thank you!
Awesome! Altough I enjoy retro speedruns I didn't know how the speedrunners know how the guts of the NES work and in this channel I discover gorgeous secrets from time to time. Thank you!
I love the warnings about technical content. Bro that's the whole reason I'm watching the video :)
I think some viewers click on the video and don't expect a technical dive to this degree. I guess I just wanted to warn them. Ha!
that's a quick and efficient way of explaining the frame rule!
A better explanation of frame rules than that common bus analogy alone.
Wow, great content! For me, as a computer scientist and as someone who loves old games, this is the best RUclips channel today because of the innovative, technically deep and analytical content. Hugs from Brazil!
I remember watching Wolf the day (or maybe it was the day after) he'd discovered this application of the trick, and he was explaining it on his stream. It was pretty amazing that a giant chunk of time had been knocked off of a game that had been plateaued for so long. Very cool.
Incredible. Thank you for explaining it in terms most people can understand.
I got into programing because I wanted to know how videogames worked. Thank you man!
Nice video! I still don't understand it 100%, but you gave a nice demo of the behind the scenes of how an NES game operates, and I appreciate it!
This is one amazing video. Explained in amazing detail. Imagine having to do this live every time you want to try for a world record. 14:15 actually made me go "OOOOOOOH, so thats how that works." I will subscribe bacause of this :D
This is the most underrated channel on RUclips.
Another great video! It's so cool to watch how the screen gets updated in code. I'm so glad I found this channel, I got inspired to try RAM watching on Mega Man X. I always liked playing as the other robot masters in Mega Man: Powered Up and thought it might be fun to try playing Mega Man X locked into one of the boss's weapons for the entire run. I eventually discovered several things:
1. The on-screen "lemon count" is controlled by a universal code: 7E0BDBYY, where YY = # of lemons that can exist on screen. All weapons use this code, so it's possible to rapid-fire Storm Tornadoes, but that eats up a lot of performance!
2. 7E0BDBZZ sets a weapon on X, where ZZ = a boss weapon where values are offset by 2. 0A is Storm Tornado.
3. Even with the above weapon code on, energy still gets consumed. Each weapon has its own code, 7E1F905C for Storm Tornado. The 5C sets its value to 92, which is the max energy a weapon can have.
The only issue with codes 2 and 3 is that having any one of them on tells the game that X has defeated that boss. I still want to fight the bosses in their own stage with their own weapon, so my next step is to find out where codes 2 and 3 write to and see if I can find out how to prevent flagging a boss as beaten.
Anyways, thanks again for this amazing content and keep up the good work!
FINALLY someone explained this exploit well. I'm a programmer and never could understand how this worked until now. Thank you!
This is the kind of content I keep coming back for, great job!
YES! Thank you for tackling this one!
Now I'm looking at Mesen's PPU Viewer for the title screen demo playthrough and seeing the columns loading in as you've described.
The system seems much more fragile now that I look at it and see it happening in real time.
A game is just smoke and mirrors, as I like to say.
@@williamdrum9899 I am something of a hobbyist game programmer, myself (and I'm sure a number of other viewers of this channel are, too). I just have never gotten very far with low level assembly in the wild.
At some point I'd love to try my hand at some 8-bit or 16-bit homebrew, though.
@@maverick_loneshark You should. It won't be easy though. Game consoles are harder than home computers since you have to do almost everything yourself, but they have the benefits of tile graphics and layering that computers dont have
Well done! Loved the video! You know I sincerely believe you could be a announcer for tv Programs lol. You have a great speaking voice.
Love your videos , thank you for taking the time to explain these mechanics.
Analysis of speed runner stuff, this is gold! :D
Wonderful explanation and visualization of a glitch that I was never able to understand before. Thanks!
I still can't really grasp the details of the assembly, but your videos provide an excellent explanation! They're always awesome :)
I've seen this kind of level loading before! Years and years ago, I played bad dumps of SMB1 ROMs that exposed the scrolling right on screen, drawing/deleting chunks of graphics, either exactly like this, or at least very similarly. (I've also seen it happen when using some goofy homebrew GameGenie codes with SMB1, to make silly antics and fake "new worlds", heheh. Fun times!) As soon as you started showing how the graphics are loaded/unloading off camera - it was like a breakthrough, completely out of nowhere. I had *forgotten* I'd ever seen anything like that - but now that you've showcased and explain it in this video - I do believe I finally have some understand of just what I was witnessing, the whys and the hows, given I was totally baffled by it way back then, though morbidly fascinated with it occurring so unexpectedly. Thank you for this video! I truly enjoyed it.
thanks for the video, it still amazes me the level of detail it takes to achieve these great things.
I love a good nes glitch breakdown video. That era of gaming just has the best kind of jank
Impressive breakdown and a well made video. When Nintendo power was the closest thing we had to cheat codes, discovering these bugs were monumental during gameplay were monumental.
Really awesome as always!
Thank you for covering this!! I was wondering if you'd make a video about this one!
I love your videos. Your description is master level and I enjoy it a lot. It's quite amazing how much a person can break a game.
This is excellent. You find creative ways to make programming bugs and glitches easily understandable for the layman.
Thank you!
Anyone watching these video's Please consider supporting Displaced Gamer on Patreon to Keep this content going. These videos are heavily edited with exceptional quality! Please help this channel grow...Thanks!!
I had no idea the NES was so complicated and efficient. Really makes one appreciate the work developers put in to bring us quality 8 bit games.
This would be a fun one for an alternative video with additional deep dives on. I remember watching SBD and Thiagoch shortly after the exploit was found. Was a trippy experience to be sure
When you start recognizing speedrunners by name from watching too many summoningsalt videos
Thanks for the work you put into this. You made it understandable. Being a loooong time Castlevania fan (buying the first game when it dropped, yeah I'm that old), I never knew this was possible. But I was able to get it to work and I'm practicing speedrunning this game.
To think I was going to skip over this video and then it just turns into the most mind-blowing Castlevania video I've ever seen!
Thanks for watching!
Super cool. I thought Castlevania had to be reaching the physical limits of human possibility but apparently not!
So awesome to see games picked apart in this detail. I think diving into the mechanics (sometimes deeper than the developers) is one of my favorite parts of speed running. Especially when you see a game broken open like this.
I think my favorite personal experience was breaking down bot arena 3 into an action combat game to try and shave down my time under 15 minutes (still haven't but it's a work in progress). Normal gameplay sees you just letting your bots fight and maybe telling them who to attack but, with very careful use of the movement commands and an understanding of how the ai is coded you can abuse slight differences in weapon range, pick apart much stronger bot teams with focusing fire and decreasing your opponent's damage efficiency, controlling (usually) two bots at the same time in this manner is what makes the run fun imo. You also have to try and improve your damage efficiency to keep the time for each battle down. Still working on strategy for the god run where I oneshot the first 4 battles but when I do it'll be awesome.
There are many different hacks that I would love to see with Castlevania 1. Can these be done? 1: Double jump. 2: Whipping as rapidly as you want. 3: Spawn whip upgrades when you already have the best whip, (what will happen?). 4: Movement not being locked in the stage advances. 5: Getting the boss orb from candles or regular enemies. 6: Getting the invisibility potion to never wear off. (Will it reset in stage advances or after the bosses?) 7: Getting invisibility potion from every candle. 8: Making holy water burn forever. 9: Adding the jumping sound from Super Mario Bros.
Amazing video as aways, great stuff to learn about!
enter the most dangerous of vampires: the Codewalker. half vampire, half code...
Great job as always. Very interesting glitch. You can see they tried to prevent it from happening from all the attempted overwrites on the same column.
From the way you described it the only way I can think of to fix the glitch would be to use two block counters. One for the left and one for the right. With that they shouldn't have to redraw the same column so many times either - it can probably be done every 3 or 4 frames instead of 2. Haven't done the math...
Which brings another thought. The amount of memory reuse NES games had was astounding. Keeping it all straight in your head must have been insane. I'm surprised these games work at all to be honest.
Ah, I frickin love this channel, I still have plenty of content to go through but I always watch new uploads once I catch them. Would you mind listing the particular music tracks used in this episode?
9:30 Did you animate all of that by hand in AE, or were you able to use some sort of AE expression? Or was all that visualization built into the emulator you were using?
I wrote it using Lua scripting that is built into the emulator (Mesen).
Holy hell. It's realy amazing to see new things discovered about og cv.
Neat analysis video! Thanks for uploading!
Never expected to jam to the instrumental version of AEJ's DiscoVision
Fascinating how Games were developed back then to even give the IMPRESSION of a fully crafted 2D World due to ridiculous Hardware limitations 👀
Back in the day when this kind of stuff happened while you were playing it screwed up your game hard and you were pissed.
Now we've got people spending their free time learning how to intentionally cause these glitches for the sole purpose of... playing less of the game.
Off-topic, but you have an absolutely dreamy voice with great pacing and tone. Could definitely be a professional broadcaster.
Absolutely amazing video, as always!! Your visualizations and explanations are unparalleled. Personally, I'd love to see more assembly walk-throughs, but that's mostly because I'm learning NES coding myself :) One question: Why is it updating each column twice?? Seems like a lot of extra work. Is it a workaround to the "bug" that it might not complete drawing the column the first round through due to player turning? I feel like it would've made more sense to queue a full column draw once (e g by having two ints -- one for which column we're currently drawing, and one for which to draw once we're done with all the rows), rather than changing mid-column...
i remember things like this accidentally happening when i played it way back in the day on the NES....i seem to recall a level with garbage on the right side and jumping and dying and might have done something where i climbed invisible stairs but it was so long ago.
I think I see the reason why Konami had to draw the background column twice. A workaround to fix this very exploit, probably due to time constraint.
Meanwhile, Megaman 1 did not put the scrolling on alternate frames. So you can lag the game by going to a scroll boundary and repeatedly move left and right quickly. The TAS uses that to cause lag, and there's a bug in the game that can sometimes cause incorrect code to be executed if a frame lagged.
Top shelf content! Love it!
So it's like solving a 15 puzzle. Shuffle around the tiles that you don't want while maintaining the tiles you do want. Very cute.
Most impressive investigations here, sir 👍
Have absolutely no doubt - the next video's gonna be even more fascinating discovery!
In the meantime I'd like to leave a suggestion for 1 of the following episodes: the trick behind Ocean Software's JP screen update with NO garbage graphics inside V-Blank column ☝️
Awesome breakdown! Can you please make a video about Contra Force? It was notorious for its slowdowns, I think it would be great to think of what optimizations could be done to make it less laggy
Nice video!
Usually when you explain glitches, there is some tricky corner case where the code turns out to do the wrong thing.
But in this case, I'm impressed just how off the solution is to begin with -- who would have thought that this would work? Just keep repeating reloading the level data and hope that all tiles will be hit before you get there -- it doesn't seem like the code was written to care about the fact that you can reverse direction at all. (I wonder if Castlevania was originally like SMB1, where you can't?)
But maybe as you said the intention was to have separate block counters for left and right, then it should have worked. So if that was the mistake that created the glitch, it would still make some sense.
I guess that the fact that it keeps reloading the same data for a while made the glitch uncommon enough in practice, so maybe no one noticed?
One question: You say that each column is loaded twice. But the block counter only needs 6 steps to reload one column. Does it still repeat after 8 steps, and just do nothing during two of them?
They did know about it this is why they load the data twice. It is very unlikely to wiggle all the time what need to be done for this glitch to work. And you see how long it toke to be discoverd. I think this was the lazy solution and they did change it in later games.
Where are we and where are we going? That's deep, if anyone knew?! Also great video, love these!
10:28 I guess the tiles are not actually read back from VRAM, but the game has a separate buffer to read them from that is updated in sync with VRAM? As far as I understand it, reading from VRAM on the NES is not very practical (maybe except during vblank).
Yes, NES games generally keep a collision map in work RAM in sync with the contents of VRAM. One game that *does* have to read back from VRAM to handle collisions is Life Force--its main collision map uses just 1 bit per tile, so when a bullet is about to collide with terrain it has to read from VRAM to distinguish between destructible terrain (e.g. the cell walls in stage 1) and regular solid terrain. The Japanese version Salamander didn't have to do this because it had additional RAM in the cartridge, giving it room for a 2-bit-per-tile collision map.
This is a wonderful extension to Summoning Salt's videos!
So each block in a column gets updated twice during that column's life cycle? Can we assume that the double updates are a simplistic method the programmer used to prevent blocks from getting skipped under "normal circumstances"? (i.e. when the player is moving in both directions but is not intentionally trying to exploit the engine)
This one is now my favorite. I love glitching stuff.
"The Belmont knows where he is at all times. He knows this because he knows where he isn't. By subtracting where he is from where he isn't, or where he isn't from where he is (whichever is greater), he obtains a difference, or deviation. The PPU subsystem uses deviations to generate analog video signals to draw the Belmont from a position where he is to a position where he isn't, and arriving at a position where he wasn't, he now is. Consequently, the position where he is, is now the position that he wasn't, and it follows that the position that he was, is now the position that he isn't.
"In the event that the position that he is in is not the position that he wasn't, the game has acquired a variation, the variation being the difference between where the Belmont is, and where he wasn't. If variation is considered to be a significant factor, it may be given its own category in speedrun rankings. However, the Belmont must also know where he was.
"The PPU logic works as follows: Because a variation has modified some of the information the Belmont has obtained, it is not sure just where he is. However, it is sure where he isn't, within reason, and it knows where he was. It now subtracts where he should be from where he wasn't, or vice-versa, and by differentiating this from the algebraic sum of where he shouldn't be, and where he was, it is able to obtain the deviation and its variation, which is called a 'glitch'."
Amazing graphics with that scripting, thank you for explaining it so well!
Doing the Lord’s work my friend.
I’m starting to sound like a broken record, but thanks again for the great content. I need stuff like this to distract me, I really appreciate it. Hope they are as fun to research and make as they are to watch.
Every project usually has at least one moment of "OH!" during investigation.
Thank you for doing this. Will you be doing videos on the other two Castlevania games for the NES?
This video shows how elegantly the original game was designed. It's tempting to think of old games as primitive, but the developers achieved so much with so little computing power
What amazes me is the fact Nintendo engineers had to figure all of this out from scratch in 1983 when they decided to make the Famicom/NES. It’s mind blowing.
Amazin I was just thinking about this following watching the wr
that was fascinating.. thanks for the video
Love this channel! Your content and a couple other chans have me learning 6502 assembly. Something I wish I had the resources to have learned as a kid honestly. Speaking of that time gone by, do you think the creators thought people would be playing, let alone analyzing its code 36 years later?
Gosh. That is an interesting question. While it is possible they wondered about longevity, I assume most were always looking to create the next thing and stay ahead of the game (no pun intended).
"I'm a programmer, not a speedrunner." *Drops mic*
Your videos make me feel like I could learn coding and make my own Nintendo and Genesis retro games
It's doable, but requires great discipline. I've tried and given up a few times, but don't let my weakness discourage you