Loved diving into Strider (NES)! This game was requested by several people since the start of Behind the Code. The game has so many odd issues. The sprites stuck out the most for me. A few notes - 1: The Nightmare on 6502 Street is just a fun joke that I was feeling. What I have found in code isn't THAT bad ... I think... (We haven't talked about ooh... Micronics that much yet... have we?) 2: By the way - Strider does have an infinite loop after CPU next frame work is complete. The loop compares RAM locations $4B and $4C to each other and loops so long as they are equal. The NMI routine increments $4B. So when the game returns from NMI, $4B does not equal $4C. That drops it out of the loop. $4C is then saved after the exit condition is met. 3: The NMI handling example in this video was just one basic method. NES developers may end up commenting on their own approach to their games in the comments below. Feel free to leave other specific requests for Strider since I am "in the code" now. That said - I already have a laundry list of stuff with lots of question marks and exclamation points on it. Take care!
Hack suggestion to mitigate this issue: add some code at the end of the NMI routine to force the interrupted code to resume **after** the sprite creation code. This will not save the graphics of the current frame but may reduce the odds that the code will overshoot the next frame again.
Dumb question: in your example at 11:36 why is Frame A merged with Frame B? My naive guess would be that Frame A gets wiped and the incomplete Frame B gets displayed. Instead they are combined into a sort of chimera?! 🥴
Athena was a game that I found oddly compelling but also detested as a child. I don’t know if it has any interesting code to look at but I definitely felt like it was going to fly apart at any moment.
Ooh, yes! Do a Micronics title at some point, please! My nomination would be for Super Pitfall, but honestly, any of them would be a treat to hear about.
Agreed. A game that just works is kinda dull, but a game that's broken through either laziness or just flying too close to the sun is always fascinating.
Final Fantasy II (Famicom) is a good candidate. Many of the bugs are due to the development team running out of both time and space. Many/most games have regions of 0x00 or 0xFF due to not fully using ROM space but FFIIj basically uses every byte. They couldn't even program a proper title screen.
It dawned on me what was going on about halfway through the background explanation leading up to the problem. I just started laughing. Hahaha! And the cherry on top is when you said it returned back to the frame drawing code w/o bothering to give up when the frame had already been drawn. That is truly magnificent. I feel like my life is better knowing this. Thank you so much. Zelda: Turns its homework in late. TMNT: Only turns in half its homework. MM: Completes the extra credit on time, and turns its homework in late. Strider: Turns in homework incomplete, then does the rest of it before starting on the next assignment. LOL This makes my day. What a glorious mess.
Yeah, it is quite silly. Especially given that it has a cascading effect: the frame code is already too slow but they handicap it by doing work for the previous frame. This ensures that even if a single frame ends up being too slow, the game will mess up several frames in sequence because of it. An interesting hack would be to modify the NMI code to ensure the game does not resume building the sprite data but jumps directly continues after the sprite creation code. This would not save the graphics of the current frame but it should at least reduce the odds that the next frame is garbled.
The fact that they alternate which actors receive priority seems like an attempt to mitigate the issue, to make it so that each of them is rendered correctly SOME of the time. So it's funny that it ends up making the corruption more chaotic as a side effect.
Priority shifting is a rather standard operation for NES games due to the 8 sprite limit per scanline. I'll get into that a bit more in a future video on flicker. Of course when you combine that with Strider's issues... yikes.
@@DisplacedGamersI can’t believe that priority shuffling cannot indeed be done on the copy to OAM. VBI are 50 lines. CPU runs at 1.8 MHz so on 18 kHz CRT we have 100 cycles per line. CPU does almost do one memory access per cycle. Most of it is wasted on repeated instructions and IO address. Some shuffling jumps don’t change much. Modern Demo coders would probably fit a lot more into this using addressing modes, zero page, illegal instructions, and self modifying code.
NES sprites will always flicker or be very slow if you have a lot of sprites at once. Priority shifting prevents any sprite from being partially invisible all the time. Flicker is better than invisibility, but don't tell jekyll and hyde that...
This is great and explains so well why Strider looked janky as heck. I'd love to see a deep dive into the collision detection. Especially with regards to wall jumping which always felt completely broken.
fascinating, esoecially you usually expect this type of thing from no name/random devs...not capcom. If Capcom farmed it out to another dev, sure but this is in house. The way larry blends in and out into moe is nuts, lol.
Even in-house development can lean on the B-team, or even C-team coders. There are only so many A-team coders to go around, and NES Strider clearly wasn't enough of a priority to get Capcom's best. Coders were "Zac" and "Mamicyan♡Otona" on Strider. Mamicyan is Masamitsu Kobayashi, an experienced Famicom programmer, who I suspect was involved later to try cleaning up Zac's buggy code as best as he could.
@@ostiariusalpha Exactly. I actually suspect that "Zac" may have been granted a basic framework from Mr. Kobayashi and he really didn't know what he was doing with no help from anyone as what happened all too often back in those days.
The other probable reason - they had very tight deadline for release and no time to spare for fixing even the obvious bugs. Knowing how prolific Capcom was during those times, I wouldn't be surprised if it was the case. Money needed to be made. Projects were being made like hot cakes. It was not worth it to postpone the release.
NES Strider was basically generating an entirely new game from an arcade game that bore little to no resemblance; some of the assumptions of that arcade game's architecture may have leaked into the design of this game. Furthermore, it's very possible that this was meant to use a memory mapper chip that wasn't available by the time the "drop dead" deadline was looming, and so they had to get it working SOMEHOW. And, even more bizarrely, this didn't just have to pass Capcom's internal QA, but Nintendo of Japan's and Nintendo of America's, too. (Presumably also Nintendo of Europe's, but considering the horrible mess this was at 60Hz, I think it would just flat-out refuse to run at 50Hz.) There are a lot of things that could have gone wrong behind the scenes, and a lot of people who should have pumped the brakes on it to make sure that it "just worked" as opposed to "just barely worked". As a coda: The NOA "Seal of Quality" was mostly a transparent form of censorship and software flood control until the early 90s (think 1992 or so) where as long as the game was mostly stable, it would pass QA and get "the Seal". There are a LOT of games prior to 1991 or 92 that are FAR WORSE than NES Strider in terms of stability, playability, and suchlike: Kung-Fu Heroes comes immediately to mind. It's also worth noting that the NES's infamous cartridge slot could have contributed to the instability, and so NOA's QA might have given some glitchiness a pass just as a result of "couldn't reproduce". Around the early 90's is when you saw NOA get serious about QA as a function of software quality as opposed to "we don't want another Crash of 1983 situation", and Sega arguably beat them to the punch (the Sonic 3D Blast "secret level select" incident, for example, was the result of Sega taking crashes and glitches more seriously for longer than previously).
i love the tone you achieve in these videos. there's just enough formality and precision in your writing that when you slip in the odd bit of humor it ends up really punchy for how simple it is. i'll be thinking about "happiness is only temporary. the nightmares are about to begin." for the rest of the day
I had no idea anyone managed to mess up the frame draws so badly on the NES. Like, the first note of programming for the thing is basically "TIMING IS EVERYTHING" and we have Capcom, one of the heavy hitters (although maybe not yet in 1989), making this fundamental level of error.
@@powerkirbybomber6503 I think the Mega Man games had Capcom's A-list talent working on them. Based on another comment, Strider seems to have been done by someone without nearly as much experience with the NES and then had to be fixed by a more senior programmer to get a "sellable" game in a tight deadline (all about that $$$!)
@@powerkirbybomber6503I believe it was different teams working on that. In some previous videos on this channel they looked at Mega Man's code and noted that even within the same game you could see some of the developers had different priorities.
I wonder if the fact this game was only ever released in North America also indicates the quality of work behind it and that it wasn't the A team working on it. Possibly not even Capcom directly.
Holy sprite flicker, Batman! God I never knew Strider NES's sprite graphics code was such a dumpsterfire. Really enlightening how you went through it though, explaining why all the bizarre sprite weirdness happens.
Loved the "Nightmare on 6502 Street" joke. These technical videos (both yours and RGME's) are always a treat and I await eagerly the next Strider video. Keep up the good work!
I swear you perfectly occupy this niche of TH-cam. I have extremely rudimentary knowledge of programming and I can not only follow but enjoy the presentation.
Both Strider and Commando were early Capcom releases, and so suffered from the fact that the programmers didn't know how to get the most of the NES hardware yet.
"But happiness is only temporary. The nightmare is about to begin." is about the rawest thing I've heard on this channel, it came so far out of left field I legit had to pause for a second to think about what I'd just heard. I think what made it better is your _casual monotone_ way of explaining things. Stryder: LET'S FUCKING GOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO-
You dove so much deeper than I did, I just spent a couple of weeks tracing the collision detection subroutine. Hope you'll look at that JP alpha in a future video - crazy how that ROM is also broken, but in different ways, and it's the version that /didn't/ ship. Some parts of the code seem more sane, but some parts clearly are less 'finished' than the US ROM. It's just completely bonkers. Anyway, fascinating stuff. Great video.
I liken double-buffering to a whiteboard on a stick. The display processor is reading from one side and carefully feeding it at the right speed into the video signal, while the processor is scribbling the next frame on the other side, then you hit vblank and the NMI yells "vibe check" and kicks the right-hand edge of the board, spinning it 180 degrees.
When you overclocked it, I fully expected the code to start building the next sprites too early, wrongly predicting their next location onscreen, creating a whole new problem.
Yeah; I got the impression that the game logic (the `main()` loop as it were) was free running, and, it'll just always do this no matter what; the buffer is sampled non-atomically. Well, that didn't happen, so it must not free-run, but does have a (apparently often useless!) wait-until-NMI flag.
It's genuinely fascinating to learn how these games worked way back in the day. Kinda seems like magic, but also rushed magic, and that's where the oddities crop up.
That joke about missing the bus killed me xD If the devs had just programmed the NMI routine to skip updating sprites if the frame wasn't ready, and the main game loop to spin while waiting for the NMI to update sprites after finishing a sprite rebuild, at least the sprite glitches would have been fixed (at the cost of bad slowdown, maybe, but that's the price you pay sometimes.) I'd definitely love to see more videos on other broken aspects of this game. I can't wait to see what other treasures it holds.
I’m guessing one of the goals was to try to provide a quick-action analogue to the arcade title, so slowdown was to be avoided at all costs. Never mind that the famicom port was more of a Metroidvania than an action platformer.
This is a very informative video and provides the required amount of details for programmers, debuggers, reverse engineers and hobbyists alike. Keep it up.
While discussing slowdown in NES games, there's also Kirby's Adventure which used two OAM buffers in RAM, which could allow for triple buffering the sprites. When you do that, you can have slowdown that's not restricted to 30FPS.
I like the solution on the C64: there are only 8 sprites in total and you have your software multiplexer. Then your time line just continues through the frames.
It's funny how much the flickering bothers me as an adult revisiting the NES, but never bothered me much as a kid. I noticed it then, but didn't let it get in the way of trying to enjoy the game. Even the lag on some games didn't bother me much at all. Innocent days of youth.
I mean, you're not WRONG, per se... but Strider here...? I dropped it. Because the glitches were unbearable, in addition to the slog, and dragging gameplay. It was off putting.
What bothers me is that NES could only read 16 bytes in horizontal blanking interval from dedicated RAM in 1984 where the original Mac run at 8 MHz. A flag for 16x8 sprites would have also saved CPU time.
The Mega Man 2 dev was clearly very particular about music slowdown. He did the thing you showed where you run the sound engine even on lag frames, but there's a certain bank switch routine that's too delicate to be interrupted by that. Instead of giving up, he sets a separate flag to tell the delicate routine to run its own emergency replacement sound engine when it regains control.
Loved this video. This is the only channel where I give every video my 100% attention. I rented strider several times as a kid and wondered why it was so janky. My assembly skills are minimal (systems automation engineer by trade.) So it's a big treat to have you explain the assembly side of things. Thank you for posting this.
After watching RGMechEx about the NES scanlines seeing how adding more "time" by adding more scanlines is so intriguing. This is an example of how timing on the hardware side is extremely important and taking too long (especially with unoptimized code) can cause issues.
I was born in 1983. When I was a kid I was one of the first generation to have a computer in my classroom from kindergarten to the 12th grade. The only thing was, we were only taught the computer as a “play thing”! We never looked at it as a tool or something serious. But I’m those days most people looked at them the same way. I’m so intrigued by this coding and logic.
Interesting. I was born a few years earlier and we were using our computers for word processing and coding in BASIC. Learning how to use programs, save our work and creating different types of code. Sure, we still played Carmen Sandiego but we did a lot more than just use computers as play things.
@@grafxgear well you were just lucky that someone had the knowledge to teach that. And, I’m talking about the early years. Latter on in the grade levels we learned these things. When I say “play things I was speaking in the figurative sense. Plus learning word processing is different from learning how to program the word processor.
@@ThickCutOhio Yes. We were being taught BASIC around 4th or 5th grade. If I recall we had some sort of robot kit around 7th and 8th grade, so that came a little later. But as I mentioned we also had access to the computers to do out class work as well. Games were more of an after class or rainy day activity.
@@grafxgear and also my day add, we never looked at Nintendo as if it was a computer we just didn’t have that kind of paradigm to us a Nintendo was just a Nintendo.
Strider NES has a lot of interesting bugs in it's collision detection as well. I think another video looking into that would be a pretty interesting topic to go over.
Never would've thought that overclocking could actually *fix* graphical glitches, but then again NES Strider was just one of those games with it's very own brand of jank. Please delve into more of this oddball title, I love it.
"A delayed game is eventually good, but a rushed game is forever bad." - S. Miyamoto. I have to believe that while this behavior was partly intentional. I also have to think that it was due to a rushed dev time.
You aren't wrong, but Strider for the NES was one of my favorite games for the system; warts and all. I even managed to beat it once somebody told me the trick with the plasma arrow to beat Matic (which I was sure wouldn't work and then my jaw dropped when Matic just stopped)
Thanks. I thought it would be easier to poke at it since the game is still fun to play. I'll always come to the defense of any given programmer no matter what era their work hails from.
I'm actually in the middle of a re-run of Strider 2014 on the xbox360, so this is quite timely. I have to say, the 2014 version really looks amazing, and I always liked that star with a leg missing logo, and I had forgotten that that wasn't new for that edition. Even the NES - buggy as hheeeellllllll, still had panache and style.
@@pete-p4t collision logic is not tied to the NMI - it doesn't read from OAM like the PPU does. The collision logic problems are more likely to be just ordinary bad coding and not frame timing related but we will have to wait and see until Displaced does the analysis.
@@djmipsmoreover, the collision between the characters and the graphics (platforms, objects, item, etc) don't have the right clipping for the pixel. Mega Man 5 and Metal Storm has great examples of good clipping (attaching character to platforms for example).
What I love about computing and games is that there's ALWAYS a logical explanation for everything, even the small glitches, and as the technology continues to evolve, with new tools and knowledge, there are bugs and things that can be fixed that were considered impossible back in the day. Great job and explanations!
Remember that the Japanese version of Strider didn't get released. So, Capcom was surely spending an extended time to work on the English version and decided the result was good enough to release. It was only many years later we got a prototype of the Japanese version dumped (and even then, it's a suspicion I have it was possibly dumped from a bootleg "reproduction" cart, as I've heard the Japanese collecting scene can be even more selfish about hording unreleased games than their western counterparts. There was drama around that same time of getting the Monster Party prototype out, and that was a game even higher on the preservation scene's wishlist as they had already known for a decade that the released English US had signs in its data of removed content.)
@@djmips Just tested it out and it feels like they cleaned it up a bit. It runs pretty similarly to the overclocked US one without being overclocked, so the sprites are less glitchy and the collision detection (at least for the sword) works better. They changed the text drawing routines in the pre-mission briefings and got rid of the lightning in the background of Stage 1 as well. Overclocked, the Japanese version runs really well, at least until you stumble into one of the glitches that wasn't caused by the timing issues.
If you ever do another video on Strider, I'd love to see you talk about that weird loading(?) freeze that would occasionally happen before certain special events, like data discs dropping in. I don't know if I ever played another NES game that visibly paused to load(?) something in. Even as a kid, I recognized how utterly janky that was.
What is the fastest route to reach a point where that happens in a game? I would need to try to replicate it and make a save state right before it happens.
@@DisplacedGamers There's one instance just a bit further on in level 1, when you find the general who says Kain is above, and you level up. There's a noticeable ~1sec pause as you enter his room, then he just pops in. I remember it happening a few more times across the game, but that's easy to get to. For that matter, a couple screens before you get to him, a corridor does this weird purple flashing thing, and I've never known why. It feels deliberate enough that it must have a purpose, but it isn't obvious.
@@jasonblalock4429 I believe the flashing is likely part of a transition during which the game changes palettes and tilesets for the boss room. I've seen speedruns where gamers clip through walls, and bypassing the transition results in scrambled graphics from the level instead of the proper boss room graphics.
7:48 This would make for an interesting lesson in an Assembly Language course as this example would teach both polling and interrupts as ways CPUs can handle I/O in the same program. (I see you there Caps Lock: I know polling is waiting on a port to have data to read, but even outside of a memory-mapped system like the 6502 you can call this kind of loop that waits for memory to change as polling.)
You could append code to the NMI routine to check the state of the controller button. No idea on what else you want to wait? Games have their one and only game loop. At least on 8 bit and 16 bit systems.
Strider was such an intriguing and nostalgic game to my brother and I, especially because of its eccentricity. I honestly like the design and concept; it's just funny how it ended up looking like an unfinished and unpolished demo. I'd definitely love to learn more about its code. There are so many things about it that make me scratch my head, from the strange and janky jump animations to the music glitching out when pausing the game to the incredibly long delays for no apparent reason after a dialogue with an NPC before the game engine finally starts running again… almost an endless list.
I'm sure I mentioned this in previous comments but sometimes the best way to understand how a game functions right is to see how it functions wrong. And since we can't tweak these parameters and observe their effects (unless you're coding a game from scratch) these old buggy games serve as great examples to learn from. And this video did a great job at explaining the technicalities of it in a simplified manner. I just wish my friends were more interested in the behind the scenes of retro games like I am, or I'd be sharing these videos more often.
Thank you. I appreciate your comment, and may I just say - I wish your friends were more interested in this stuff as well! Ha. However, I understand it is a niche topic versus the majority of gamer-related YT entertainment.
Really cool. I often wondered about this when I was younger. We all experienced weird glitches on the NES, but Strider was in a class of its own. It's interesting to know why it's as ridiculous as it is.
Haven't even watched the video all the way through. As soon as the "sprites may not finish drawing" text appeared I immediately understood just how badly this is coded. Knee-jerk reaction was something along the lines of "Oh. Oh no. No no no. God, why?" Good stuff.
I noticed some flicker and what not playing this as a kid, but I didn't know HOW BAD it was! As you said, it seems OK for the most part running in real time. I still really like this game. So the TL:DR answer is sloppy programming. Someone at Capcom didn't fully know (or respect) the limitations of the NES.
Great video! I've become very interested in the differences, advantages, and disadvantages in that generation of consoles, the NES, 7800, and SMS. Could you do a video on that sometime? that would be such a fascinating video!
Can you check borderline visually broken NES games like Pitfall too? I'd love to learn about the subpar programming of a game that plays and looks this messy
+1 on super pitfall. Oh yeah the 30th anniversary mod looks amazing, much needed overhaul. Super pitfall is prob one of the earliest games to have simultaneous vertical and horizontal scrolling, and has some pretty interesting graphical bugs, possibly as a result. Sprites randomly appearing in the wrong places, disappearing etc. It also has some horrible loading times. It might be interesting to examine these issues
I always find it fascinating to learn how these old games work, specially how developers manage to work around the limitations of the hardware at the time.
Please do more Strider! It's always struck me as pretty much a playable prototype. Learning about this is a big deal for me. How bout that wall jumping? Oof!
Was this the first game to do wall jumping or is that wrong? Either way, by the time Super Metroid rolled around (perhaps pun intended?), there was at least a good visual queue of when to press the jump button. Definitely looking forward to a video on that.
@Laurell_Silentshade idk who did it first, but Strider definitely did it worst. It's effectively impossible. I only fumbled through the game thanks to the turbo function on my NES Advantage joystick, which at least made the wall jump technically occur, but only sometimes, unpredictably, intermittently. NES Batman demonstrated how to do it right.
This game was so hilariously glitchy playing as a kid. Emulators really have come a long way in visualizing timing and other things. The graphics illustrating time usage in a frame were great.
Any chance you could look into Milon's Secret Castle code and figure out what you'd need to do to start out with full life after you die to avoid the grind? I think you'd find it interesting because of the trail of values that lead to it. I was only able to get so far and I got lost, after several times of trying to piece it together.
I'm back. Took me longer to understand what you wanted since the game doesn't seem to have a concept of lives. Had to look up a faq to see that I had to beat the first boss and then enable the continue cheat. I've confirmed that the code that sets your starting life is the same regardless of continuing or starting a new game. So, to always start with full health use these game genie codes that I've created: SZSANXOZ + ULSEEZAZ
@@NesrocksGamingVideos Wow, quick response! You're every Qa person's dream pair :) Qa: I found this nasty bug! You (two seconds later): Fixed, what else you got?
In the topic of broken games, I'd love to see explanation of how the heck collision detection work in sky shark. The game is lovely and broken at the same time...
Amazing detail, would love to see an entire series on this game if there's more to cover as well as for other games. This is especially interesting to me because I've always been a big fan of the Sega and arcade versions of Strider.
I like this. As if the game logic and PPU have divergent cadences but it still results in something acceptable - like NES game euclidean rhythm. Gets a bit weird sometimes, but go with it.
I would love to see a similar video about Super Pitfalls jank. That game gets some very weird glitch graphics. It's not as popular of a game...hated even. But I bet it be a great example of what not to do.
I loved this video. Great way to learn about computers. It's nuts to think about big titles having these kinds of fundamental issues. It makes me think that is something very common no matter what project or company we work on. Have you ever thought about how airplanes fly? I'm not questioning the physics behind it, I'm questioning the code.
I noticed only 10% of what was going on in that sequence at 1:20 when played at normal speed, and for some reason it reminded me of that scene from Johnny English with the micro-expressions when you lie.
This is so excellent. I've always been kinda curious about Strider, but it wasn't until just recently when Jeremy Parish did a Metroidvania Works video featuring it that I found out how busted the damn thing is. I'm really glad that I got to see you take it apart like this!
This was such a strange game to my 13 year old brain as a kid. I remember thinking what's this game about and also remember thinking that the game was giving us clues to solve in order to complete the objectives. Why does the wall turn red when I back away from it or other strange behavior in the graphics. Simon's quest was also another one and despite the strange behavior the game displays at times, they are forever remembered for giving me some of my greatest video game playing experiences.
It's kind of wild this is a 1989 game. It feels like a leftover from Capcom's earlier, rougher quality era from just a few years prior. For context, Strider released in the US the same month that Willow released in Japan, and the gulf in quality and polish between them is striking. Commando is a similarly messy game from Capcom, with jittery graphics, messy screen transitions, and disappearing enemies. That one at least has the excuse of being from 1986.
I wonder if there wasn't some devkit or dev environment discrepancy that gave them more available CPU time before the frame interrupt that didn't manifest the issue until running on actual hardware, and by that point it was too much work to just redo everything.
No the developers just didn't know what they were doing. There was no 'super powered NES' dev kit in fact on the NES there was no widely available development hardware at all. Games were programmed in DOS and burned onto EEPROM for testing.
That certainly does happen on modern games for consoles which are often developed on robust PCs and the devs don't check on the console often enough and get behind on their optimizations and GPU problems but as @ssl3546 says back in the day they had to test directly on the hardware.
ive just stumbled across this channel and let me tell you... its going to be a pleasure to fall asleep to, i never knew i needed it, but i do. have a sub. totally no offence by the way, genuine enjoyable watch/listen.
Very interesting stuff. Coming from more modern programming my initial thought for the sprite coordinate confusion was it looked like reading the attributes of the wrong instance, since "Larry" and "Moe" are different instances of the same objects. In a way I guess it kind of was, the two entities were getting mashed together.
After seeing so much about how these early consoles synced up with the fast process of scanlines, I always wondered what would happen if this got screwed up. Never figured it would be borderline intentionally but hey, at least there is an answer
Really well done description of the crazy timing game devs are supposed to plan for. The reason for this kind of error in code is typically due to forced release on a schedule back when the time between finishing and publishing was months, and long before the ability to patch. The fix is to mix around the code so the sprite building is scheduled in a different place, and substitute some other code in that area. You can optimize in many ways, and reschedule .. but only if the development team is given adequate time and a flexible release date. Crunch is toxic.
The coding part of the development team may have only been handled by a single programmer. I wouldn't be surprised if that programmer didn't have enough experience with the Famicom yet. It was originally meant for Q4 1988 in Japan and only ended up getting a U.S. release in Summer of 1989. It is possible they shelved it and had someone else finish it for the international release in order to get some money back. Prior to that period, Capcom contracted development work for their Famicom titles out to Micronics. The 1987 to 1989 period was quite a period of growth for Capcom's understanding of the hardware. Ironic in that it was so late in the system's lifespan and that Capcom ended up making some great titles on the system.
I've always kind of wondered how Capcom's in-house team managed to churn out a game that feels technically on par with a Micronics joint. At least we get a great soundtrack by Harumi Fujita, who worked on Bionic Commando (arcade), Gargoyle's Quest, Chip 'n Dale RR 1, and a couple tracks on Mega Man 3 (Needle and Gemini themes).
It was likely made by someone who was a total beginner. Back then there was a lot of first-timers making games as the field was rapidly expanding with very few veterans. They probably got the code from another completed game but didn't know how to make it work properly and likely got little help from their busy colleagues who horded their knowledge.
I used to love this game...thank you for destroying my childhood! 😅 In all seriousness, this video was an eye-opener and really interesting, thank you for taking the time to research and create it! 😊
Loved diving into Strider (NES)! This game was requested by several people since the start of Behind the Code. The game has so many odd issues. The sprites stuck out the most for me.
A few notes -
1: The Nightmare on 6502 Street is just a fun joke that I was feeling. What I have found in code isn't THAT bad ... I think... (We haven't talked about ooh... Micronics that much yet... have we?)
2: By the way - Strider does have an infinite loop after CPU next frame work is complete. The loop compares RAM locations $4B and $4C to each other and loops so long as they are equal. The NMI routine increments $4B. So when the game returns from NMI, $4B does not equal $4C. That drops it out of the loop. $4C is then saved after the exit condition is met.
3: The NMI handling example in this video was just one basic method. NES developers may end up commenting on their own approach to their games in the comments below.
Feel free to leave other specific requests for Strider since I am "in the code" now. That said - I already have a laundry list of stuff with lots of question marks and exclamation points on it.
Take care!
Hack suggestion to mitigate this issue: add some code at the end of the NMI routine to force the interrupted code to resume **after** the sprite creation code.
This will not save the graphics of the current frame but may reduce the odds that the code will overshoot the next frame again.
Dumb question: in your example at 11:36 why is Frame A merged with Frame B? My naive guess would be that Frame A gets wiped and the incomplete Frame B gets displayed. Instead they are combined into a sort of chimera?! 🥴
Athena was a game that I found oddly compelling but also detested as a child. I don’t know if it has any interesting code to look at but I definitely felt like it was going to fly apart at any moment.
Ooh, yes! Do a Micronics title at some point, please! My nomination would be for Super Pitfall, but honestly, any of them would be a treat to hear about.
"Strider plows right through it!" So Strider is the programming equivalent of LLEEEEEEROOOYYYY JEEEENKKKKIIINNSSS!
"Happiness is only temporary, the nightmares are about to begin" was not said verbatim by my programming professor, but it was implied.
Oof!
Hot damn, it's been some 30 years and I finally get why this game flickered so weirdly compared to everything else at the time.
lol
PLEASE do more videos explaining instances where games are just fundamentally broken like this. I love it.
I actually agree and do videos about left over code and junk.
Agreed. A game that just works is kinda dull, but a game that's broken through either laziness or just flying too close to the sun is always fascinating.
Adding my vote for this! I love that stuff!
Final Fantasy II (Famicom) is a good candidate. Many of the bugs are due to the development team running out of both time and space. Many/most games have regions of 0x00 or 0xFF due to not fully using ROM space but FFIIj basically uses every byte. They couldn't even program a proper title screen.
Agree
I would love to see why the collision detection in this game was so wonky. Jumping was such a pain.
Best way to triangle jump is to use an auto pad or just frantically press the jump button.
It dawned on me what was going on about halfway through the background explanation leading up to the problem. I just started laughing. Hahaha! And the cherry on top is when you said it returned back to the frame drawing code w/o bothering to give up when the frame had already been drawn. That is truly magnificent. I feel like my life is better knowing this. Thank you so much.
Zelda: Turns its homework in late.
TMNT: Only turns in half its homework.
MM: Completes the extra credit on time, and turns its homework in late.
Strider: Turns in homework incomplete, then does the rest of it before starting on the next assignment. LOL
This makes my day. What a glorious mess.
That is a perfect explanation hehe.
Yeah, it is quite silly. Especially given that it has a cascading effect: the frame code is already too slow but they handicap it by doing work for the previous frame. This ensures that even if a single frame ends up being too slow, the game will mess up several frames in sequence because of it.
An interesting hack would be to modify the NMI code to ensure the game does not resume building the sprite data but jumps directly continues after the sprite creation code. This would not save the graphics of the current frame but it should at least reduce the odds that the next frame is garbled.
It's actually kind of miraculous that the game doesn't create a condition in which it can crash itself during these laggy moments.
"The nightmare is about to begin."
- then ad started playing
LOL. Sorry.
The fact that they alternate which actors receive priority seems like an attempt to mitigate the issue, to make it so that each of them is rendered correctly SOME of the time. So it's funny that it ends up making the corruption more chaotic as a side effect.
Priority shifting is a rather standard operation for NES games due to the 8 sprite limit per scanline. I'll get into that a bit more in a future video on flicker.
Of course when you combine that with Strider's issues... yikes.
@@DisplacedGamersI can’t believe that priority shuffling cannot indeed be done on the copy to OAM. VBI are 50 lines. CPU runs at 1.8 MHz so on 18 kHz CRT we have 100 cycles per line. CPU does almost do one memory access per cycle. Most of it is wasted on repeated instructions and IO address. Some shuffling jumps don’t change much. Modern Demo coders would probably fit a lot more into this using addressing modes, zero page, illegal instructions, and self modifying code.
NES sprites will always flicker or be very slow if you have a lot of sprites at once. Priority shifting prevents any sprite from being partially invisible all the time. Flicker is better than invisibility, but don't tell jekyll and hyde that...
This is great and explains so well why Strider looked janky as heck. I'd love to see a deep dive into the collision detection. Especially with regards to wall jumping which always felt completely broken.
Collision detection and wall jumping are on the list.
@@DisplacedGamers I'll bring the popcorn
The way I sorted out the wall jumping, press the A button as fast as you can.
Oh god, wall jumping...I always assumed I just sucked at the game. Could it be...I didn't suck?
@@mattmorrisson9607 Very, VERY likely!
fascinating, esoecially you usually expect this type of thing from no name/random devs...not capcom. If Capcom farmed it out to another dev, sure but this is in house. The way larry blends in and out into moe is nuts, lol.
Even in-house development can lean on the B-team, or even C-team coders. There are only so many A-team coders to go around, and NES Strider clearly wasn't enough of a priority to get Capcom's best. Coders were "Zac" and "Mamicyan♡Otona" on Strider. Mamicyan is Masamitsu Kobayashi, an experienced Famicom programmer, who I suspect was involved later to try cleaning up Zac's buggy code as best as he could.
back then everyone was random devs
@@ostiariusalpha Exactly. I actually suspect that "Zac" may have been granted a basic framework from Mr. Kobayashi and he really didn't know what he was doing with no help from anyone as what happened all too often back in those days.
The other probable reason - they had very tight deadline for release and no time to spare for fixing even the obvious bugs. Knowing how prolific Capcom was during those times, I wouldn't be surprised if it was the case. Money needed to be made. Projects were being made like hot cakes. It was not worth it to postpone the release.
NES Strider was basically generating an entirely new game from an arcade game that bore little to no resemblance; some of the assumptions of that arcade game's architecture may have leaked into the design of this game. Furthermore, it's very possible that this was meant to use a memory mapper chip that wasn't available by the time the "drop dead" deadline was looming, and so they had to get it working SOMEHOW. And, even more bizarrely, this didn't just have to pass Capcom's internal QA, but Nintendo of Japan's and Nintendo of America's, too. (Presumably also Nintendo of Europe's, but considering the horrible mess this was at 60Hz, I think it would just flat-out refuse to run at 50Hz.) There are a lot of things that could have gone wrong behind the scenes, and a lot of people who should have pumped the brakes on it to make sure that it "just worked" as opposed to "just barely worked".
As a coda: The NOA "Seal of Quality" was mostly a transparent form of censorship and software flood control until the early 90s (think 1992 or so) where as long as the game was mostly stable, it would pass QA and get "the Seal". There are a LOT of games prior to 1991 or 92 that are FAR WORSE than NES Strider in terms of stability, playability, and suchlike: Kung-Fu Heroes comes immediately to mind. It's also worth noting that the NES's infamous cartridge slot could have contributed to the instability, and so NOA's QA might have given some glitchiness a pass just as a result of "couldn't reproduce". Around the early 90's is when you saw NOA get serious about QA as a function of software quality as opposed to "we don't want another Crash of 1983 situation", and Sega arguably beat them to the punch (the Sonic 3D Blast "secret level select" incident, for example, was the result of Sega taking crashes and glitches more seriously for longer than previously).
i love the tone you achieve in these videos. there's just enough formality and precision in your writing that when you slip in the odd bit of humor it ends up really punchy for how simple it is. i'll be thinking about "happiness is only temporary. the nightmares are about to begin." for the rest of the day
Thank you!
I had no idea anyone managed to mess up the frame draws so badly on the NES. Like, the first note of programming for the thing is basically "TIMING IS EVERYTHING" and we have Capcom, one of the heavy hitters (although maybe not yet in 1989), making this fundamental level of error.
I think Capcom had some growing pains on the Famicom when moving from contracting Micronics to developing their stuff in-house.
What's odd about this is that Mega Man 1 & 2 were released prior to Strider and yet they're far more stable than it.
@@powerkirbybomber6503 I think the Mega Man games had Capcom's A-list talent working on them. Based on another comment, Strider seems to have been done by someone without nearly as much experience with the NES and then had to be fixed by a more senior programmer to get a "sellable" game in a tight deadline (all about that $$$!)
@@powerkirbybomber6503I believe it was different teams working on that. In some previous videos on this channel they looked at Mega Man's code and noted that even within the same game you could see some of the developers had different priorities.
I wonder if the fact this game was only ever released in North America also indicates the quality of work behind it and that it wasn't the A team working on it. Possibly not even Capcom directly.
MegaMan prioritized audio during slow down because they knew they shouldn't mess with those banger tunes.
This was agonising to watch as someone learning homebrew development... Keep it up.
Same.
Also same
Holy sprite flicker, Batman! God I never knew Strider NES's sprite graphics code was such a dumpsterfire. Really enlightening how you went through it though, explaining why all the bizarre sprite weirdness happens.
Loved the "Nightmare on 6502 Street" joke. These technical videos (both yours and RGME's) are always a treat and I await eagerly the next Strider video. Keep up the good work!
Thanks!
I swear you perfectly occupy this niche of TH-cam. I have extremely rudimentary knowledge of programming and I can not only follow but enjoy the presentation.
Thank you!
Commando is another one in this mold. Looking forward to more analysis on games zortching as frequently as this one.
Both Strider and Commando were early Capcom releases, and so suffered from the fact that the programmers didn't know how to get the most of the NES hardware yet.
"But happiness is only temporary. The nightmare is about to begin." is about the rawest thing I've heard on this channel, it came so far out of left field I legit had to pause for a second to think about what I'd just heard.
I think what made it better is your _casual monotone_ way of explaining things.
Stryder: LET'S FUCKING GOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO-
You dove so much deeper than I did, I just spent a couple of weeks tracing the collision detection subroutine. Hope you'll look at that JP alpha in a future video - crazy how that ROM is also broken, but in different ways, and it's the version that /didn't/ ship. Some parts of the code seem more sane, but some parts clearly are less 'finished' than the US ROM. It's just completely bonkers.
Anyway, fascinating stuff. Great video.
I liken double-buffering to a whiteboard on a stick. The display processor is reading from one side and carefully feeding it at the right speed into the video signal, while the processor is scribbling the next frame on the other side, then you hit vblank and the NMI yells "vibe check" and kicks the right-hand edge of the board, spinning it 180 degrees.
That's an excellent analogy.
Also someone switches the light off a few ms before the flip and turns it back on after it. 😉
When you overclocked it, I fully expected the code to start building the next sprites too early, wrongly predicting their next location onscreen, creating a whole new problem.
Yeah; I got the impression that the game logic (the `main()` loop as it were) was free running, and, it'll just always do this no matter what; the buffer is sampled non-atomically. Well, that didn't happen, so it must not free-run, but does have a (apparently often useless!) wait-until-NMI flag.
It's genuinely fascinating to learn how these games worked way back in the day. Kinda seems like magic, but also rushed magic, and that's where the oddities crop up.
That joke about missing the bus killed me xD
If the devs had just programmed the NMI routine to skip updating sprites if the frame wasn't ready, and the main game loop to spin while waiting for the NMI to update sprites after finishing a sprite rebuild, at least the sprite glitches would have been fixed (at the cost of bad slowdown, maybe, but that's the price you pay sometimes.)
I'd definitely love to see more videos on other broken aspects of this game. I can't wait to see what other treasures it holds.
I’m guessing one of the goals was to try to provide a quick-action analogue to the arcade title, so slowdown was to be avoided at all costs. Never mind that the famicom port was more of a Metroidvania than an action platformer.
This is a very informative video and provides the required amount of details for programmers, debuggers, reverse engineers and hobbyists alike. Keep it up.
While discussing slowdown in NES games, there's also Kirby's Adventure which used two OAM buffers in RAM, which could allow for triple buffering the sprites. When you do that, you can have slowdown that's not restricted to 30FPS.
I like the solution on the C64: there are only 8 sprites in total and you have your software multiplexer. Then your time line just continues through the frames.
It's funny how much the flickering bothers me as an adult revisiting the NES, but never bothered me much as a kid. I noticed it then, but didn't let it get in the way of trying to enjoy the game. Even the lag on some games didn't bother me much at all. Innocent days of youth.
I mean, you're not WRONG, per se... but Strider here...? I dropped it. Because the glitches were unbearable, in addition to the slog, and dragging gameplay. It was off putting.
What bothers me is that NES could only read 16 bytes in horizontal blanking interval from dedicated RAM in 1984 where the original Mac run at 8 MHz. A flag for 16x8 sprites would have also saved CPU time.
The Mega Man 2 dev was clearly very particular about music slowdown. He did the thing you showed where you run the sound engine even on lag frames, but there's a certain bank switch routine that's too delicate to be interrupted by that. Instead of giving up, he sets a separate flag to tell the delicate routine to run its own emergency replacement sound engine when it regains control.
Loved this video. This is the only channel where I give every video my 100% attention. I rented strider several times as a kid and wondered why it was so janky. My assembly skills are minimal (systems automation engineer by trade.) So it's a big treat to have you explain the assembly side of things.
Thank you for posting this.
After watching RGMechEx about the NES scanlines seeing how adding more "time" by adding more scanlines is so intriguing.
This is an example of how timing on the hardware side is extremely important and taking too long (especially with unoptimized code) can cause issues.
I was born in 1983. When I was a kid I was one of the first generation to have a computer in my classroom from kindergarten to the 12th grade. The only thing was, we were only taught the computer as a “play thing”! We never looked at it as a tool or something serious. But I’m those days most people looked at them the same way. I’m so intrigued by this coding and logic.
Interesting. I was born a few years earlier and we were using our computers for word processing and coding in BASIC. Learning how to use programs, save our work and creating different types of code. Sure, we still played Carmen Sandiego but we did a lot more than just use computers as play things.
@@grafxgear well you were just lucky that someone had the knowledge to teach that. And, I’m talking about the early years. Latter on in the grade levels we learned these things. When I say “play things I was speaking in the figurative sense. Plus learning word processing is different from learning how to program the word processor.
@@ThickCutOhio Yes. We were being taught BASIC around 4th or 5th grade. If I recall we had some sort of robot kit around 7th and 8th grade, so that came a little later. But as I mentioned we also had access to the computers to do out class work as well. Games were more of an after class or rainy day activity.
@@grafxgear and also my day add, we never looked at Nintendo as if it was a computer we just didn’t have that kind of paradigm to us a Nintendo was just a Nintendo.
Strider NES has a lot of interesting bugs in it's collision detection as well. I think another video looking into that would be a pretty interesting topic to go over.
Doing work on collision detection right now. Movement and collision detection seem to be "overdone" so far, imo. I'll keep working.
Never would've thought that overclocking could actually *fix* graphical glitches, but then again NES Strider was just one of those games with it's very own brand of jank. Please delve into more of this oddball title, I love it.
This is one of your best videos. I'm looking forward to more on Strider. The Larry and Moe playback at 3% was incredibly revealing and entertaining.
More Strider on the way.
strider was one of my favorite games as a kid and even then i could tell it was held together with tape and bubblegum.
"A delayed game is eventually good, but a rushed game is forever bad." - S. Miyamoto.
I have to believe that while this behavior was partly intentional. I also have to think that it was due to a rushed dev time.
You aren't wrong, but Strider for the NES was one of my favorite games for the system; warts and all. I even managed to beat it once somebody told me the trick with the plasma arrow to beat Matic (which I was sure wouldn't work and then my jaw dropped when Matic just stopped)
This game brings up good memories from my old NES days. I enjoy your technical videos and am happy to see another post! Thank you!
Love how aggressive this video got toward Strider. Excellent work as always!
Thanks. I thought it would be easier to poke at it since the game is still fun to play. I'll always come to the defense of any given programmer no matter what era their work hails from.
I'm actually in the middle of a re-run of Strider 2014 on the xbox360, so this is quite timely. I have to say, the 2014 version really looks amazing, and I always liked that star with a leg missing logo, and I had forgotten that that wasn't new for that edition. Even the NES - buggy as hheeeellllllll, still had panache and style.
This was interesting! I hope you can also explain why the jumping is so glitchy too lol.
i bet collision logic did not finish before the nmi kicked in and positions/state is taken to the next frame with old data of the last frame.
@@pete-p4t collision logic is not tied to the NMI - it doesn't read from OAM like the PPU does. The collision logic problems are more likely to be just ordinary bad coding and not frame timing related but we will have to wait and see until Displaced does the analysis.
@@djmipsmoreover, the collision between the characters and the graphics (platforms, objects, item, etc) don't have the right clipping for the pixel. Mega Man 5 and Metal Storm has great examples of good clipping (attaching character to platforms for example).
What I love about computing and games is that there's ALWAYS a logical explanation for everything, even the small glitches, and as the technology continues to evolve, with new tools and knowledge, there are bugs and things that can be fixed that were considered impossible back in the day. Great job and explanations!
Remember that the Japanese version of Strider didn't get released. So, Capcom was surely spending an extended time to work on the English version and decided the result was good enough to release. It was only many years later we got a prototype of the Japanese version dumped (and even then, it's a suspicion I have it was possibly dumped from a bootleg "reproduction" cart, as I've heard the Japanese collecting scene can be even more selfish about hording unreleased games than their western counterparts. There was drama around that same time of getting the Monster Party prototype out, and that was a game even higher on the preservation scene's wishlist as they had already known for a decade that the released English US had signs in its data of removed content.)
Does the 'prototype' glitch as well?
@@djmips Just tested it out and it feels like they cleaned it up a bit. It runs pretty similarly to the overclocked US one without being overclocked, so the sprites are less glitchy and the collision detection (at least for the sword) works better. They changed the text drawing routines in the pre-mission briefings and got rid of the lightning in the background of Stage 1 as well. Overclocked, the Japanese version runs really well, at least until you stumble into one of the glitches that wasn't caused by the timing issues.
If you ever do another video on Strider, I'd love to see you talk about that weird loading(?) freeze that would occasionally happen before certain special events, like data discs dropping in. I don't know if I ever played another NES game that visibly paused to load(?) something in. Even as a kid, I recognized how utterly janky that was.
What is the fastest route to reach a point where that happens in a game? I would need to try to replicate it and make a save state right before it happens.
@@DisplacedGamers There's one instance just a bit further on in level 1, when you find the general who says Kain is above, and you level up. There's a noticeable ~1sec pause as you enter his room, then he just pops in.
I remember it happening a few more times across the game, but that's easy to get to.
For that matter, a couple screens before you get to him, a corridor does this weird purple flashing thing, and I've never known why. It feels deliberate enough that it must have a purpose, but it isn't obvious.
@@jasonblalock4429 I believe the flashing is likely part of a transition during which the game changes palettes and tilesets for the boss room. I've seen speedruns where gamers clip through walls, and bypassing the transition results in scrambled graphics from the level instead of the proper boss room graphics.
@@TravisTev Yeah, that makes sense. Also, now I need to look up speedruns for this. As broken as it is, they must be wild. 🙂
7:48 This would make for an interesting lesson in an Assembly Language course as this example would teach both polling and interrupts as ways CPUs can handle I/O in the same program. (I see you there Caps Lock: I know polling is waiting on a port to have data to read, but even outside of a memory-mapped system like the 6502 you can call this kind of loop that waits for memory to change as polling.)
You could append code to the NMI routine to check the state of the controller button. No idea on what else you want to wait? Games have their one and only game loop. At least on 8 bit and 16 bit systems.
Strider was such an intriguing and nostalgic game to my brother and I, especially because of its eccentricity. I honestly like the design and concept; it's just funny how it ended up looking like an unfinished and unpolished demo. I'd definitely love to learn more about its code. There are so many things about it that make me scratch my head, from the strange and janky jump animations to the music glitching out when pausing the game to the incredibly long delays for no apparent reason after a dialogue with an NPC before the game engine finally starts running again… almost an endless list.
I'm loving this foray into "The game is just broken, but they shipped it anyway" deep dive stuff you've done so far.
I'm sure I mentioned this in previous comments but sometimes the best way to understand how a game functions right is to see how it functions wrong. And since we can't tweak these parameters and observe their effects (unless you're coding a game from scratch) these old buggy games serve as great examples to learn from.
And this video did a great job at explaining the technicalities of it in a simplified manner.
I just wish my friends were more interested in the behind the scenes of retro games like I am, or I'd be sharing these videos more often.
Thank you. I appreciate your comment, and may I just say - I wish your friends were more interested in this stuff as well! Ha. However, I understand it is a niche topic versus the majority of gamer-related YT entertainment.
Love these deep dives, especially for a sorry-mess-of-a-game like Strider for NES!
I was recommended your video here. I always chalked these flickerings as glitches as a kid, not understanding that the delivery was delayed. 😮
Really cool. I often wondered about this when I was younger. We all experienced weird glitches on the NES, but Strider was in a class of its own. It's interesting to know why it's as ridiculous as it is.
I’d watch a whole series on Strider. This game has some of the weirdest coding from an A list studio I’ve ever seen.
This is so fascinating and for sure that I want more!
always wondered why this game just... looked like that. great video!
Haven't even watched the video all the way through. As soon as the "sprites may not finish drawing" text appeared I immediately understood just how badly this is coded. Knee-jerk reaction was something along the lines of "Oh. Oh no. No no no. God, why?"
Good stuff.
Double Dragon also had some wonky sprites, I always wondered what was going on, I suspect it's the same thing as Strider.
Good video. I hope you do this with Commando. That's even worse. I wonder if it has *anything* in common with Strider.
I noticed some flicker and what not playing this as a kid, but I didn't know HOW BAD it was! As you said, it seems OK for the most part running in real time. I still really like this game.
So the TL:DR answer is sloppy programming. Someone at Capcom didn't fully know (or respect) the limitations of the NES.
I remember Donkey Kong Land having a lot of stuff like that where garbage graphics appear, and it was very noticeable
Great video!
I've become very interested in the differences, advantages, and disadvantages in that generation of consoles, the NES, 7800, and SMS. Could you do a video on that sometime? that would be such a fascinating video!
Can you check borderline visually broken NES games like Pitfall too? I'd love to learn about the subpar programming of a game that plays and looks this messy
I believe a developer actually took Super Pitfall and basically rebuilt it with upgraded graphics and more a few years ago.
+1 on super pitfall. Oh yeah the 30th anniversary mod looks amazing, much needed overhaul. Super pitfall is prob one of the earliest games to have simultaneous vertical and horizontal scrolling, and has some pretty interesting graphical bugs, possibly as a result. Sprites randomly appearing in the wrong places, disappearing etc. It also has some horrible loading times. It might be interesting to examine these issues
I always find it fascinating to learn how these old games work, specially how developers manage to work around the limitations of the hardware at the time.
Man, this is so good technical explanation of the issue. You explain this stuff so understandably :)
I live for videos like this, I love being able to understand WHY shit is jank
Always a pleasure to see new video from you! Informative, fun, relaxing, meditative in a way 😌
Thanks!
Please do more Strider! It's always struck me as pretty much a playable prototype. Learning about this is a big deal for me. How bout that wall jumping? Oof!
Wall jumping is on the list.
@@DisplacedGamers so glad! :D
Was this the first game to do wall jumping or is that wrong?
Either way, by the time Super Metroid rolled around (perhaps pun intended?), there was at least a good visual queue of when to press the jump button. Definitely looking forward to a video on that.
@Laurell_Silentshade idk who did it first, but Strider definitely did it worst. It's effectively impossible. I only fumbled through the game thanks to the turbo function on my NES Advantage joystick, which at least made the wall jump technically occur, but only sometimes, unpredictably, intermittently. NES Batman demonstrated how to do it right.
This video was suggested to me by TH-cam. 40 seconds in, I subscribed. Looking forward to seeing your other content after this vid!
Moe and Larry??? I love it!
This game was so hilariously glitchy playing as a kid. Emulators really have come a long way in visualizing timing and other things. The graphics illustrating time usage in a frame were great.
Any chance you could look into Milon's Secret Castle code and figure out what you'd need to do to start out with full life after you die to avoid the grind? I think you'd find it interesting because of the trail of values that lead to it. I was only able to get so far and I got lost, after several times of trying to piece it together.
That's an easy rom hacking task. Let me try. Will be back soon.
I'm back. Took me longer to understand what you wanted since the game doesn't seem to have a concept of lives. Had to look up a faq to see that I had to beat the first boss and then enable the continue cheat. I've confirmed that the code that sets your starting life is the same regardless of continuing or starting a new game. So, to always start with full health use these game genie codes that I've created: SZSANXOZ + ULSEEZAZ
"Easy rom hacking task. brb."
Love it, NesrocksGamingVideos!
@@NesrocksGamingVideos Wow, quick response! You're every Qa person's dream pair :)
Qa: I found this nasty bug!
You (two seconds later): Fixed, what else you got?
@@NesrocksGamingVideos Awesome brother. I'm going to give it a try and get back to you about it!
This was an absolute treat to watch. It’s amazing how many programming shortcuts that were taken when these games were developed.
Well it was like 10x harder to program those games than today, with less resources so its kind of understandable
In the topic of broken games, I'd love to see explanation of how the heck collision detection work in sky shark. The game is lovely and broken at the same time...
Amazing detail, would love to see an entire series on this game if there's more to cover as well as for other games. This is especially interesting to me because I've always been a big fan of the Sega and arcade versions of Strider.
Always found this game to be super wank. Didn't even feel like Capcom quality. Guess I'll now find out why!
I like this. As if the game logic and PPU have divergent cadences but it still results in something acceptable - like NES game euclidean rhythm.
Gets a bit weird sometimes, but go with it.
I would love to see a similar video about Super Pitfalls jank. That game gets some very weird glitch graphics. It's not as popular of a game...hated even. But I bet it be a great example of what not to do.
"happiness is only temporary, the nightmares are about to begin"
Bro went hard with that quote 💀
I loved this video. Great way to learn about computers.
It's nuts to think about big titles having these kinds of fundamental issues. It makes me think that is something very common no matter what project or company we work on.
Have you ever thought about how airplanes fly? I'm not questioning the physics behind it, I'm questioning the code.
I noticed only 10% of what was going on in that sequence at 1:20 when played at normal speed, and for some reason it reminded me of that scene from Johnny English with the micro-expressions when you lie.
What a beautiful nightmare. I've missed your videos. This is brilliant!
This is so excellent. I've always been kinda curious about Strider, but it wasn't until just recently when Jeremy Parish did a Metroidvania Works video featuring it that I found out how busted the damn thing is. I'm really glad that I got to see you take it apart like this!
Thank you!
This was such a strange game to my 13 year old brain as a kid.
I remember thinking what's this game about and also remember thinking that the game was giving us clues to solve in order to complete the objectives.
Why does the wall turn red when I back away from it or other strange behavior in the graphics.
Simon's quest was also another one and despite the strange behavior the game displays at times, they are forever remembered for giving me some of my greatest video game playing experiences.
I must admit I kinda love the brute force janky method they used for this. 😅
They didn't know (or perhaps the hardware didn't allow) at the time anything more sophisticated than this method...
It's kind of wild this is a 1989 game. It feels like a leftover from Capcom's earlier, rougher quality era from just a few years prior. For context, Strider released in the US the same month that Willow released in Japan, and the gulf in quality and polish between them is striking.
Commando is a similarly messy game from Capcom, with jittery graphics, messy screen transitions, and disappearing enemies. That one at least has the excuse of being from 1986.
New videos from Displaced Gamers and Retro Game Mechanics Explained on the same day? There is a Santa Clause!
These were some great guesses. I think you even got a couple things right. Kidding!
This is beautiful. Strider always felt like it was turn-based.
Yeah I've definitely had days where I feel like Strider's graphics routine
I wonder if there wasn't some devkit or dev environment discrepancy that gave them more available CPU time before the frame interrupt that didn't manifest the issue until running on actual hardware, and by that point it was too much work to just redo everything.
No the developers just didn't know what they were doing. There was no 'super powered NES' dev kit in fact on the NES there was no widely available development hardware at all. Games were programmed in DOS and burned onto EEPROM for testing.
That certainly does happen on modern games for consoles which are often developed on robust PCs and the devs don't check on the console often enough and get behind on their optimizations and GPU problems but as @ssl3546 says back in the day they had to test directly on the hardware.
ive just stumbled across this channel and let me tell you... its going to be a pleasure to fall asleep to, i never knew i needed it, but i do. have a sub. totally no offence by the way, genuine enjoyable watch/listen.
Very interesting stuff. Coming from more modern programming my initial thought for the sprite coordinate confusion was it looked like reading the attributes of the wrong instance, since "Larry" and "Moe" are different instances of the same objects. In a way I guess it kind of was, the two entities were getting mashed together.
one of your best videos yet, you are very right that this is an entertaining idea, i love it!
The more I learn about them, the more I'm convinced that Capcom was the NES's Bethesda...
After seeing so much about how these early consoles synced up with the fast process of scanlines, I always wondered what would happen if this got screwed up. Never figured it would be borderline intentionally but hey, at least there is an answer
Really well done description of the crazy timing game devs are supposed to plan for. The reason for this kind of error in code is typically due to forced release on a schedule back when the time between finishing and publishing was months, and long before the ability to patch. The fix is to mix around the code so the sprite building is scheduled in a different place, and substitute some other code in that area. You can optimize in many ways, and reschedule .. but only if the development team is given adequate time and a flexible release date. Crunch is toxic.
I contend this was made by a junior dev - so not just a schedule issue.
The coding part of the development team may have only been handled by a single programmer. I wouldn't be surprised if that programmer didn't have enough experience with the Famicom yet. It was originally meant for Q4 1988 in Japan and only ended up getting a U.S. release in Summer of 1989. It is possible they shelved it and had someone else finish it for the international release in order to get some money back.
Prior to that period, Capcom contracted development work for their Famicom titles out to Micronics. The 1987 to 1989 period was quite a period of growth for Capcom's understanding of the hardware. Ironic in that it was so late in the system's lifespan and that Capcom ended up making some great titles on the system.
The part at 1:00 sounds like a description of a 3 Stooges creepypasta
I've always kind of wondered how Capcom's in-house team managed to churn out a game that feels technically on par with a Micronics joint. At least we get a great soundtrack by Harumi Fujita, who worked on Bionic Commando (arcade), Gargoyle's Quest, Chip 'n Dale RR 1, and a couple tracks on Mega Man 3 (Needle and Gemini themes).
It was likely made by someone who was a total beginner. Back then there was a lot of first-timers making games as the field was rapidly expanding with very few veterans. They probably got the code from another completed game but didn't know how to make it work properly and likely got little help from their busy colleagues who horded their knowledge.
Incredible work as always. Keep it up.
I used to love this game...thank you for destroying my childhood! 😅 In all seriousness, this video was an eye-opener and really interesting, thank you for taking the time to research and create it! 😊
10:07 - Okay that wraparound got a genuine laugh out loud from me
These videos are _compellingly_ entertaining