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!

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.

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

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

I can't believe this vid is two years old already? 'A Nightmare on 6502 Street' is one of my favourite lines to come from this channel.

MegaMan prioritized audio during slow down because they knew they shouldn't mess with those banger tunes.

"Happiness is only temporary, the nightmares are about to begin" was not said verbatim by my programming professor, but it was implied.

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.

13:08 [S] Strider: Overclock.

"Let's gooooooooooo!" 🤣

0:52 Larry moment

10:01 is the best XD

"Are these frames being displayed live?"
"No, Homer. Very few games have their frames displayed live. It's a terrible strain on the console's sprite-building process."

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.

10:07 - Okay that wraparound got a genuine laugh out loud from me

I live for videos like this, I love being able to understand WHY shit is jank

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.

You've heard of programmer art, now get ready for art programming.

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 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.