Destroying and Reprogramming the Sprite Engine of Ghosts 'n Goblins - Talkin' Code Episode 6
ฝัง
- เผยแพร่เมื่อ 7 ก.พ. 2025
- If we change some code in Micronics' Ghosts 'n Goblins for the NES, we can see how the game might run at 60 fps.
If you would like to support this channel, here is a link to the Displaced Gamers Patreon page - / displacedgamers
Twitter: / displacedgamers
Facebook: / displacedgamers
Instagram: / displacedgamers
Music by:
/ hariboosx
/ @wolfandraven
#NES #Programming #Code
i don't think you necessarily have to make your reprogramming extremely 'youtube friendly' i honestly just love watching you reprogram stuff
same!
No kidding. Making shit "youtube friendly" is the quickest way to get a lot of people to stop watching entirely.
Well he's going to need viewers to keep doing it
@@ObscuraDeCapraAgreed, this is a niche channel. We're here for what normies consider "boring" 😂
Yeah. Those who don't care about programming won't watch this no matter how friendly his programming is
You made this SO compelling. It's really hard to make talking about this stuff flow and feel good to watch and you totally crushed it
Thank you! I tear up the script quite a bit to try to get flow to work. I feel like it is worth the time.
"My chronic sprite pain" killed me lol
Same lol
Presentation is getting better and better. I liked the transition from code on screen to code on paper. Smooth.
Yeah that was pretty neat
Indeed. The code on paper was an excellent way to show that.
Yeah, good stuff.
I think what this really shows is the importance of having a way to profile your code. The original developer presumably thought that going through all the code to optimize it wasn't worth their time - but I doubt they had any clue that _most_ of the CPU time was spent just in those two small routines that do the simple operations of "fill with FF" and "copy and reverse". If they had known that, maybe they would have given them a closer look.
That assumes they had the time to do so. Odds are good the programmers were being rushed to get the thing out the door on a deadline, so they just tried to do it in the safest way they knew how (hence filling memory with known values).
There's also the fact that the tools we have today to profile code... basically didn't exist back then. The kind of visualizer that could go through and show exactly how long a routine took relative to frame time wasn't a thing. There were some tools, but they are *nothing* like we have today.
It was already known back then that you can trade off rom space with speed. They had the clue.
That's the problem when you work with deadlines, you don't make a good product, you are making a product in time.
It's very common for games mid-development to be severely unoptimized because optimization basically implies knowing what work must be done and guiding the CPU to do exactly that much, while the simplest algorithm in many instances is "do everything from the beginning every time". If you take the simple path, you can reach feature completion faster and also make design changes if necessary because you have less code and fewer assumptions to iterate on.
Early optimization actually presents a major issue when you start coding on top of a tech demo: you can often land in a place where you are throwing around gajillions of sprites or demonstrating an enormous world, but the assumptions you made to get there impede every other kind of gameplay feature.
Edit: something else I'd add is that Micronics seems to have preferred making configurable, reusable code in almost every instance, as with the sprite page pointers that can write to either page 2 or 3. That's a tradeoff that harms optimization, in that it defers the final workload until later. But it does mean more of it can potentially be reused from one game to the next.
@@GeneralBolas You're right and you're underselling it. These developers had no support from Nintendo in 1985. They had to burn a game to an EEPROM and run it to test it with no profiling or debugging. Editors were not IDEs; if you've ever written BASIC on a 1980's PC you can begin to feel how this isn't anything like putting text easily wherever you want. With this subroutine, the developer gets a reliable tool that takes less typing and is hard to mess up.
And that all assumes this wasn't considered a smart choice the replacement code saves cycles and takes bytes. Every switch costs 3 more bytes on this function (about). If you consistently uses this subroutine philosophy without other functions you could easily save 100-500 bytes.
On Ghosts and Goblins, 500 bytes still isn't a ton. The cart is 128KB. But if we assume the code was shared with old Micronics games we'll look at 1942; that game had 32KB of program ROM. If you consistency shave code for subroutines, it matters.
None of this is to say that it was ideal, but it wasn't cluelessness. We're the ones obsessed with the ideal version of the game. They needed to fulfill the contract.
@@JH-pe3ro Also optimization tends to be one of the last things you do when making a game, which is why it is often what ends up being half assed when faced with a deadline.
You have a fully working game that performs poorly, business people don't care about the end-user experience and don't agree to shift the deadline for optimization work.
You might think bug fixing would be the last thing done, but optimizing the code can make fixing bugs quite complex.
I don't know how popular code review/change is on youtube, but I will say I'd watch it no matter how complex it was. Your videos are amazing.
Thanks for that. I was uncertain how well a code review would work in an edutainment channel type of space.
This is some of your best work. I love watching you identify the problem, and then explain how to fix the problem! Please don’t dumb it down for our sake, we are all a bunch of nerds here and it helps us learn!! Keep up the great work
Thank you for the encouragement!
the reason you liked it is that he smoothed out and polished the experience. you call it dumbing down. he call it perfecting the content for a wider audience.
I say he should keep doing what he's doing. It is working.
This is my favorite TH-cam channel of all time
Hell yeah!!
Same.
For what it's worth, I've only ever done extremely basic coding (IRC bots back in the day and very simple python scripts since) and I still really enjoyed watching this video. You did a great job with the presentation; visualizing the areas where time could be saved, explaining why things were slow and then how to make them faster, and then visualizing how much time _was_ saved. The bit at the end showing the 'potential' FPS was especially good.
I definitely hope you continue with more of these sorts of projects.
Thank you! Perhaps this video works as a template of sorts when it comes to presenting optimization in future projects.
The green, yellow, and red bars at the end were my favorite part to do as I just tagged them onto the project after a bulk of the work was already done.
@@DisplacedGamers I was super impressed with it -- makes it so easy for the viewer to understand what's going on.
Don't dumb down anything, please.
Thats why we like you.
Agreed. I’m an engineer my friend who likes these videos is of eng-curious orientation, he appreciates the complexity. I suspect most people fall into one of these two categories
yes, no dumbing down, please :) I love this channel!
I feel it's worth noting that optimizing code in 2025 is a _lot_ easier than doing so in 1985. Not just because we have computers that can casually run debug tests in the background, though that certainly helps.
The other big advantage is that _Ghosts 'n Goblins_ (1985) is now considered a complete game. We know the exact parameters that the game will need to operate under. One instance of that was mentioned at 10:13, but there are almost certainly others we can't reverse-engineer. The programmers probably would have loved to optimize the game, but any optimizations they did might get wiped out next week if they had to refactor a bit of the engine to adapt to scope creep or fix a newly-discovered bug or something. So they made code that was flexible and easy to rewrite, easy to tweak if needed.
Maybe the G&G team would have made a more optimized game if they'd set a few more weeks aside at the end of development to make the game less janky without adding anything new. But the programmers don't decide the schedule.
There's also the fact that, once the decision was made that the game would run at 20 FPS, tossing in a bunch of optimizations to push it up to 30 FPS (let alone 60) would be a pretty huge deal. You'd need to *prove* that your series of optimizations didn't break anything, that the game and sound logic all still function correctly, that the gameplay is unchanged, etc.
Past a certain point of development, that's just not viable, as it would run a major risk of delaying the game. So even if you knew you could probably take a week to push it to 30, that's not something you'd likely be allowed to do if you need to start burning test EPROMs to get it out the door next month. So unless the game were failing to hit the target framerate, "good enough" was likely where it was going to be.
The console also wasn't as well documented.
Yep, you need safe redundant code that's going to work in unknown scenarios so you do what worked last time.
Opening with a Galaxy Quest reference. We're in for a special treat, ladies and gentlemen~
God, that whole mess with changing that loop that needed 16-bit handling down to an 8-bit one... Brought back war flashbacks from college. The professor put a question on a test where we had to program an 8-bit processor to divide two 16-bit numbers. It took 3 hours to figure out the program. The test was an hour long and had 4 other questions. Nobody could figure it out in time. The professor didn't see the problem. After all, he knew the answer, so it must not have been hard!
So damn cool. I always suspected so much of this was left on the table back in the day. Amazing to see clear examples of what was and how small fixes make all the difference.
Thanks, Adrian!
Woah.... that hand looked SO REAL!! You've once again outdone yourself!
That hand is clapping at your comment right now. ha!
@@DisplacedGamers So what *is* the sound of one hand clapping? 🤔
@@KernelLeak Bart Simpson has an answer for you.
Never said it was alone.
@@DisplacedGamers heh.... what OTHER secrets do you have?!?!
This is amazing!
Also I love how the infographics are bleeding into real life now with a hand, a marker and stuff.
It was so nice to shoot SOMETHING on camera to fill the time rather than do everything in photoshop.
I appreciate the focus on structured, profiled, proof-driven optimisation rather than guesswork :)
This was rad. I appreciate you taking up the encouragement you were getting to make this video.
I'm prepared to see you go even further in the future. 30 or 60 fps Ghosts n' Goblins would be so cool.
Excellent video!
I optimized the codes of Final Fight 3 (Final Fight 3 Optimized Hack) for the SNES and the part that helped improve performance the most was optimizing the routine for sending unused sprites out. Before, it was a loop that changed all 4 bytes of the sprite attributes (remember that the SNES has 128 sprites, so this loop occurs 128 times). I replaced it with an unrolled loop that only changed the vertical position. This uses a lot more bytes, but fortunately there were plenty of them to spare.
Unfortunately, many games on the console used a giant loop for this.
Another bottleneck on the SNES is how the game will deal with the 2 extra bits per sprite. The first 4 bytes work the same as on the NES, but the 2 extra bits are a nightmare to use, because each byte in the table will have attributes from 4 different sprites. Another easy thing to mess up and lose performance.
Wow! Thanks for sharing your experience with this.
And doesn't the discovery of that fact other games use a giant loop make you wonder just how much optimization was left on the table for those games? How much better could the performance be for those games had the programmers been provided just a bit more time?
I checked out the readme/changelog on romhacking for FF3OH. Thanks for listing your changes like that. I am obviously interested in behind the scenes details.
I think you nailed the amount of "optimization jargon to youtube friendliness"
Enough optimization to show impactful changes, but still leaving us room to try figuring out stuff ourselves.
Really loving the content!
I've done something a bit like the copy and reverse code that you write 16:05
there's actually a tiny bit better way to do the loop, by copying from & to 4 separate sections of the page, which allows you to remove 3 of the 4 INX and DEY instructions, further cutting the cost by 12 cycles. but then we need to move stuff around a bit more to make it work a bit more cleanly without having a CPY instruction which would take 2 bytes, so we use the TYA to only use 1 byte at the same cycle count to test for a zero. leaving us at 10 cycles saved each time it loops.
so in total, there's a save of 640 cycles compared to the one with 4 INX and DEY instructions. but with that, I don't know how it could be optimized further.
\/ so the code would be more like \/
Copy_All_Sprites_from_OAM_200_to_300:
LDX #$00
LDY #$40 ; Lowered because it's not decremented 4 times each round anymore
Copy_All_Sprites_from_OAM_200_to_300_Loop:
DEY ; Moved the instruction to make it easier to work with the exit of the loop
LDA $0200,Y ; Takes $0200 - $023F
STA $0300,X
LDA $0240,Y ; Takes $0240 - $025F
STA $0340,X
LDA $0280,Y ; Takes $0260 - $029F
STA $0380,X
LDA $02A0,Y ; Takes $02A0 - $02FF
STA $03A0,X
INX
TYA ; Easily check the Y register if it's 0
BNE Copy_All_Sprites_from_OAM_200_to_300_Loop
Nice!
I went down a rabbit hole of optimization when I was putting the video together and thought perhaps I should pull it back a bit for the video - Plus I KNEW that fellow programmers could take to the comments and share some awesome stuff.
(I am not only glad you shared this - I am happy the formatting in the comments lines up. I hope YT didn't give you too much trouble with it.)
that's not surprising me @DisplacedGamers
I would have went in deep with optimization aswell, but that's because it's something I love to do as much as I can. it's also the topic I love seeing the most, along side how different glitches happen.
surprisingly the comments just worked out right from the get go with the spacing of them which was nice.
This is to Ghosts 'n Goblins what Kaze's entire channel is to Super Mario 64. Gimme more of that delicious assembly optimization! I want to see this game hit a locked 30 FPS.
This is such a cool series, I really hope you continue on with more optimizations. This is why I love to program these retro machines, your resources are so thin and optimization is so important it really puts your skills to the test. So much more fun and interesting then modern systems. It's so satisfying to make a machine do the "impossible".
I really enjoy programming while keeping the hardware in mind. I appreciate the fact that modern computer and console hardware provide those extra layers and resources that let programmers just get the job done, but squeezing the most out of hardware is very satisfying.
@@DisplacedGamers You aren't wrong, even when programming these old systems I wouldn't want to do it without modern tools!
Watching you optimize code gives me the same sort of satisfaction as watching Cracking the Cryptic go through and figure out a Sudoku puzzle :)
This was so satisfying to watch. I'd love to see another episode of this where you optimize the game even further.
Oh yes! And make the game play at 30 (and/or 60) fps.
I really love this. It's exactly what I want from your channel. It's a lot like Kaze Emanuar's work on SM64. It's extremely satisfying to see these optimizations
The reactions I have received from the video surprised me a bit. I knew I was basically going "full code mode" on this one and was concerned about audience interest. Guess I had nothing to worry about!
I'm loving this. I'd definitely like to see more optimization videos like this. Even a follow up to this where you do the aforementioned "total gut job" of the Build Sprites segment would be welcome.
your content is so very coherent and shows the practical process of programming better than almost any pedagogy I've ever come across.
I started making a 2d game from scratch in JS/WebGL because of you xD and your videos. Designed with a sprite canvas layer and a background canvas layer in mind. It's been quite fun learning about these common NES game patterns.
I gotta be honest, that you want to do a code review and optimization is what makes it fun. This is super practical, it's true edutainment: I learn about something in an exciting way. I mean, presentation matters, but even your less scripted stuff is very watchable/listenable purely because you are quite knowledgeable and talk with coherent competency. So, yeah, let's do this, Chris! Excitement!
This is called “technical debt” Just in case anyone was curious what it looks like when an engineer doesn’t get enough time to finish their work lol
If you were a teacher explaining this stuff to me when I was a teenager I would have opted to be a programmer. You do a really good job of presenting this.
Wow. Thank you!
Interesting thumbnail choice
That's for sure
looks like AI??
@@AmareloStudios The hands look too good for AI, unless it was touched up by someone afterwards. Also, it's Princess Prin Prin from GnG.
@ no hands have gotten much better in the last few months
Someone hasn't been keeping up with AI 😂@@bojangle
Loved that smooth transition around 8:35
Top 5 fav channels on YT right now. Love your work, brother!
I really love these videos by the way. It'd be fun to load some of these changes onto the eeprom nes cartridge I half-built when I was a kid.
We need more content like this. I have so many things I want to know still about a few games.
I'd like to see this pursued further, this is incredibly interesting, and would be even cooler if one day we could play it fully optimized!
Love your content. This is the kind of 'tinkering' video I've been hoping for. Your other videos with "what could a Game Genie code do" are great. But this is the Next Level I have been wanting you to do. Good Job!
I think this is my favorite video of yours. I really enjoyed the reworking for the FF fill and sprite building.
The Assembly on paper reminded me of first stepping through the code for the NES Bubble Bobble password system back in the day.
This seems like your most in-depth Assembly work in a video yet. Wonderful and inspiring, as always!
Wow. Thank you for your comment. It was fun to just hit record and draw through stuff for a more natural flow.
You really stepped up your game for this video. I liked how the code screen became code on paper! What a neat transition.
This was a remarkable journey. It's so entertaining to listen to this old game optimizations! Thanks for the video!
Nice. I like the assembly walk thru on my old favorite games. Going through someone else's code is always fun ... when you're not getting paid to do it!
Seriously. Was also happy to not be on a deadline!
@@DisplacedGamers [JIRA-42069] If you ever get into 68000 and the Genesis/Mega Drive, I'm curious as to how the cart swap trick worked. I assume the same game engine or code base was used so the memory registers were reused between games, like NES Tennis and SMB. Specifically, starting Forgotten Worlds or Space Harrier II (I forget which) and enabling the debug menu, then hot swapping Fist of the North Star/Last Battle let you choose your levels. No rush at all, it might be an interesting topic to dive into given the code might be shared between those games, and I enjoy your presentation style.
That reference in the first sentence was absolutely top tier. Well done, sir. Well done indeed.
Man... I have but the faintest idea of how coding works, being a fan all of my life but lack the mindset, concentration and knowledge to actually try it. But sinking half an hour of my day into a coding video is a miracle in my life only you could accomplish! Thank you very much!
Thanks for keeping a great channel alive! I'm learning a lot from your videos!
Really happy the code is also dark most of the time. Makes this easier to watch at night
Have watched a bunch of your videos. Your editing is remarkable. Well done!
Thanks!
Im not a programmer, but Ive always found your content facinating, but Ill say also this video has been pretty enjoyable to watch! I hope these vids reach bigger audiences because they certainly deserve it!
I really do love these videos. I'm an ex-BASIC, ex-FORTRAN, ex-PASCAL guy and this brings some wonderful memories to mind. I don't think I could write new code, but I certainly understand the revisions that you're doing. TY!!!
I'm no coder and I don't understand most of what's said here but the way you explain it is done in a fun and friendly manner which kept my attention despite being clueless, very well done!
I absolutely love this video. Your visualizations are (as always) top notch, and you manage to present things in a way that seems to work well for people on both sides of technical knowledge.
Thank you. I try to make content that appeals to those that love to program and those that are simply curious.
Fun to watch, you had me at code optimization
I don't fully understand everything, but it's really neat to watch. Great work.
cannot wait for Ghosts and Goblins: Displaced Edition
I love your videos, DG! I’ve always wondered how games actually work and I feel like I’m learning going through you content backlog. Thank you for creatively making coding entertaining.
I want to learn assembly and your explainations alone are very captivating, so I would LOVE more content like this!
Just do it. Assembly instructions are simple, especially in such an old processor design. Assembly is hard because the instructions are so simple you need so many to get anything done, not because the instrudtions are complicated.
I think this was really neat to see. Really amused by how you sheared the yellow box down so much!
Ahh the potential is there!
I'd love to see this classic game run at mostly; if not fully; at 60 FPS! 😮
I'd love to see it run at 60 fps as well!
Your older videos played a huge part in teaching me NES coding, and pushed me to make my first NES game! (It’s called Firewall on Itch). That knowledge made it possible for me to take in these optimizations and I followed along at every step! I’ll even bring some of these optimizations with me :) thank you!!!
This was a great episode. Really interesting to see how such a small change can have such a big impact.
Perfect timing while I just watched some other videos on the channel!
Probably one of my favorite video of yours so far. Keep up the great work!
I really really wish you'd release your code optimizations as patches. We should all be able to play the improved better performing version of the game!
The optimizations I did in this video are more along the lines of little exercises rather than a real patch. At best, they will remove a little bit of the jank. The game still runs at 20 fps even with the current optimizations.
If they help someone else pick up the project and put something together, I encourage them to go for it!
Even if it's not enough for you to release, I think people will appreciate those changes and probably could help to make new patches and quality of life changes.
Amazing!!! You are doing an excellent work. I can't wait for episode 7!!!
Amazing episode, dealing with nes asm for a few years I was shocked how messy the code was, I also like how you only switch the Y position to hide a sprite instead of writing to all 4 properties of a sprite. Great video!
This was a lot of fun, and satisfying. I'm going to be late for work now and I don't even care!
Thanks, but also - oh no!
@@DisplacedGamers My boss just announced that missing the morning meeting will be reflected in our bonuses.
But anyway, I played GnG back when it came out and this "jank" (word didn't really exist back then) was always really annoying. In fact, I remember my friend's mom took us to Gemco and we were sitting in the back of the car on the way home trying to decide if the screenshot on the box was really the NES or arcade. I was right! It's the arcade.
i really like your work. it puts into perspective how much artistry went into these games. and it reminds me that all forms of engineering are really about answering the question "what's just good enough?"
As someone with practically no code expertise and considers much of what's shown to be moon-speak, I still very much enjoy watching these videos, and I at least am under a delusion I understand more when you have visuals to go with it.
Absolutely love this stuff, please keep it coming ❤
Amazing video! I don't program in assembly language, but I love watching your videos of code reviews to get me in that creative space to tackle my own programming optimization problems. I think you found the right balance of detail to edutainment, but I agree with the others that this niche audience probably leans more towards detail.
Keep being awesome, excited for more Talkin' Code!
I would really like to see a full series of optimizing all the way to 60fps. This is a fascinating video.
Another fantastic episode. There is something deeply beautiful in pushing little bits around. And you are a master of didactics.
It's a good video. And thorough.
Videos getting better each time. Good work. Please don’t start chasing the audience too much though, this is just right as it is!
Your best video yet. Always wondered what you could improve or fix if you weren't limited to Game Genie codes or other simple changes.
The side by side is night and day, nice work. Super Dodge Ball might be one that's worth adding to your list of potential projects.
0:50 the official definition of "jank"
Honestly, I don't know much of anything regarding assembly.
But your videos, explanations, and patience for your viewers makes this incredibly entertaining.
It's wonderful to see under the hood why the games we loved were so bad, and how they could have been so very different.
Thank you. Keep doing whatever you want to. You've got a core audience.
Thank you so much. The videos are hard work, so comments like yours are very encouraging.
Would love to see more of this, it's fascinating! I've always been a sucker for resto-mods - that old thing I'm nostalgic for, but better than ever? Feel like this scratches the same itch for me.
See, now I just want to see you take this further and optimize it more.
This is like Kaze Emanuar and him tackling the Rambus for Super Mario 64
This was a great video. I know you said you were concerned with how to make code optimization into a good video and you succeeded! I've been following your channel for years and it's clear how much you've grown your communication and presentation skills.
Now, is there any chance you could be convinced to make more videos about the journey to 60 FPS for Ghost 'n Goblins? Or, more optimization videos in general? Seriously, this video was a lot of fun!
Such a great video, Chris. I love your Behind the code series and I think follow up videos where you repair the code would be just as great to watch, mostly for two reasons. One, I'm trying to learn assembly coding and videos like this are exactly what I need. And two, there's something therapeutic to watching messy code cleaned up to peak efficiency. Kind of like why videos of dirty houses being cleaned or overgrown lawns being mowed have become popular.
And why the code is so bad I can only assume it's ported from a different system and little time was given to optimise it for the 6502 processor. That's my guess anyway.
Love love LOVE this video! And the IRL hand jumpscare was great haha.
Just rewrite the whole game! You know you want to..... :)
I'm really enjoying this series. It's been a few years since I wrote 6502 but I'm following along nicely to all this. Looking forward to the next one!
Started watching you recently, and this is my favorite video. I hope to see the adventure continue!
awesome job! I remember having so many discussions in the 90s with programmers about how coding was getting too lazy and that developers were increasingly leaning way too much on the rapid advancements in processor power to make up for the lack of optimization. It's stuff like this that really hits that home. People are so obsessed with big silicone companies squeezing ever more performance out of the diminishing gains now realized by die shrinks, but there is a huge amount of untapped potential in code (and code ecosystem) optimization and with processor architecture
That nested copy operating is.. an insane decision for something of this era. WTF.
Great work cleaning it up!
What an awesome follow-up to your earlier code runthrough of Ghosts 'n Goblins!
That was super cool to watch. I've played fastrom and SA-1 hacks but actually seeing you go in and actually rewrite the code with a few small optimizations and gain almost 10fps is really cool. Seeing the gains after fixing the double loop reminded me of the first time I wrote a random map generator when I was fairly inexperienced with programming. It worked but it took like almost 30 seconds to draw a simple tile map. It ended up being something like looping through every tile in a second loop while looping through every tile in the first loop. I think if I remember right i fixed it by changing the order it looped through the tiles so it didn't do the double loop. In the end I swapped two variables and suddenly it generated maps instantaneously. It was eye opening for me. I'd debugged stuff and fixed errors before but it was my first experience speeding something up that shouldn't be slow and it was almost a whole different way of thinking about things than just bug and error hunting. It was really cool seeing something like that at an assembly level in your video.
this is my all time favorite channel on TH-cam
I could seriously watch your code optimization videos all day, so well done and very satisfying to see old NES games improved!
stellar presentation as always!!
i really appreciate the effort you put into explaining the investigation process, and i like the techniques you landed on in this vid for making the code fix process (and its effects) visually digestible-that sort of attention is what really puts this channel above the rest for me.
all my coding experience is with more modern languages but i always feel like i genuinely understand NES assembly a little better by the end of one of these vids...
This was great.
As something of a spaghetti merchant myself, I'm glad that the code I cobble together never needs to wory about fractional, or even WHOLE seconds in its execution lol.
loving this channel.. I used to code 6502, Z80 and 68000 assembly and loved code optimisation.
Are you still following along?
Me: Not at all!
(...but I still like watching all the same.)
I like the part where you worked through editing the code on paper. That made it a lot more clear what you were edoing
Genuinely one of my favorite channels online. Keep doing what you're doing, man.
Seeing old games fixed like this is sooo satisfying. To be fair, coders, often under crunch, have a number of non-engineering limitations imposed on them, resulting in suboptimal code shipping. Fans have a lifetime to deconstruct it. You cover that aspect in the Mega Man 3 vid where you talk about a new coder inheriting an existing engine plus having to support the new mm3 mapper on top of that.