The Garbage Sprites in Strider (NES) - Behind the Code

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!

PLEASE do more videos explaining instances where games are just fundamentally broken like this. I love it.

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.

I would love to see why the collision detection in this game was so wonky. Jumping was such a pain.

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.

"The nightmare is about to begin." - then ad started playing

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.

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.

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.

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.

This was agonising to watch as someone learning homebrew development... Keep it up.

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.

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.

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.

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 swear you perfectly occupy this niche of YouTube. I have extremely rudimentary knowledge of programming and I can not only follow but enjoy the presentation.

Commando is another one in this mold. Looking forward to more analysis on games zortching as frequently as this one.

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!