I cannot imagine the board meeting where they decided “giving the player one pixel of white in the eyes” is worth reducing the number of drawable objects by more than 10%
It looks baffling, but hey, we probably paid more attention to their white eyes than we would to an extra sprite being drawn without flickering everything
It's a tiny detail but I think that subconsciously it makes a big difference to the players and makes the characters much more animated and alive looking. Even if you don't think it makes a difference, it probably affects you subconsciously. I mean literally the entire game (and every videogame) is literally just you interpreting visuals, so it makes sense to want to make them look as good as you can.
I find it absolutely hilarious that toad is the only one who already uses white in his color palette and yet is the only one lacking whites in his eyes.
I main Peach myself but I too have noticed that she seems to "blink" rapidly when going through doors. I never considered it was the same effect as the flickering sprites so in my head canon, I explained it as the characters were just blinking fast to adjust their eyes to the drastic changes in lighting.
Another well-known NES game that uses multiple sprites for the player character is Mega Man. In those games, the whole face is a separate sprite, so sometimes Mega's face flickers due to hitting the sprite limit.
The MSX, which came out a few years before the NES, also used this trick often of sprite stacking. I believe the first Metal Gear used this. MSX also had color math, which the NES sort of had but it was more on a global level than at the sprite level. For the NES It was often used for pausing the game or a underwater level to tint the screen. On the MSX the color math could be used with sprite stacking to get new colors.
Another fun fact about Mega Man's face graphics: the skin color, white eyes, and black pupil colors are reused for the health pickups, enemy damage flashes, and even some projectiles (at least in mm2). So you could say the iconic lemons are actually flesh balls! Plain-colored weapons, like Quick Boomerang and Metal Blade, use this trick to allow more colorful outfits for Mega Man. More colorful weapons, like Air Shooter and Leaf Shield, require Mega Man to match his projectiles. As an interesting aside, consider the flashing health and energy pickups, which use Mega Man's palettes. You'd think those are using palette cycling, but they actually have to use two separate graphics to avoid making Mega Man into a strobe monster.
This also made the graphics more versatile, since it meant that any facial expression could be slotted in with any pose. A sprite even more versatile was Dizzy in The Fantastic Adventures of Dizzy, where not only did he have many face pieces to choose from, but his gloves and shoes were separate objects that could float just anywhere they were needed for any pose. Being separate objects, they had a separate palette from the body, allowing the body to contain _two_ shades of white with black outlines instead of having to share with the red gloves and shoes.
@@warmCabin Re Mega Man changing colors with the weapons: That's neat! I didn't know that was due to a hardware limitation. Capcom came up with a rather plausible way to spin a limitation into canon, at least for those games. (I haven't played anything in the Mega Man series past MM4, sadly.)
I've always seen that eye flicker effect for years as a child. And when I started playing on emulators it got more pronounced due to the upscaling on an LCD. Always wondered what was going on behind that! Thanks for demystifying yet another interesting aspect of these older games! 😀
What i did noticed is that on the nes via composite video, mario has black eyes and a black mustage while on a emulator via vga ,mario’s mustage and eyes are just blue, i don’t why it is, but this can be no coicidence i believe nintendo took advantage of the ntsc color artifacts.
@@johneygd It depends on the colour palette that the emulator uses. FirebrandX has made a very accurate NTSC colour palette and most NES emulators let you change the colour palette being used. It's not 100% accurate because you'd need something like a 12bit display panel and most LCD screens are 6 or 8 bits so the palette is optimized to look the best on a common LCD display (HDR displays may be 10bits and professional displays may be 12 bits).
@@johneygd NTSC color artifacts and the properties of the display itself both come into play. Remember that most CRTs aren't exactly great at reproducing the NTSC color spectrum exactly either - not to mention the TV's own controls are likely playing a part as well. I recall the SMB2 sprites having non-black (dark-blue) borders on my old TV, but I always figured that was because the TV's "black" wasn't really black. It was only when I played it on an emulator that I saw it actually being dark blue, and that it was actually different from SMB1.
I will always have mad respect to the programmers of that age. Being able to work around the limitations of the hardware to create truly magnificent games. Being able to so tightly manage the limited resources.
There's still a large amount of current work done in this space, specifically in iot and devices meant for near space flight. Extreme limitations on weight and size are still getting devs to coerce complicated functionality from scarce resources.
I never thought about how this flickering behavior was something completely intended and designed by the game programmers, it makes perfect sense! Thank you very much for this videos. As always, informative and easy to follow despite being really technical.
IMO, coming up with creative solutions in the face of severe limitations is a lost art. Programmers back in the day knew what kinds of limitations they were up against and found really interesting ways to get around them, and many developers today just don't have to worry about it anymore.
All the revisions that went into Doki Doki becoming the western SMB2 is a fascinating discussion. Among other things it was American audiences introduction to Nintendo's powerful MMC3 enhancement chip, which would go on to become the workhorse of second generation NES cartridges (Most future NES games would put this chip to use). In the case of SMB2 it added all the animated backgrounds that were static in Doki Doki Panic, a trick the developers lifted from SMB3's development.
A couple things I thought might be worth pointing out: You can see the eye-flashing thing most clearly with the door because it doesn't move and doesn't collide. But in theory, there are other cases where it could happen as well. Specifically, if any object were to go behind the player and occupy the same space as the eye-whites, you'd see them flicker then as well, since the whites would be competing for priority with the other objects. (I think the game specifically disallows this - everything collides with each other except the door.) You can probably reproduce the eye flicker by making the player stand to the right of two or more of the waterfall logs with their eyes in the same horizontal line as the logs. Since the eye-whites would occasionally be at a lower priority than the logs, they'd hit the 8-objects-per-scanline limit and end up not being drawn. Again, this may or may not be possible or feasible to recreate. The game designers may have built the levels in such a way that you can't make that happen - e.g. no stationary ground low enough for the eyes to overlap vertically with the logs. I'd have to play around with an emulator to see for sure. Also, I would say that the Shy Guy overlap-flicker you mentioned at 6:30 is not a matter of "fairness" or a deliberate design decision to show the two characters equally, but rather a simple consequence of the sprite-shuffling design. It has the effect of making both Shy Guys appear roughly equally, but I don't think the devs specifically intended for that to happen. Finally, do you know what, if anything, actually used the "Important Item" slot? (#4, to the right of the player character slot.) I don't think I saw it ever populated in any of the examples here, but there are a lot of other scenes in the game. :)
On standing in line with the logs: It occurs to me that the player could stand anywhere on the screen so long as the eyes are in the same line as the logs. It doesn't have to be to the right of them - the priority order is essentially random.
I've been working on my first disassembly (Bomber King). I was literally staring at code in the debugger that I had no idea what it did. This video was absolutely serendipitous.
Excellent video! I always thought that the flickering was a glitch or unintentional when enemy characters overlapped each other. Interesting to learn that the sprites were cycling so that they each had a chance to show on screen due to programming!
i always noticed the flickering effect when sprites were overlapping but never understood why that might be happening. this is so interesting, especially knowing that it was a conscious choice made to ensure that no particular sprite in that group had priority over another.
Honestly, this sprite system in SMB2 seems to introduce an artificial limitation layer on top of what the system allows. What I mean is, it does not seem dynamic at all, and can't reserve the exact number of objects required to show everything in one frame, so a lot of the "sprite bandwidth" goes unused.
Well, to some extent that problem existed in Doki Doki Panic as well. That game had some scenes in it where there were just as many sprites on the screen at once, and they had to flicker just the same, though I couldn't tell you if the code cycled the objects in the same way. The eye-transparency trick here does reduce the sprite slots by one, which exacerbates the problem, but the problem was there to begin with, and exists in plenty of other games as well.
I thought it would be an eye-shaped sprite over top of the player sprite, but having a white square show through from underneath probably saves a few bytes, since it can be reused for the other characters. Very interesting!
It's very funny to me that Toad, who has white as part of his palette already, is the one who doesn't have whites to his eyes. Like it's not worth drawing them unless it takes extra effort to do it.
These guys were legends back in the day. Any of the old school dudes had to do what they had to do and created so many classic games for millions of people to enjoy due to hardware limitations. Not that game design is any easier by anymeans but these boys set the foundation
"One doesn't really deserve to be always on top of the other, so to be fair and allow both enemies to show through, the OAM slots that each sprite gets is shuffled every frame." We did it boys, we established true equality
The more I see to the "magic" that goes in behind what we consider "simple" games still utterly blows my mind with how much thought, attention, and creativity was needed to pull them off, let alone perform small innovations such as the whites of these sprite's eyes. Fascinating!
Dude, you are a legend. I have learned sooo much about all this game stuff from watching your videos, particularly the stuff around the SNES, and I'm learning new things every day as I rewatch each video and understand just a little bit more each time. Major kudos to you.
One comment in this video kinda sticks out to me. The "transparency" from overlapping enemies is _definitely_ not a desired effect, and in fact a pretty notorious quirk in NES programming (but could apply to any similar hardware). It would absolutely look a lot better if one shyguy just passed in front of the other, but it's really difficult to create an effecient sprite cycling routine while also maintaining a depth priority maintained by game logic. Even giving the player character priority like SMB2 does has a negative impact on how striking the flickering appears on the remaining objects. I think this is especially evident in a belt scroller such as Mighty Final Fight which choses to forego sprite priority in favor of more effecient sprite cycling, despite the fact that sprite priority would make a lot of sense in a game like that.
Damn, I feel like I never really noticed the eye flickering when going through doors. I probably just tuned NES sprite flicker out as a kid. But now, thanks to this video, I'm going to fixate on it every time I play SMB2.
Fun fact: Pac-Nan does the same trick for its third cutscene when Blinky is revealed to be a monster by rendering Blinky himself and his cloak as seperate sprites, this also allows the assembled together sprite to look like it was more than 16 pixels wide.
And just like that, the universe answers my question from over 30 years ago... THANK YOU!!! ...Also, may I recommend a very fun, but *very* glitchy, NES game to dissect? DODGE BALL. It used to regularly flicker and slow down to the point where I was sure my nintendo would catch on fire 🏐🏐🔥🚒👍
When you asked how this was the day before posting, I thought this might be the answer, but I thought I was wrong because the sprites on the spriter's resource don't reflect this, and I figured the impact on sprite flickering would be more severe.
Well, huh, not only did I learn why the eyes seem to blink or sparkle, I also learned why sprite flickering happens all in one video. This is why I love this channel.
Simple, Take mario for example, There are 2 sections, Background tiles, and sprite tiles, mario actually has four colors: red, blue, gold yellow, and transparent. The white part in the eye is actually transparent, the background tile goes white when the eyes go on the background tile. Big brain >:3 Edit: oh wait the white part is also a sprite
I've always wondered how SMB2 did this! This level of clarity is something I never thought I'd learn, yet here you are, solving it in a way that even idiots like me can understand it!
Oh this explains how the battle sprites in Mother look. because most of them have more then 3 colors. You can even see extra details being added as the enemy loads in like the chain and collar on the stray dog.
When I was younger, I thought that the flashing eyes when the player is in front of a door is just some special animation added to the player, but I didn't know it was actually a glitch, lol.
This got me curious! In the Super Mario All-Stars version of Super Mario Bros. 2, even though the characters' whites don't need to be separate anymore, is the object still present?
Is there a reason why the "extra" slots didn't get used for the new eye objects? Do those not exist for the rare occasions of needing more objects? Wouldn't it make sense to use up one of those instead of the normal slots & avoid reducing the number of things that can be on screen during average gameplay?
The priority issue is primarily for the limited sprite visibility per row. Secondarily it is for ensuring everything can be drawn beyond the onscreen limit. The draw ordering is only important for the main player character and other important sprites, but not because there is no preferred ordering for enemies. It would be better if their ordering was constant.
I was wondering why the eyes flicker when opening a door! Nice explanation for one of my favorite games! Also interesting is that the prototype didn't have the whites in the eyes, so they must've been decided to be added in later!
It was then Capcom and their Mega Man franchise through which they implemented the "more than three colors" rule. Mega Man has in this regard even five visible colors: blue, teal, yellow, black and white. Plus Mega Man has a signature eye blink animation.
7:55 don't know how much time it took to create that but thank you I can't wait until Minecraft becomes a "Retro Game" because man I would love this kind of stuff for games like that
@@jwhite5008 I would like to see this channel analyze in their style. Where every frame has a slot of data showing information, in a similar fassion to what you see at 7:55. If you know of videos or channels that make videos like this for Minecrafts code do let me know!
You might be very interested in the classic DOOM games for DOS. John Carmack put genius effort to make something like that run on 16-bit DOS computers. doomwiki.org/wiki/Entryway
@@FakeDomi I disagree that it wouldn't be as interesting, but it would be a lot harder to show. Modern games tend to have much more complex logic. Especially a 3D game like Minecraft using tons of procedural generation.
The Mega Man games on NES do this too. Mega Man's armor is two shades of blue and black, but his face, as well as bullets, explosions, health power ups, and the faces of other bosses all share a universal black-tan-white color palette. It's a clever way to reuse commonly appearing colors to maximize detail in objects and backgrounds.
Some NES games take it one step further and use sprites that either don't move (or move in sync with scrolling) for additional background color. Normally a 32x32 section of tiles MUST share the same palette (or is it 16x16?) but since sprites can use their own distinct palette they can go anywhere and break this limit easily
I'd love to see someone do a video on the more hardcore detailed games like Vice Project Doom, Ninja Gaiden 1-3, Shatterhand and The Guardian Legend. Just the more high end artwork, not to diminish the artistry here. Its movingly beautiful.
On AtariAge, somebody made a Mario walking animation with 4 different types of sprites stacked on top of each other. So the "meta sprite" has 12 colors, and looks like something on the Master System
Pretty sure Mario is drawn behind the background when he enters the pipe. SMB3, on the other hand, does make use of a masking sprite which goes above Mario but also goes behind the background, thus creating the illusion that Mario goes behind the pipe only but not decorative tiles.
I've played SMB2 millions of times as a kid and never once noticed the eyes flicker. Mind you I only ever played with the Princess for her glide ability and Luigi for one level where his fliaty jump gave an advantage and it looks like they had the least amount of white for their eyes.
Is it weird that I was just thinking this a week ago? Edit: even weirder is that I thought this was the solution, but thought it was inefficient. Which it is.
Makes me wonder if there isn't a way to just tweak the sprite priority code in order to move the eyes object just below the player's sprite itself, but not actually shuffle around with everything else lower in priority, essentially making it remain static, and wouldn't flicker when the door or anything that would go below the player, making the entire thing look a bit nicer. I would argue that the life meter could have a similar treatment too, so that would make held objects, player, life meter, and eyes, in that order, static object layer, and would never flicker, while all the remaining sprites underneath would keep using that same flicker shuffle effect.
That would definitely be possible. I think this was a very quick fix just to get it working. I also think that having sprites flicker wasn't that big of an issue around the time the game was made, since you would see it all the time due to sprite restrictions in general.
Yeah, but special-casing for Toad would require a lot more complex code and a lot of extra shuffling around of the OAM, and handling that case dynamically could easily have slowed down the game execution code to the point that it couldn't maintain a steady framerate. (That kind of thing is NOT easy at the machine code level.)
I cannot imagine the board meeting where they decided “giving the player one pixel of white in the eyes” is worth reducing the number of drawable objects by more than 10%
It looks baffling, but hey, we probably paid more attention to their white eyes than we would to an extra sprite being drawn without flickering everything
It's a tiny detail but I think that subconsciously it makes a big difference to the players and makes the characters much more animated and alive looking. Even if you don't think it makes a difference, it probably affects you subconsciously. I mean literally the entire game (and every videogame) is literally just you interpreting visuals, so it makes sense to want to make them look as good as you can.
@@melody3741 This is the reason we remember Mario and not Pitfall Harry.
It helps that the game was already fully designed, so they knew how much room was left for extra objects.
Only 90's game devs will understand 😤
I find it absolutely hilarious that toad is the only one who already uses white in his color palette and yet is the only one lacking whites in his eyes.
Toad with eye-whites seems kinda disturbing the more I think of it.. I’m just so used to them being solid black dots!
I've noticed the Mario with Red Flickering Eyes multiple times when going through a door. Thanks for the explanation!
I main Peach myself but I too have noticed that she seems to "blink" rapidly when going through doors.
I never considered it was the same effect as the flickering sprites so in my head canon, I explained it as the characters were just blinking fast to adjust their eyes to the drastic changes in lighting.
@@Dargonhuman huh
I've always mained Toad since the early 90s, so I have to admit I've never noticed this glitch.
Yea
@@theREALsilviautismRead it again, it makes perfect sense??...
Somehow I never noticed the eyes freaking out when on a door but now I won't be able to un-see it, thanks
@@alainchristian I'm pretty good at not seeing things. It's one of my many talents
r/TIHI?
@@Bry10022 this ain't reddit, fella
@@xander0479 I know, It probably qualifies for the Thanks, I Hate It subreddit…
Have you ever noticed that in SMB3 and Kirby's Adventure, the tiles on the right side of the screen have the wrong colors while scrolling?
Don’t you just HATE when your eyes turn door-colored? I sure do!
yeah stalkers can relate :)
Ikr
ikr
Ikr
Another well-known NES game that uses multiple sprites for the player character is Mega Man. In those games, the whole face is a separate sprite, so sometimes Mega's face flickers due to hitting the sprite limit.
The MSX, which came out a few years before the NES, also used this trick often of sprite stacking. I believe the first Metal Gear used this. MSX also had color math, which the NES sort of had but it was more on a global level than at the sprite level. For the NES It was often used for pausing the game or a underwater level to tint the screen. On the MSX the color math could be used with sprite stacking to get new colors.
Another fun fact about Mega Man's face graphics: the skin color, white eyes, and black pupil colors are reused for the health pickups, enemy damage flashes, and even some projectiles (at least in mm2). So you could say the iconic lemons are actually flesh balls!
Plain-colored weapons, like Quick Boomerang and Metal Blade, use this trick to allow more colorful outfits for Mega Man. More colorful weapons, like Air Shooter and Leaf Shield, require Mega Man to match his projectiles.
As an interesting aside, consider the flashing health and energy pickups, which use Mega Man's palettes. You'd think those are using palette cycling, but they actually have to use two separate graphics to avoid making Mega Man into a strobe monster.
This also made the graphics more versatile, since it meant that any facial expression could be slotted in with any pose.
A sprite even more versatile was Dizzy in The Fantastic Adventures of Dizzy, where not only did he have many face pieces to choose from, but his gloves and shoes were separate objects that could float just anywhere they were needed for any pose. Being separate objects, they had a separate palette from the body, allowing the body to contain _two_ shades of white with black outlines instead of having to share with the red gloves and shoes.
@@warmCabin Re Mega Man changing colors with the weapons: That's neat! I didn't know that was due to a hardware limitation. Capcom came up with a rather plausible way to spin a limitation into canon, at least for those games. (I haven't played anything in the Mega Man series past MM4, sadly.)
Was going to say the same thing. They did a great job with the level of detail for Mega Man
It should be noticed that the SMB2 prototype lacks the extra eye sprites, putting the characters' eyes more like the style shown in SMB3.
I've always seen that eye flicker effect for years as a child. And when I started playing on emulators it got more pronounced due to the upscaling on an LCD. Always wondered what was going on behind that! Thanks for demystifying yet another interesting aspect of these older games! 😀
What i did noticed is that on the nes via composite video, mario has black eyes and a black mustage while on a emulator via vga ,mario’s mustage and eyes are just blue, i don’t why it is, but this can be no coicidence i believe nintendo took advantage of the ntsc color artifacts.
@@johneygd It depends on the colour palette that the emulator uses. FirebrandX has made a very accurate NTSC colour palette and most NES emulators let you change the colour palette being used. It's not 100% accurate because you'd need something like a 12bit display panel and most LCD screens are 6 or 8 bits so the palette is optimized to look the best on a common LCD display (HDR displays may be 10bits and professional displays may be 12 bits).
@@johneygd NTSC color artifacts and the properties of the display itself both come into play. Remember that most CRTs aren't exactly great at reproducing the NTSC color spectrum exactly either - not to mention the TV's own controls are likely playing a part as well. I recall the SMB2 sprites having non-black (dark-blue) borders on my old TV, but I always figured that was because the TV's "black" wasn't really black. It was only when I played it on an emulator that I saw it actually being dark blue, and that it was actually different from SMB1.
I will always have mad respect to the programmers of that age. Being able to work around the limitations of the hardware to create truly magnificent games. Being able to so tightly manage the limited resources.
There's still a large amount of current work done in this space, specifically in iot and devices meant for near space flight. Extreme limitations on weight and size are still getting devs to coerce complicated functionality from scarce resources.
Before knowing about this, I though Mario and co. were blinking while going through a door!
That was my head canon as well - I figured they were going from very bright light to very dim interiors (or vice versa) and were adjusting their eyes.
Marios eye go like
😐😑😐😑😐😑😐😑😐😑😐😑😐😑😐😑😐😑😐😑😐😑😐😑😐😑😐😑 XD
They were….
1-800-CONTACTS?
THEY CAN'T HAVE MY BRAND!
I have special eyes...
Tali: Look. Look with your special eyes.
MY BRAND
I like this comment…
They specialize in special eyes
I never thought about how this flickering behavior was something completely intended and designed by the game programmers, it makes perfect sense!
Thank you very much for this videos. As always, informative and easy to follow despite being really technical.
It doesn't to me, could you explain? Why is this more desirable than simply having the enemy that's in front appear in front?
It still blows my mind with the limits of the NES, of what programmers and creators accomplished
IMO, coming up with creative solutions in the face of severe limitations is a lost art. Programmers back in the day knew what kinds of limitations they were up against and found really interesting ways to get around them, and many developers today just don't have to worry about it anymore.
I've always wondered why Mario's eyes glitch out when he's in a red door and now i know it, great videos btw!
"Your new game just came out."
"On the NES? It can't render my sprite. I HAVE SPECIAL EYES."
"Look. Look with your special eyes."
"MY SPRITE!"
What is this a reference to?
@@LouieFromPikmin 1-800-CONTACTS if I remember correctly.
@@literallyn01imp0rtant MY BRAND!
special eyes? on my cartridge?
it's more likely than you'd think.
I always thought the flickering eyes was the characters raising their eyebrows in anticipation of going through the door.
All the revisions that went into Doki Doki becoming the western SMB2 is a fascinating discussion. Among other things it was American audiences introduction to Nintendo's powerful MMC3 enhancement chip, which would go on to become the workhorse of second generation NES cartridges (Most future NES games would put this chip to use). In the case of SMB2 it added all the animated backgrounds that were static in Doki Doki Panic, a trick the developers lifted from SMB3's development.
Everyone’s eyes may look
g o r g e o u s
A couple things I thought might be worth pointing out:
You can see the eye-flashing thing most clearly with the door because it doesn't move and doesn't collide. But in theory, there are other cases where it could happen as well. Specifically, if any object were to go behind the player and occupy the same space as the eye-whites, you'd see them flicker then as well, since the whites would be competing for priority with the other objects. (I think the game specifically disallows this - everything collides with each other except the door.)
You can probably reproduce the eye flicker by making the player stand to the right of two or more of the waterfall logs with their eyes in the same horizontal line as the logs. Since the eye-whites would occasionally be at a lower priority than the logs, they'd hit the 8-objects-per-scanline limit and end up not being drawn. Again, this may or may not be possible or feasible to recreate. The game designers may have built the levels in such a way that you can't make that happen - e.g. no stationary ground low enough for the eyes to overlap vertically with the logs. I'd have to play around with an emulator to see for sure.
Also, I would say that the Shy Guy overlap-flicker you mentioned at 6:30 is not a matter of "fairness" or a deliberate design decision to show the two characters equally, but rather a simple consequence of the sprite-shuffling design. It has the effect of making both Shy Guys appear roughly equally, but I don't think the devs specifically intended for that to happen.
Finally, do you know what, if anything, actually used the "Important Item" slot? (#4, to the right of the player character slot.) I don't think I saw it ever populated in any of the examples here, but there are a lot of other scenes in the game. :)
On standing in line with the logs: It occurs to me that the player could stand anywhere on the screen so long as the eyes are in the same line as the logs. It doesn't have to be to the right of them - the priority order is essentially random.
I just found this channel on the patrons list at the end of the latest Technology Conections video. 😂 🤣
That was a great find!!! 💪 👍
I've never actually noticed the eyes flickering until this day, and now I cannot unsee it. Great job video! :D
Just play with Toad. Problem solved.
I've been working on my first disassembly (Bomber King). I was literally staring at code in the debugger that I had no idea what it did. This video was absolutely serendipitous.
Excellent video! I always thought that the flickering was a glitch or unintentional when enemy characters overlapped each other. Interesting to learn that the sprites were cycling so that they each had a chance to show on screen due to programming!
i always noticed the flickering effect when sprites were overlapping but never understood why that might be happening. this is so interesting, especially knowing that it was a conscious choice made to ensure that no particular sprite in that group had priority over another.
Love these videos, so many things that are a lot more involved than they appear.
You don't have to leave a comment about Mega Man's face. There are already a lot of comments about it.
Hey, did you know that Mega Man's face is drawn... oh, forget it. ;)
How about Ninten's hat?
Weirdly enough, I found this channel through NileReds patron list.
I'm surprised you didn't talk about Megaman, seeing how he has five (well, six) colours
The frame by frame loaded sprite visualization is really cool, this is good stuff!
Honestly, this sprite system in SMB2 seems to introduce an artificial limitation layer on top of what the system allows. What I mean is, it does not seem dynamic at all, and can't reserve the exact number of objects required to show everything in one frame, so a lot of the "sprite bandwidth" goes unused.
Well, to some extent that problem existed in Doki Doki Panic as well. That game had some scenes in it where there were just as many sprites on the screen at once, and they had to flicker just the same, though I couldn't tell you if the code cycled the objects in the same way. The eye-transparency trick here does reduce the sprite slots by one, which exacerbates the problem, but the problem was there to begin with, and exists in plenty of other games as well.
So the blinking eye effect was basically a happy accident. That's so cool!
I thought it would be an eye-shaped sprite over top of the player sprite, but having a white square show through from underneath probably saves a few bytes, since it can be reused for the other characters. Very interesting!
I'm always amazed by your diagrams and explanations, you really do clarify these abstract programming and design ideas
SMB2/USA sprites are beautiful
Wow, genius! I love how old console games used these "tricks" to get more done that first thought possible!
It's very funny to me that Toad, who has white as part of his palette already, is the one who doesn't have whites to his eyes. Like it's not worth drawing them unless it takes extra effort to do it.
Watching these videos makes me feel a bit like Neo in The Matrix.
These guys were legends back in the day. Any of the old school dudes had to do what they had to do and created so many classic games for millions of people to enjoy due to hardware limitations.
Not that game design is any easier by anymeans but these boys set the foundation
"One doesn't really deserve to be always on top of the other, so to be fair and allow both enemies to show through, the OAM slots that each sprite gets is shuffled every frame."
We did it boys, we established true equality
The more I see to the "magic" that goes in behind what we consider "simple" games still utterly blows my mind with how much thought, attention, and creativity was needed to pull them off, let alone perform small innovations such as the whites of these sprite's eyes. Fascinating!
They have special eeeeeeyes!
aaaaaa it's called sclera!!!!!!!!!!
On a more serious note, this video was very informative, as your videos usually are. Thank you for making this!
I guessed this one before you revealed it but the extra information about how OAM works was very interesting, thanks!
omg this is so fun seeing all of your fans!!! i'm so excited and happy for you.
Dude, you are a legend. I have learned sooo much about all this game stuff from watching your videos, particularly the stuff around the SNES, and I'm learning new things every day as I rewatch each video and understand just a little bit more each time. Major kudos to you.
One comment in this video kinda sticks out to me.
The "transparency" from overlapping enemies is _definitely_ not a desired effect, and in fact a pretty notorious quirk in NES programming (but could apply to any similar hardware).
It would absolutely look a lot better if one shyguy just passed in front of the other, but it's really difficult to create an effecient sprite cycling routine while also maintaining a depth priority maintained by game logic. Even giving the player character priority like SMB2 does has a negative impact on how striking the flickering appears on the remaining objects.
I think this is especially evident in a belt scroller such as Mighty Final Fight which choses to forego sprite priority in favor of more effecient sprite cycling, despite the fact that sprite priority would make a lot of sense in a game like that.
I would like to know the inner workings of the Game Boy Zelda games.
The technique is called Sprite stacking and megaman used it as well
Damn, I feel like I never really noticed the eye flickering when going through doors. I probably just tuned NES sprite flicker out as a kid. But now, thanks to this video, I'm going to fixate on it every time I play SMB2.
Fun fact: Pac-Nan does the same trick for its third cutscene when Blinky is revealed to be a monster by rendering Blinky himself and his cloak as seperate sprites, this also allows the assembled together sprite to look like it was more than 16 pixels wide.
Mario's *EYE* conic late NES-era sprite design
Hah!
Is this supposed to be a joke?
@@kemalswimmingsuitswimmingh415 Yes because the video is about the eyes
@@AWigglePig oh yes I get it now haha XD
And just like that, the universe answers my question from over 30 years ago... THANK YOU!!!
...Also, may I recommend a very fun, but *very* glitchy, NES game to dissect? DODGE BALL. It used to regularly flicker and slow down to the point where I was sure my nintendo would catch on fire 🏐🏐🔥🚒👍
Huh, thanks for making more sense of how old games used to work. I wondered how they managed to up the look from Mario 1 to Mario 2/USA
When you asked how this was the day before posting, I thought this might be the answer, but I thought I was wrong because the sprites on the spriter's resource don't reflect this, and I figured the impact on sprite flickering would be more severe.
Well, huh, not only did I learn why the eyes seem to blink or sparkle, I also learned why sprite flickering happens all in one video.
This is why I love this channel.
this vid was spectacular, great job.
Simple,
Take mario for example,
There are 2 sections, Background tiles, and sprite tiles, mario actually has four colors: red, blue, gold yellow, and transparent. The white part in the eye is actually transparent, the background tile goes white when the eyes go on the background tile.
Big brain >:3
Edit: oh wait the white part is also a sprite
I always wondered about that eye flicker at the doors and whether it was some weird illusion or something.
I've always wondered how SMB2 did this! This level of clarity is something I never thought I'd learn, yet here you are, solving it in a way that even idiots like me can understand it!
well, if you were wondering about this then you're not that much of an idiot, don't look so down on yaself
Really cool stuff, man. Always look forward to your videos. Thanks for all the work you put into them!
Oh this explains how the battle sprites in Mother look. because most of them have more then 3 colors. You can even see extra details being added as the enemy loads in like the chain and collar on the stray dog.
I actually genuinely love your content.
That little comment about Toad was quite funny to me.
So does that mean that Mario is EATING TOAD HEADS the whole time!?!?
@@MattRose30000 Given all the weird things that Mario gets to do when eating them, it's as good an explanation as any. :)
When I was younger, I thought that the flashing eyes when the player is in front of a door is just some special animation added to the player, but I didn't know it was actually a glitch, lol.
This got me curious! In the Super Mario All-Stars version of Super Mario Bros. 2, even though the characters' whites don't need to be separate anymore, is the object still present?
Just saw here on a debugger and nop! Each character is composed of 2 16x16 sprites and nothing more.
I can't wait for part 11 of your main series on hardware registers. Then I wonder what will be your next 'main' series.
Is there a reason why the "extra" slots didn't get used for the new eye objects? Do those not exist for the rare occasions of needing more objects? Wouldn't it make sense to use up one of those instead of the normal slots & avoid reducing the number of things that can be on screen during average gameplay?
The priority issue is primarily for the limited sprite visibility per row. Secondarily it is for ensuring everything can be drawn beyond the onscreen limit. The draw ordering is only important for the main player character and other important sprites, but not because there is no preferred ordering for enemies. It would be better if their ordering was constant.
I always noticed the flickering behind the eyes. At the time, I wasn't so sure why that happened, though. This video helps clear it up, thanks! :D
If I were good at game programming. It's stuff like this that would be fun to code.
I was wondering why the eyes flicker when opening a door! Nice explanation for one of my favorite games!
Also interesting is that the prototype didn't have the whites in the eyes, so they must've been decided to be added in later!
I'll never unsee the shuffling. Thanks
It was then Capcom and their Mega Man franchise through which they implemented the "more than three colors" rule. Mega Man has in this regard even five visible colors: blue, teal, yellow, black and white. Plus Mega Man has a signature eye blink animation.
This is the first time I was able to understand what is going on fully, I’m proud of myself lmao.
7:55 don't know how much time it took to create that but thank you
I can't wait until Minecraft becomes a "Retro Game" because man I would love this kind of stuff for games like that
Minecraft (java edition) already has loads of mods, skins, maps, was decompiled and analyzed countless times, what else would you like?
@@jwhite5008 I would like to see this channel analyze in their style. Where every frame has a slot of data showing information, in a similar fassion to what you see at 7:55. If you know of videos or channels that make videos like this for Minecrafts code do let me know!
there's a lot less trickery going on behind the scenes so it wouldn't be even nearly as interesting as games on old, severely limited systems
You might be very interested in the classic DOOM games for DOS.
John Carmack put genius effort to make something like that run on 16-bit DOS computers.
doomwiki.org/wiki/Entryway
@@FakeDomi I disagree that it wouldn't be as interesting, but it would be a lot harder to show. Modern games tend to have much more complex logic. Especially a 3D game like Minecraft using tons of procedural generation.
That's interesting, i never know they could draw sprites over / under other sprite layers. Cool video!
The Mega Man games on NES do this too. Mega Man's armor is two shades of blue and black, but his face, as well as bullets, explosions, health power ups, and the faces of other bosses all share a universal black-tan-white color palette. It's a clever way to reuse commonly appearing colors to maximize detail in objects and backgrounds.
Some NES games take it one step further and use sprites that either don't move (or move in sync with scrolling) for additional background color. Normally a 32x32 section of tiles MUST share the same palette (or is it 16x16?) but since sprites can use their own distinct palette they can go anywhere and break this limit easily
I'd love to see someone do a video on the more hardcore detailed games like Vice Project Doom, Ninja Gaiden 1-3, Shatterhand and The Guardian Legend. Just the more high end artwork, not to diminish the artistry here. Its movingly beautiful.
On AtariAge, somebody made a Mario walking animation with 4 different types of sprites stacked on top of each other.
So the "meta sprite" has 12 colors, and looks like something on the Master System
Appropriate video for Halloween. Eyes are haunted.
NICE!!! Ever since the 80's I wondered why the character eyes flickered!
I didn't know the NES could draw sprites on top of other sprites :0
I'm guessing they used that trick in the exit/enter pipe animation in smb1
Sprites are different from tiles, pipes are most likely tiles
Pretty sure Mario is drawn behind the background when he enters the pipe. SMB3, on the other hand, does make use of a masking sprite which goes above Mario but also goes behind the background, thus creating the illusion that Mario goes behind the pipe only but not decorative tiles.
@@MarioFanGamer659 I thought the exact same smb3 technique was used in smb1
Ive been searching for this answer my whole life
7:00 in addition to partial transparency, I've also heard flicker used for color mixing (e.x. Metroid).
i love all the hoops they had to jump through to accomplish what they did on the limited hardware they had.
I can't view peach as not slightly fed up
This is such great content! Thank you :)
finally, I wasn't the only one that saw the eyes freaking out!!!
I've played SMB2 millions of times as a kid and never once noticed the eyes flicker.
Mind you I only ever played with the Princess for her glide ability and Luigi for one level where his fliaty jump gave an advantage and it looks like they had the least amount of white for their eyes.
The shuffling is also used to blow past the 8 sprites per scanline limit.
Is it weird that I was just thinking this a week ago?
Edit: even weirder is that I thought this was the solution, but thought it was inefficient. Which it is.
What’s even weirder is that your pfp looks kinda familiar, can’t seem to put my finger on it though...
@@art1637 why does everyone have this pfp i do not understand please help
Your voice is uh. like, really nice to listen to? it so soft :o
ngl kinda cute actually
All that for a small detail, I can see why SM3 ditched the white eyes
Makes me wonder if there isn't a way to just tweak the sprite priority code in order to move the eyes object just below the player's sprite itself, but not actually shuffle around with everything else lower in priority, essentially making it remain static, and wouldn't flicker when the door or anything that would go below the player, making the entire thing look a bit nicer.
I would argue that the life meter could have a similar treatment too, so that would make held objects, player, life meter, and eyes, in that order, static object layer, and would never flicker, while all the remaining sprites underneath would keep using that same flicker shuffle effect.
That would definitely be possible. I think this was a very quick fix just to get it working. I also think that having sprites flicker wasn't that big of an issue around the time the game was made, since you would see it all the time due to sprite restrictions in general.
I always thought they were blinking their eyes and that it was on purpose.
The irony is Toad’s sprite wouldn’t even need an extra sprite but he doesn’t have whites in his eyes
Yeah, but special-casing for Toad would require a lot more complex code and a lot of extra shuffling around of the OAM, and handling that case dynamically could easily have slowed down the game execution code to the point that it couldn't maintain a steady framerate. (That kind of thing is NOT easy at the machine code level.)
Even if he did, he already has white.
I guess I will never see this game the same way again ;-)
never noticed the eyes flickering, thats neat!
Little did I know decades after playing I would find out why their eyes sparkled!
"Look.. look with your special eyes. MY BRAND!"