Some of you have pointed out errors I've made in the video and I'd like to address them, the two I'm seeing the most are: 1. Mario isn't Sprite 0 2. Sprite 0 wasn't created by the software team, it's part of the hardware functionality Mario being Sprite 0 was a joke I included that hasn't landed for a lot of people, for those of you with a technical knowledge of the NES it rightly didn't make sense for Mario to be Sprite 0 as there as good reasons for him to not be Sprite 0. For those of you that may be encountering these concepts for the first time it created confusion and made the video harder to follow. In the future I won't be making jokes with concepts core to the topic of the video, thanks for the feedback on that. In this instance I could have explained why the coin sprite was used and why Mario isn't a good spite 0, that added context may have helped clear up some of the confusion. As to Sprite 0 being created by the software team, this was an error on my part, the team that made SMB didn't create a function in the code for sprite 0, it's a part of the hardware. Thanks to everyone that pointed this out, I should have clued in when reading the NESDEV wiki that it wasn't a software thing. Thanks for bringing these issues to my attention, it's important for info to be correct and I'll work harder to ensure that it is in future uploads.
This whole video is a convoluted way of saying that "the sprite zero is used to tell when a v-blank ends; if it's blank it never ends". Let me explain what actually happens in a clear way: Sprite zero is used to determine when a special state called a v-blank ends. A vertical blank, or v-blank, is the time between the last line of the current frame and the first line of the next frame, which is never defined clearly in the video for some reason. You can think of it as the time between frames. The v-blank is important because it is the time the PPU is NOT accessing the sprites and is instead waiting for the next frame(it's idle), meaning that this is the time when you can safely update data in shared memory or registers without causing a data race(writing to memory that's currently being read). Super Mario Bros. uses the little coin there to determine when a v-blank ends. There's nothing particularly ground-breaking or genius about this, they just decided it made sense since it's always there. The coin, which is sprite zero, is used by the NES to calculate a pixel-hit against the background(it's not used for collision detection like this video seems to suggest). If opaque pixels overlap, then a sprite zero hit is considered to have happened. This means that amongst other things, games can use it to tell when a v-blank period ends, as the hit state is cleared before the electron gun starts drawing the next frame, thus allowing programmers to know when it's unsafe to access memory shared with the PPU. This means that in Super Mario Bros. you can lock the game in an infinite loop by finding a way to corrupt the UI coin(sprite zero) such that it becomes a fully transparent sprite, which consequently would never trigger the v-blank end state. Players found out that a specific set of steps causes buffer overflow that overrides sprite zero with arbitrary memory garbage that makes it transparent. This makes the game believe it's unsafe to update the graphics and it ends up locked in an infinite loop waiting for the now impossible v-blank end state. In other words: sprite zero is used to tell when the time between frames ends, and if it's transparent, it never ends. By following a specific set of steps, players can cause a buffer overflow that overrides sprite zero with garbage memory that makes it transparent, thus locking the game in an infinite loop waiting for the v-blank end state.
The sprite zero hit doesn't indicate the end of VBlank. It indicates the end of the status bar, because there is a tile with visible pixels set under the bottom of the coin(you can actually see the triggering "dirt" left behind on the screen once the coin is cleared and the crash happens). Once the sprite zero collision is registered, the CPU can reset the scroll registers on the PPU, because it now knows all the data that needs to not scroll has all been drawn to the screen. It allows the CPU to know how far through the image the PPU has made it, so mid-frame "raster effects" are possible. And since it just sets a bit in a status register rather than raising an interrupt, the CPU can miss the hit if other things are happening. That's why sometimes the status bar scrolls for a couple of frames, and why MMC3 added a scanline-counter that raised an interrupt.
@@CptJistuce Yes it does. The hit flag is cleared at the end of every v-blank. This means that games can track the state of the flag to know when the v-blank ends, but for that to work it must guarantee that a hit will occur next frame, otherwise it gets stuck in an infinite loop. Now watch the video again. As he mentions at 9:30, the developers assumed a sprite zero hit would always occur, when it doesn't the game hangs. Now you know why. When only the HUD logic is compromised what we get is a completely different effect where the HUD glitches out and doesn't appear static. But yes, sprite zero can also be used for other purposes, which is exactly why I said "*amongst other things*". Drawing in relation to the camera was one such "other thing", but that was pretty irrelevant to the explanation.
Sorry to be "that guy" but a couple things are a bit iffy imo: * Sprite 0 is clearly intended for the purpose of doing something like a scrollbar, it's not a genius move on Miyamoto's part. * The devs of SMB didn't "create a function called a sprite 0 hit", the sprite 0 hit is something built-in to the hardware that the developers made use of.
It's engagement bait. He says it wrong, you comment on how it annoys you, he gets more comments from the hundreds of other people who also complain about the same thing
Gotta say the engagement bait here is really subtle, he gets so much else in this video wrong that it seems entirely possible he wouldn't even know how to pronounce miyamoto's name
@@maxrichards5925 Yeah. Matter of fact, if you tilt too hard, it'll dislodge the cartridge from its socket and you'll be able to take it out. I suggested lightly tapping it. It works better if your console is old and you haven't done any pin replacement operations on it. And you can also just bump the console for the same effect.
Please get someone who understands how CRTS and the NES work to help you with the technical details as I did not understand most of what you said. Just a minor criticism since you make great videos, just a way for you to improve :D
CRT's render lines one at a time and 2 pauses happen during rendering. The horizontal blank (hblank) is a very short pause that happens between the end of a scanline and the beginning of the next scanline. The PPU prepares how to draw sprites for the next line during that time and it only has time to prepare 8. Most games use a function to invert the order of sprites on screen so they flicker instead of becoming invisible when there are more than 8. The vertical blank (vblank) is a long pause between 2 frames where the PPU has nothing to do. This is the only time each frame that the CPU has time to upload data to VRAM. The NES is designed to have a non-maskable interrupt (NMI) at the beginning of vblank to interrupt the CPU of whatever it's doing and the software can start uploading tile and sprite data to the PPU. When outside both hblank and vblank, the PPU focuses on rendering background as the CRT beam goes from left to right. The PPU has enough time to render 2bpp (bit per pixel, in this case 4 colors) per 8 pixels tile plus a tile attribute to select a palette per 16 pixels. While drawing 8 pixels of one tile, the PPU will prepare the next tile by loading: a tile from the nametable, a tile attribute from the name table and load 2x 8-bit of a sliver of 8 pixels. The CPU can change background scroll values mid frame to achieve 2 or more different scrolling values in one frame. Sprite 0 is used for timing (as explained in the video). Changing the X coordinate of the background is easy but changing Y value requires abusing a hardware glitch and I don't want to get too technical about it. The VRAM buffers that he's talking about are part of SMB's software.
*DO NOT WATCH!!! YOU WILL LEARN WRONG!* This video contains a lot of *subtle inaccuracies* and *half-truths* that will confuse you and make it more difficult to learn about NES hardware and coding. 1:18 is showing a "minus world" where the game read an invalid level header and loaded an overworld map layout as an underwater type level, which is why it has strange graphics and colors. For real examples of graphical corruption from mistimed PPU writes, see Displaced Gamers' videos on Strider and Mega Man 3. 1:23 has misleading phrasing. _Everything_ is drawn by the PPU on _every_ frame using data from a separate memory space than CPU memory. This separate memory is updated by the CPU sending commands to the PPU (or to the cart hardware, for more advanced features). Sprite data (OAM) is usually kept in CPU memory and copied to PPU memory before each frame using special hardware functionality (DMA), so the CPU copy can be updated for the next frame while the current frame is being drawn, but writing anything to the PPU should only be done between frames (or scanlines). 1:37 VRAM_Buffer2 is described accurately, but VRAM_Buffer1 does not handle sprites at all, it's a general scratch space used during other non-sprite graphical changes, such as updating the status bar, palette cycling (coins and ? blocks), and erasing background tiles when blocks are hit. It should also be noted that these are just arbitrary sections of CPU RAM allocated by the SMB1 code, they are not hardware chips as the video implies. 1:55 what the hell is that grid, I'm done, see every other comment for more mistakes Please at least watch NesHacker, Displaced Gamers, and Retro Game Mechanics Explained and learn how to use Mesen's graphics viewers before trying to make videos like this.
5:39 CRTs don't send information in the form of light, but instead in the form of an electron beam, which is shot by a device quite literally called an "electron gun" these electrons then excite the phosphorescent coating on the back of the tube, which causes it to glow
the technical explanations and diagrams in this video are full of inaccuracies and blatant errors. any research was clearly done very hastily, with no attempt to actually understand what's going on. issues range from misnaming several concepts (and mispronouncing the name of one of the most prolific video game designers of all time), to completely misrepresenting what a sprite-zero hit actually does and why it works. i honestly think you should delete this video and either rewrite it with help from somebody who knows what they're talking about, or just scrap it altogether
Every time he said the sprite 0 hit was at the same time each frame while playing a video of Mario moving all over the place, I got distracted trying to figure out how that could possibly be true. I don't know what the purpose of lying about that for so long was, but as least lie in a way that doesn't break the explanation
4:34 Buddy. BUDDY. I’m happy that you’re getting sponsored by Brilliant. But you absolutely cannot fuckup “software” vs “hardware” this badly. Every Computer Engineering and Computer Science student in the country will come mobbing after you with pitch forks and torches, so: A capacitor. Is not. A software. Component. ITS. HARDWARE. GRAHHHHH okay rant over
Your technical details are incorrect in some aspects. I won't go too far into detail since most of the comments are already pointing this out. But I really hope you get someone who actually knows the NES proofread your work. As stuff like Sprite Zero was not an invention by Miyamoto. But a hardware quirk as the NES draws to the screen, you could ask it to notify the register after the first sprite is rendered and then execute whatever you want.
Not after the first sprite is drawn, after the first sprite overlaps an active BG pixel. You can see the debris that activates the collision left behind on the screen after the crash. Edit: just checked to make sure by disabling sprites and BG tiles in FCEU. The coin graphic is a BG tile, the dirt is sprite zero.
"create a layer and attach it to the camera". Layers and cameras are not actual constructs, they are creative ways of abstracting draw order and windowing to make it easier to reason about. Please don't include these terms when referencing hardware.
Imagine a bus that stops 29.97 times per second, and when it is stopped it can load more passengers on through the door. If you try to throw passengers at the door while it is running, the bus will crash.
I think you forgot one thing: what does the buffers exactly hold? They obviously don't contain pixel data. And it's not a copy of OAM, that's larger than 63 bytes.
@@Abyssoftman as a huge fan of yours this was a BAD idea, it makes an already hard to understand explanation even worse for the viewer for a joke that’s admittedly not even funny.
9:10 "Mario isnt sprite zero! Its actually this other sprite that makes way more sense to be the sprite zero interrupt" Idk what the point of that bait-and-switch was but all it did was make the explanation more confusing than it was already. You joke about the viewer feeling betrayed but I seriously didn't like that. Edit: as an alternative, maybe bundle it with the part about the sprite table instead of having the viewer question how Mario could be a valid sprite zero interrupt for several minutes
You didn't like that and I on the other hand expected that. It's simply easier to think about Mario as an example for a sprite. The revelation came later than expected but it was funny to me.
i guess he just finished the whole video, believing that mario was sprite 0 but then realised while researching, that that isnt acutally the case. instead of redoing the whole video he just made a joke out of it and went "acssshually this coin is sprite 0."
I think my favorite part is the reaction from the speedrunners, they're always so funny and goofy I love them so much. "OH MY GOD I DID IT!!! OH MY GOD!!"
honestly it should only seem goofy to an outsider. speedruns and similar things are something you really have to grind for and gain mastery- it's a long term, lofty goal and so of course it feels incredible - and is a great deal of relief and excitement - when you finally achieve your goal. same way that sports teams lose their mind when they win the championships, or whatnot.
So wait.... half the video is a lie because mario was not sprite 00? Was this just to reach 12 minutes and mix in a ad that has little to do with the video? He's not even using the word bitmaps correctly...
Yea its so strange, I came to this video interested in the concept but to be shown that half of the new info I was told wasn't real? So confusing to keep track alone when trying to learn new concepts. It's like walking into a brand new class and halfway through the prof just goes JK lol here's how it ACTUALLY works, so weird
It seems to be an extremely common issue with videos in general where the people creating the video forget that viewers need more than a split second to see what is being talked about and to understand it. Like whatever this thing is before 2:34. I'd rather move on to a new video than try to rewind repeatedly and lose interest. Now if you'll excuse me, I'm off to another video.
Im pretty sure SMB1 is not the first game to have a sprite 0 hit status bar. Sprite 0 hit is and was a well known programming technique because it was the only thing close to a scanline counter in the NES.
If you get the score to update multiple times in the same second, the sprite data will be copied to the buffer too late and will arrive in the wrong buffer, causing there to be no Sprite Zero in the correct buffer, and therefore the game's logic will fall over and crash the NES. I think.
Because the author doesn't understand it either. He's trying to explain things in a very convoluted way when it's actually a very simple concept. Sprite zero hit is a hardware functionality that allows the code to determine when a v-blank period ends, but if the sprite used is fully transparent the code will never be notified that the v-blank has ended because an opaque pixel is needed to collide against another opaque pixel, and therefore the game will be stuck in a loop waiting for the v-blank to end.
@@dantemeriere5890You're explaining it wrong too, because sprite zero has nothing to do with VBlank and VBlank isn't relevant to the effect being created.
@@CptJistuce Sprite zero hit sets a flag that gets cleared at the end of a v-blank, games check that flag to know when a v-blank ends. For that to work, the game must ensure a hit every frame. Otherwise the game falls into an infinite loop. Now watch the video again with that in mind and you will learn why it hangs.
@@dantemeriere5890 The game isn't checking to see when the flag is cleared. It is checking to see when the flag is SET. The sprite zero flag is used here for a mid-screen "raster effect", specifically changing the scroll registers after the status bar is drawn.
@@SomeGuy712x no, terrain aren't sprites, except for blocks when they are hit. I left some info out of this video to try and make it easier to digest but I ended up adding confusion, a lesson for next time
I generally love your videos but the technical explanations in this one are a total mess. I'm pretty sure you don't understand most of what you're saying. Did you try to show the video to someone more knowledgeable to confirm it's accurate before punishing? They probably would have warned you about Miyamoto too ;)
The actual run was shown well: if we just assume that you need to be at a coin count ending in 1 and need to collect 4 coins at once because "reasons", then the way you showed the record being improved was really good.
Was there anything in particular you thought I was wrong on? I'll say up front that I had to leave some things out because explaining them gets very off topic to the video itself, so someone with technical knowledge might have questions about why I didn't mention X, Y, or Z, and the answer to that is viewers without that technical background won't be able to follow along as giving them lots of knew concepts gets hard to follow so I try to keep it to the essentials in a digestible form.
@@Abyssoft Well I'll say upfront that I'm not a NES developer so I probably won't be totally accurate. That said, here's some points, the way I understand it: 1. The position of sprite 0 is extremely important. The bait-and-switch you played at the start with Mario completely destroys the technical explanation. The interrupt (≈ function call) occurs at the end of the scanline where the sprite is, and that's when it moves the background. So the coin sprite was deliberately placed right at the bottom of the score display, specifically to control the timing of the interrupt. If it were Mario, it makes no sense as his position keeps changing. 2. I'll have to rewatch to remember more, but that's the biggest problem
@@Abyssoft 2. The explanation you have about PPU and CPU accessing the same thing, and VRAM1 and VRAM2... Here I don't know enough to say what's right, but I'm fairly sure everything you're saying about this is either wrong or irrelevant.
@@Abyssoft What I do know about NES graphics, I picked up from watching videos by Displaced Gamers on UA-cam. Amazing channel for technical explanations.
6:40 That image composite is rather misleading, as it suggests clouds might be as high as the info display, but of course for the scrolling trick to work they can't be. I am struggling with your calling it a UI, user interface, because it's just a one-way display. Does that count as an interface? I'd be more inclined to say HUD. Is there a better term? (Similarly, 4:30, the software doesn't really "interact" with the scanlines, as you say. It outputs them and doesn't get anything back.) Add one to the Miyamoto pronunciation count, but please, also, it's pronounced BROTHERS. This is painful. (And it's spelled Bros., with a period, as you can see everywhere official. Because it's a written abbreviation. For Brothers.)
The 6:40 wasn't drawn perfectly to scale, that aside clouds aren't transparent so it wouldn't affect anything. I also debated calling it a HUD over UI but ultimately went with UI, but on reflection HUD would have been better. Also Orcarina ;)
Status bar would be a more precise term. It IS a form of user interface. HUD is objectively the wrong term, but calling status bars "HUDs" has become very common in the gaming community. HUD comes from military aircraft, and is about putting important information where the pilot is looking so they don't have to glance away from the action to check their instruments. It is the exact opposite of a status bar.
While Miyamoto is a game development genius in his own right, he's just the designer for game mechanics and levels while the actual code, according to google, was made by Toshihiko Nakago and Kazuaki Morita
It wasnt until after i clicked on it that I remembered skipping over the same video with a different thumbnail. I dont like to think thumbnails affect my habits that much but whatever you changed did in fact work
2:50 The tiles are 8x8, so it would have to move by 8 pixels, not 7, right?. Also, that grid is horribly misaligned. And in a different way every time.
On a number of occasions, I've had W1-2 crash in the section after the star, after ducking under the low brick wall, in the area shortly afterward where there are a few Goombas and coins collectable by smashing the bricks underneath them. Sometimes the game survives the crash, and simply corrupts screen contents temporarily with numbers and other portions of sprites. I never did figure out how to do either the crash or corruption at will, though.
I never knew something like the U.I. at the top of the screen took so much work. Its actually insane how much effort had to go in just for that one thing to work smoothly.
So if you cause a lot of sprite updates on the same frame, it overloads VRAM 1 buffer and sprite 0 doesnt get drawn so theres no sprite 0 hit so the game crashes? This explanation was confusing as hell, and not because its hard to understand but because it was explained so poorly. Im not even sure my understanding is remotely correct.
While the video makes it seem like buffer 1 is related to sprites, it's not; the sprite buffer is a separate thing entirely. Instead, VRAM buffer 1 is a general-purpose VRAM transfer buffer for updating things like palettes and background elements like breaking blocks and the HUD, while VRAM buffer 2 is a specialized buffer for loading background columns while scrolling. The bug happens because a buffer 1 overflow into buffer 2 (caused here by queuing up many HUD score updates on the same frame) can cause corruption of the HUD, which can remove the coin tile that is colliding with sprite 0. Sprite 0 is still there, but it's now on top of transparent (sky) pixels, so no hit occurs. The code that waits for sprite 0 hit is not designed to handle the case where a hit never happens, so it gets stuck waiting for the hit forever, causing the game to hang.
I haven’t even watched this video yet, but I MUST applaud the accuracy of your title. So many times in videos and songs (such as CinemaSins calling it “XX minutes or less”) I just see it get needlessly done wrong 🤦♂️. Kudos to you, sir!
I’ve always wondered this! Honestly, I kept looking everywhere and couldn’t find anything as detailed yet succinct as this! Thank you. But a follow up question, what causes the glitch that rarely happens when you fail this glitch? The one that seemingly shuffles every sprite randomly and makes goombas turn into the back half of bowser?
You know, for as common as that technique was, I doubt that was the intended use of this hardware feature. It would seem instead to be a method for creating hardware accelerated sprite collision detection in 80s arcade ports. After all, the Famicom was designed to run Donkey Kong above all else, a prototypical game from its era - a trait which made it amazing system for games of that type.
I usually like your vidoes but this one is not it. I couldn’t watch the whole thing. I feel like there are a lot of plot holes in explaining something that isn’t understood well and on top of that, mispronouncing Miyamoto’s name potentially on purpose for more engagement made me almost unsub. You’re better than this.
While this video is a technical disaster and the guy’s narrating voice is not the best, he said Miyamoto’s name exactly how literally everyone I know said it before UA-cam came out. I don’t think it’s a big deal.
This is really, REALLY bad. Here's a little bit more if it already hasn't turned a stone elsewhere. Super Mario Bros. for the Nintendo Entertainment System and/or original Family Computer is a 40kB rom. 32kB for code. 8kB for Graphics. It contains NO mapper, so no extensions. Graphics can be defined either as part of a BG (background) or as a sprite (free-motion object), both in 8x8 tiles. (code can combine tiles to work together for larger tiling effects) Both the level and the upper HUD are drawn as BG, where a vertical interrupt every frame skews the internally managed scrolling a quarter-ways through the drawn frame. Such Scrolling is hardware-bound, and was (nearly) exclusive to the NES. The level includes the Ground, pipes, clouds, hills, and inactive bricks and coins...Essentially anything that is not in current interaction, or does not need independence from hardware scroll. The HUD is simply the text drawn over the screen. The timer, lives, and coin count are simple containers that constantly read from registers (of which I cannot remember, nor whether or not are hex/dec convertible). Sprites include the Mario Bros., goombas, koopas, buzzy beetles, Bowser, flames, hammer bros., bumped and broken bricks, power-ups, and, for reasons, "sprite 0", the coin drawn at the top of the screen, which dictates where an vertical interrupt should stop, and the game resume scrolling. An invalid read/write, and an overflow (caused by a 1up off screen, bumped block, goomba running timer to despawn after being squished, etc.) can push the PC (Program Counter; location of running code) where it shouldn't be to read invalid data, and, inevitably, crash. In this case, you've destroyed the only thing holding the interrupt together, the coin holding at the coin counter, so the PC gets stuck, where only a reset can break it out. she gi ru ma i e mo to != shi ge ru mi ya mo to
Everybody here hurt by his pronunciation of Myamoto... and the only thing that I can think of is how happy I am that someone finally understand how I feel when people call Ryu "Rayu"
People who miss pronounce names of foreign persons for their entire life (because foreign words are hard to pronounce for everyone) feel elitist by telling other people that they pronounce 1 name correct which they themselves can pronounce correctly. Miyamoto wouldn't be able to pronounce my name correctly, so what, why should I care, I care about his good work instead.
The old game's programing is insane. It's so sad we don't have to use these mind blowing techniques and impovise like this anymore because of memory limitations and or other limitations like the hud not following the camera automaticly in this case
If you are gonna make a joke, please make it more obvious for us who haven’t played the game or really know about the mechanics. It made it feel as everything you said was true only for me to come into the comments and feel disappointed that the sprite 0 thing was a joke in a seemingly informative video. Just my two cents
Some of you have pointed out errors I've made in the video and I'd like to address them, the two I'm seeing the most are:
1. Mario isn't Sprite 0
2. Sprite 0 wasn't created by the software team, it's part of the hardware functionality
Mario being Sprite 0 was a joke I included that hasn't landed for a lot of people, for those of you with a technical knowledge of the NES it rightly didn't make sense for Mario to be Sprite 0 as there as good reasons for him to not be Sprite 0. For those of you that may be encountering these concepts for the first time it created confusion and made the video harder to follow. In the future I won't be making jokes with concepts core to the topic of the video, thanks for the feedback on that. In this instance I could have explained why the coin sprite was used and why Mario isn't a good spite 0, that added context may have helped clear up some of the confusion.
As to Sprite 0 being created by the software team, this was an error on my part, the team that made SMB didn't create a function in the code for sprite 0, it's a part of the hardware. Thanks to everyone that pointed this out, I should have clued in when reading the NESDEV wiki that it wasn't a software thing.
Thanks for bringing these issues to my attention, it's important for info to be correct and I'll work harder to ensure that it is in future uploads.
ok
@@LavaCreeperPeople ok!
you are true professional
Uh oh
Now the question is, does this glitch crash Nintendo World Championships on the Switch, is it ignored, or does it cause a rewind?
This whole video is a convoluted way of saying that "the sprite zero is used to tell when a v-blank ends; if it's blank it never ends". Let me explain what actually happens in a clear way:
Sprite zero is used to determine when a special state called a v-blank ends. A vertical blank, or v-blank, is the time between the last line of the current frame and the first line of the next frame, which is never defined clearly in the video for some reason. You can think of it as the time between frames. The v-blank is important because it is the time the PPU is NOT accessing the sprites and is instead waiting for the next frame(it's idle), meaning that this is the time when you can safely update data in shared memory or registers without causing a data race(writing to memory that's currently being read).
Super Mario Bros. uses the little coin there to determine when a v-blank ends. There's nothing particularly ground-breaking or genius about this, they just decided it made sense since it's always there. The coin, which is sprite zero, is used by the NES to calculate a pixel-hit against the background(it's not used for collision detection like this video seems to suggest). If opaque pixels overlap, then a sprite zero hit is considered to have happened. This means that amongst other things, games can use it to tell when a v-blank period ends, as the hit state is cleared before the electron gun starts drawing the next frame, thus allowing programmers to know when it's unsafe to access memory shared with the PPU.
This means that in Super Mario Bros. you can lock the game in an infinite loop by finding a way to corrupt the UI coin(sprite zero) such that it becomes a fully transparent sprite, which consequently would never trigger the v-blank end state. Players found out that a specific set of steps causes buffer overflow that overrides sprite zero with arbitrary memory garbage that makes it transparent. This makes the game believe it's unsafe to update the graphics and it ends up locked in an infinite loop waiting for the now impossible v-blank end state.
In other words: sprite zero is used to tell when the time between frames ends, and if it's transparent, it never ends. By following a specific set of steps, players can cause a buffer overflow that overrides sprite zero with garbage memory that makes it transparent, thus locking the game in an infinite loop waiting for the v-blank end state.
you shouldve made the video instead of him
The sprite zero hit doesn't indicate the end of VBlank. It indicates the end of the status bar, because there is a tile with visible pixels set under the bottom of the coin(you can actually see the triggering "dirt" left behind on the screen once the coin is cleared and the crash happens).
Once the sprite zero collision is registered, the CPU can reset the scroll registers on the PPU, because it now knows all the data that needs to not scroll has all been drawn to the screen. It allows the CPU to know how far through the image the PPU has made it, so mid-frame "raster effects" are possible.
And since it just sets a bit in a status register rather than raising an interrupt, the CPU can miss the hit if other things are happening. That's why sometimes the status bar scrolls for a couple of frames, and why MMC3 added a scanline-counter that raised an interrupt.
@@CptJistuce Yes it does. The hit flag is cleared at the end of every v-blank. This means that games can track the state of the flag to know when the v-blank ends, but for that to work it must guarantee that a hit will occur next frame, otherwise it gets stuck in an infinite loop. Now watch the video again. As he mentions at 9:30, the developers assumed a sprite zero hit would always occur, when it doesn't the game hangs. Now you know why. When only the HUD logic is compromised what we get is a completely different effect where the HUD glitches out and doesn't appear static. But yes, sprite zero can also be used for other purposes, which is exactly why I said "*amongst other things*". Drawing in relation to the camera was one such "other thing", but that was pretty irrelevant to the explanation.
ls there not a WSYNC strobe in the NES? The implemented solution seems so intricate.
Sorry to be "that guy" but a couple things are a bit iffy imo:
* Sprite 0 is clearly intended for the purpose of doing something like a scrollbar, it's not a genius move on Miyamoto's part.
* The devs of SMB didn't "create a function called a sprite 0 hit", the sprite 0 hit is something built-in to the hardware that the developers made use of.
yeah, I lso noticed how much of a big deal he was making out of it when it's clearly a hardware function used in many games
Only one thing to do now: Spread the word that Maiyamoto invented the sprite 0 hit and piss everybody off
I'm curious which team at Nintendo did architect the NES and if they had any involvement in SMB
also that random lie about mario being sprite 0 was completely pointless and just made this more confusing
@@ZeludeRose we love padding without research
This is a video that you watch, then turn to Retro Game Mechanics Explained and re-binge the entire thing so you truly understand what's going on lol
Was about to say, this is literally some Pokémon Q level shit.
the way you pronounced shigeru miyamoto phsyically hurt
same
That's his cousin, Shigeru Mayamoto.
It's engagement bait. He says it wrong, you comment on how it annoys you, he gets more comments from the hundreds of other people who also complain about the same thing
@@zeroone4661EazySpeezy does this constantly, calling VHSs "DVDs", as if he doesn't know, gets lots of comments, only to do it again.
@@TalesNTSounded more like Zuchero to me.
Gotta say the engagement bait here is really subtle, he gets so much else in this video wrong that it seems entirely possible he wouldn't even know how to pronounce miyamoto's name
This crash is crazy! Very impressive! Does this mean that Super Mario Bros has a new speedrun category? Crash percent?
the category already existed but it was normally done in 1-2. the faster crash saves about 26 ish seconds
the optimization is gonna be CRAZY with this one.
Bricktendo Entertainment Paperweight any%
Quite the contrary, the category is dead because it's been pretty much maxed.
@@ehx3419 Unless there's another way to do it
please tell me all the obvious mistakes are intentional ways to get people to write angry comments for engagement.
According to the sticky, they were not. :|
"This is the fastest someone has ever managed to crash the game"
*laughs in hitting the console with a hammer*
without DAMAGING the console itself.
well.. that's ONE way to do it
You can just tilt the cartridge. Toploader NES or not
@@artstrange3230You can cartridge tilt with the original NES?
@@maxrichards5925
Yeah. Matter of fact, if you tilt too hard, it'll dislodge the cartridge from its socket and you'll be able to take it out. I suggested lightly tapping it. It works better if your console is old and you haven't done any pin replacement operations on it.
And you can also just bump the console for the same effect.
Please get someone who understands how CRTS and the NES work to help you with the technical details as I did not understand most of what you said. Just a minor criticism since you make great videos, just a way for you to improve :D
CRT's render lines one at a time and 2 pauses happen during rendering.
The horizontal blank (hblank) is a very short pause that happens between the end of a scanline and the beginning of the next scanline. The PPU prepares how to draw sprites for the next line during that time and it only has time to prepare 8. Most games use a function to invert the order of sprites on screen so they flicker instead of becoming invisible when there are more than 8.
The vertical blank (vblank) is a long pause between 2 frames where the PPU has nothing to do. This is the only time each frame that the CPU has time to upload data to VRAM. The NES is designed to have a non-maskable interrupt (NMI) at the beginning of vblank to interrupt the CPU of whatever it's doing and the software can start uploading tile and sprite data to the PPU.
When outside both hblank and vblank, the PPU focuses on rendering background as the CRT beam goes from left to right. The PPU has enough time to render 2bpp (bit per pixel, in this case 4 colors) per 8 pixels tile plus a tile attribute to select a palette per 16 pixels. While drawing 8 pixels of one tile, the PPU will prepare the next tile by loading: a tile from the nametable, a tile attribute from the name table and load 2x 8-bit of a sliver of 8 pixels.
The CPU can change background scroll values mid frame to achieve 2 or more different scrolling values in one frame. Sprite 0 is used for timing (as explained in the video). Changing the X coordinate of the background is easy but changing Y value requires abusing a hardware glitch and I don't want to get too technical about it.
The VRAM buffers that he's talking about are part of SMB's software.
@@Myself086 Wow thank you so much for explaining this!! I appreciate the time and effort you took to break it down for me e🙏
shageroh maiyamoto is a very brilliant man
LMAO
69 like I don't Wana mess up the like counter xD
but IDK should i...?😈
POV: you are watching a man explain something he doesn't himself understand
U got a typo
@@JoshyW-g3rwho cares
Fr
Jokes on you, I don't understand it even after it was explained to me!
Shiggura Mayamoto
This video feels a little rushed and underdeveloped.
*DO NOT WATCH!!! YOU WILL LEARN WRONG!*
This video contains a lot of *subtle inaccuracies* and *half-truths* that will confuse you and make it more difficult to learn about NES hardware and coding.
1:18 is showing a "minus world" where the game read an invalid level header and loaded an overworld map layout as an underwater type level, which is why it has strange graphics and colors. For real examples of graphical corruption from mistimed PPU writes, see Displaced Gamers' videos on Strider and Mega Man 3.
1:23 has misleading phrasing. _Everything_ is drawn by the PPU on _every_ frame using data from a separate memory space than CPU memory. This separate memory is updated by the CPU sending commands to the PPU (or to the cart hardware, for more advanced features). Sprite data (OAM) is usually kept in CPU memory and copied to PPU memory before each frame using special hardware functionality (DMA), so the CPU copy can be updated for the next frame while the current frame is being drawn, but writing anything to the PPU should only be done between frames (or scanlines).
1:37 VRAM_Buffer2 is described accurately, but VRAM_Buffer1 does not handle sprites at all, it's a general scratch space used during other non-sprite graphical changes, such as updating the status bar, palette cycling (coins and ? blocks), and erasing background tiles when blocks are hit. It should also be noted that these are just arbitrary sections of CPU RAM allocated by the SMB1 code, they are not hardware chips as the video implies.
1:55 what the hell is that grid, I'm done, see every other comment for more mistakes
Please at least watch NesHacker, Displaced Gamers, and Retro Game Mechanics Explained and learn how to use Mesen's graphics viewers before trying to make videos like this.
Underrated comment
Ooh, I'll have to check out NesHacker, thanks. I already follow the other two, so I was cringing along with you through this video lol
5:39
CRTs don't send information in the form of light, but instead in the form of an electron beam, which is shot by a device quite literally called an "electron gun"
these electrons then excite the phosphorescent coating on the back of the tube, which causes it to glow
Thanks for pointing this out, if I cover crt's in depth again I'll make the correction.
@@Abyssoftyou got 2 typos
the technical explanations and diagrams in this video are full of inaccuracies and blatant errors. any research was clearly done very hastily, with no attempt to actually understand what's going on. issues range from misnaming several concepts (and mispronouncing the name of one of the most prolific video game designers of all time), to completely misrepresenting what a sprite-zero hit actually does and why it works. i honestly think you should delete this video and either rewrite it with help from somebody who knows what they're talking about, or just scrap it altogether
Yea I agree
+1 As it stands, this video is basically misinfo
Damn another youtuber that I can't trust now🙄
I understood nothing except "make coin count go up 4 times in 1 frame while coin count ends in 1=crash"
Every time he said the sprite 0 hit was at the same time each frame while playing a video of Mario moving all over the place, I got distracted trying to figure out how that could possibly be true. I don't know what the purpose of lying about that for so long was, but as least lie in a way that doesn't break the explanation
4:34 Buddy. BUDDY. I’m happy that you’re getting sponsored by Brilliant. But you absolutely cannot fuckup “software” vs “hardware” this badly. Every Computer Engineering and Computer Science student in the country will come mobbing after you with pitch forks and torches, so:
A capacitor. Is not. A software. Component. ITS. HARDWARE. GRAHHHHH
okay rant over
Your technical details are incorrect in some aspects. I won't go too far into detail since most of the comments are already pointing this out. But I really hope you get someone who actually knows the NES proofread your work. As stuff like Sprite Zero was not an invention by Miyamoto. But a hardware quirk as the NES draws to the screen, you could ask it to notify the register after the first sprite is rendered and then execute whatever you want.
Not after the first sprite is drawn, after the first sprite overlaps an active BG pixel. You can see the debris that activates the collision left behind on the screen after the crash.
Edit: just checked to make sure by disabling sprites and BG tiles in FCEU. The coin graphic is a BG tile, the dirt is sprite zero.
"Shigeru Mayamoto" lol
yup, that hurt...
He definitely did this so we would comment about it, but man, it still hurts...
maya hee, maya hoo, maya haa, maya ha ha
I didn't catch that, I was like, wait a minute, this guy sounds familiar....?
0:17 I had a very different question when I heard this: "Okay, but why though?"
"create a layer and attach it to the camera". Layers and cameras are not actual constructs, they are creative ways of abstracting draw order and windowing to make it easier to reason about. Please don't include these terms when referencing hardware.
Well, that certainly wasn't a BAD video... but... definitely an explanation of questionable accuracy. Fine enough for a VERY rough overview I guess?
No mention of a bus?
Imagine a bus that stops 29.97 times per second, and when it is stopped it can load more passengers on through the door. If you try to throw passengers at the door while it is running, the bus will crash.
The technical explanation in this video is inaccurate to a degree which is almost satirical...
I think you forgot one thing: what does the buffers exactly hold? They obviously don't contain pixel data. And it's not a copy of OAM, that's larger than 63 bytes.
3:03 this pronunciation made my ears bleed
my yuh moto
Shiguru Mayamoto the GOAT
Which one-“my-uh-moto” or “mario brohs”?
i remember a video where he pronounced ocarina of time as orcarina of time so it's not that surprising
@@Nathanatos22 mario bros was mostly fine
This video makes so many misrepresentations and is painful to watch.
"Mario isn't sprite 0"
@@Abyssoft Then why did u use him for sprite 0?
@@CosmicNek0 9:10 He explains it
@@Abyssoftman as a huge fan of yours this was a BAD idea, it makes an already hard to understand explanation even worse for the viewer for a joke that’s admittedly not even funny.
@@Abyssoft great response man glad you're so receptive to criticism
9:10 "Mario isnt sprite zero! Its actually this other sprite that makes way more sense to be the sprite zero interrupt"
Idk what the point of that bait-and-switch was but all it did was make the explanation more confusing than it was already. You joke about the viewer feeling betrayed but I seriously didn't like that.
Edit: as an alternative, maybe bundle it with the part about the sprite table instead of having the viewer question how Mario could be a valid sprite zero interrupt for several minutes
Just a joke that didn't land for some people, sorry for the confusion.
You didn't like that and I on the other hand expected that. It's simply easier to think about Mario as an example for a sprite. The revelation came later than expected but it was funny to me.
The joke would have landed significantly better if it wasn't surrounded by so many other technical errors
i guess he just finished the whole video, believing that mario was sprite 0 but then realised while researching, that that isnt acutally the case. instead of redoing the whole video he just made a joke out of it and went "acssshually this coin is sprite 0."
I think my favorite part is the reaction from the speedrunners, they're always so funny and goofy I love them so much. "OH MY GOD I DID IT!!! OH MY GOD!!"
Followed by the dog howling and him thanking the dog.
honestly it should only seem goofy to an outsider. speedruns and similar things are something you really have to grind for and gain mastery- it's a long term, lofty goal and so of course it feels incredible - and is a great deal of relief and excitement - when you finally achieve your goal.
same way that sports teams lose their mind when they win the championships, or whatnot.
11:38 the “thanks dog” has me dead 💀😂❤
So wait.... half the video is a lie because mario was not sprite 00? Was this just to reach 12 minutes and mix in a ad that has little to do with the video? He's not even using the word bitmaps correctly...
most of this guys' videos are not very well informed, been like this for ages
Yea its so strange, I came to this video interested in the concept but to be shown that half of the new info I was told wasn't real? So confusing to keep track alone when trying to learn new concepts. It's like walking into a brand new class and halfway through the prof just goes JK lol here's how it ACTUALLY works, so weird
It seems to be an extremely common issue with videos in general where the people creating the video forget that viewers need more than a split second to see what is being talked about and to understand it. Like whatever this thing is before 2:34. I'd rather move on to a new video than try to rewind repeatedly and lose interest. Now if you'll excuse me, I'm off to another video.
Did you just say that "Gaster" crashed the game? Are we sure this wasn't on purpose for the memes?
That betrayal cut deep. Not sure i will get over it.
me neither.
but i have another just for good measure.
It's especially bad for a technical video as this since it only further creates confusion on the viewers part.
Great video! Thank you for featuring a clip of my STAGEO TAS as well.
Im pretty sure SMB1 is not the first game to have a sprite 0 hit status bar. Sprite 0 hit is and was a well known programming technique because it was the only thing close to a scanline counter in the NES.
I gotta be honest, this is one of the first videos that I just don't understand, lol. I'm a software engineer and I'm still pretty lost. Well done.
If you get the score to update multiple times in the same second, the sprite data will be copied to the buffer too late and will arrive in the wrong buffer, causing there to be no Sprite Zero in the correct buffer, and therefore the game's logic will fall over and crash the NES. I think.
Because the author doesn't understand it either. He's trying to explain things in a very convoluted way when it's actually a very simple concept. Sprite zero hit is a hardware functionality that allows the code to determine when a v-blank period ends, but if the sprite used is fully transparent the code will never be notified that the v-blank has ended because an opaque pixel is needed to collide against another opaque pixel, and therefore the game will be stuck in a loop waiting for the v-blank to end.
@@dantemeriere5890You're explaining it wrong too, because sprite zero has nothing to do with VBlank and VBlank isn't relevant to the effect being created.
@@CptJistuce Sprite zero hit sets a flag that gets cleared at the end of a v-blank, games check that flag to know when a v-blank ends. For that to work, the game must ensure a hit every frame. Otherwise the game falls into an infinite loop. Now watch the video again with that in mind and you will learn why it hangs.
@@dantemeriere5890 The game isn't checking to see when the flag is cleared. It is checking to see when the flag is SET.
The sprite zero flag is used here for a mid-screen "raster effect", specifically changing the scroll registers after the status bar is drawn.
I'd love to see a mod that zooms the camera out and lets you see the level being built in front of Mario and falling off behind him
Why the hell did you use Mario as sprite zero??
Every time he says sprite 0 hit, take a shot of sprite zero.
I'm not over that vicious betrayal.
7:09 thats a great joke lol.
(2:52) You mean if the UI moved by a full 8 pixels, not 7.
(3:14) Wait, the terrain objects aren't sprites, are they?
@@SomeGuy712x no, terrain aren't sprites, except for blocks when they are hit. I left some info out of this video to try and make it easier to digest but I ended up adding confusion, a lesson for next time
I generally love your videos but the technical explanations in this one are a total mess. I'm pretty sure you don't understand most of what you're saying. Did you try to show the video to someone more knowledgeable to confirm it's accurate before punishing?
They probably would have warned you about Miyamoto too ;)
The actual run was shown well: if we just assume that you need to be at a coin count ending in 1 and need to collect 4 coins at once because "reasons", then the way you showed the record being improved was really good.
Was there anything in particular you thought I was wrong on? I'll say up front that I had to leave some things out because explaining them gets very off topic to the video itself, so someone with technical knowledge might have questions about why I didn't mention X, Y, or Z, and the answer to that is viewers without that technical background won't be able to follow along as giving them lots of knew concepts gets hard to follow so I try to keep it to the essentials in a digestible form.
@@Abyssoft Well I'll say upfront that I'm not a NES developer so I probably won't be totally accurate. That said, here's some points, the way I understand it:
1. The position of sprite 0 is extremely important. The bait-and-switch you played at the start with Mario completely destroys the technical explanation. The interrupt (≈ function call) occurs at the end of the scanline where the sprite is, and that's when it moves the background. So the coin sprite was deliberately placed right at the bottom of the score display, specifically to control the timing of the interrupt. If it were Mario, it makes no sense as his position keeps changing.
2. I'll have to rewatch to remember more, but that's the biggest problem
@@Abyssoft
2. The explanation you have about PPU and CPU accessing the same thing, and VRAM1 and VRAM2... Here I don't know enough to say what's right, but I'm fairly sure everything you're saying about this is either wrong or irrelevant.
@@Abyssoft What I do know about NES graphics, I picked up from watching videos by Displaced Gamers on UA-cam. Amazing channel for technical explanations.
Great video, worst way ive heard miyamotos name said ever
Today I learned that Sugar Mingusmango is the mind behind the legendary Super Mario Bros.
Best comment
the way you pronounced miyamoto made me light headed. how is that POSSIBLE why is the human body just allowed to do that
Almost all of the technical information in this video is wrong.
6:40 That image composite is rather misleading, as it suggests clouds might be as high as the info display, but of course for the scrolling trick to work they can't be.
I am struggling with your calling it a UI, user interface, because it's just a one-way display. Does that count as an interface? I'd be more inclined to say HUD. Is there a better term? (Similarly, 4:30, the software doesn't really "interact" with the scanlines, as you say. It outputs them and doesn't get anything back.)
Add one to the Miyamoto pronunciation count, but please, also, it's pronounced BROTHERS. This is painful. (And it's spelled Bros., with a period, as you can see everywhere official. Because it's a written abbreviation. For Brothers.)
The 6:40 wasn't drawn perfectly to scale, that aside clouds aren't transparent so it wouldn't affect anything. I also debated calling it a HUD over UI but ultimately went with UI, but on reflection HUD would have been better. Also Orcarina ;)
Status bar would be a more precise term. It IS a form of user interface.
HUD is objectively the wrong term, but calling status bars "HUDs" has become very common in the gaming community.
HUD comes from military aircraft, and is about putting important information where the pilot is looking so they don't have to glance away from the action to check their instruments. It is the exact opposite of a status bar.
NOW WE NEED TO TRY THIS IN NINTENDO WORLD CHAMPIONSHIP NES EDITION
Miyamotos programming prowess is always super impressive to be. Such creative ways to get around all of the hardware limitations of early consoles
While Miyamoto is a game development genius in his own right, he's just the designer for game mechanics and levels while the actual code, according to google, was made by Toshihiko Nakago and Kazuaki Morita
@@teu009 🤓👆
@@s0nVanyou are a disgrace
Miyamoto didn’t invent the “Sprite 0 Hit”, this was misinformation in the video. It was an already imbedded aspect of the hardware.
It wasnt until after i clicked on it that I remembered skipping over the same video with a different thumbnail. I dont like to think thumbnails affect my habits that much but whatever you changed did in fact work
2:50 The tiles are 8x8, so it would have to move by 8 pixels, not 7, right?. Also, that grid is horribly misaligned. And in a different way every time.
On a number of occasions, I've had W1-2 crash in the section after the star, after ducking under the low brick wall, in the area shortly afterward where there are a few Goombas and coins collectable by smashing the bricks underneath them.
Sometimes the game survives the crash, and simply corrupts screen contents temporarily with numbers and other portions of sprites. I never did figure out how to do either the crash or corruption at will, though.
It will take time to get over that betrayal!
you know a game has been "beaten" when speedrunners are racing to glitch the game out faster lol
I never realized just how complicated the drawing algorithm was
I never knew something like the U.I. at the top of the screen took so much work. Its actually insane how much effort had to go in just for that one thing to work smoothly.
Yeah, status bars are actually really hard to do on the Nintendo if the background scrolls.
That was the weirdest pronunciation of Miyamoto I’ve ever heard in my fkn life bro
You playin saying his name like that right lol
i love your videos, i love to watch stuff like this but often zone out because they are too slow, yours tickle my brain perfectly . thanks Abyssoft
The kind of stuff I would be pulling considering how everything always goes wrong on my livestreams
So if you cause a lot of sprite updates on the same frame, it overloads VRAM 1 buffer and sprite 0 doesnt get drawn so theres no sprite 0 hit so the game crashes? This explanation was confusing as hell, and not because its hard to understand but because it was explained so poorly. Im not even sure my understanding is remotely correct.
While the video makes it seem like buffer 1 is related to sprites, it's not; the sprite buffer is a separate thing entirely. Instead, VRAM buffer 1 is a general-purpose VRAM transfer buffer for updating things like palettes and background elements like breaking blocks and the HUD, while VRAM buffer 2 is a specialized buffer for loading background columns while scrolling. The bug happens because a buffer 1 overflow into buffer 2 (caused here by queuing up many HUD score updates on the same frame) can cause corruption of the HUD, which can remove the coin tile that is colliding with sprite 0. Sprite 0 is still there, but it's now on top of transparent (sky) pixels, so no hit occurs. The code that waits for sprite 0 hit is not designed to handle the case where a hit never happens, so it gets stuck waiting for the hit forever, causing the game to hang.
The way you pronounced Miyamoto was unhinged lol
I haven’t even watched this video yet, but I MUST applaud the accuracy of your title.
So many times in videos and songs (such as CinemaSins calling it “XX minutes or less”) I just see it get needlessly done wrong 🤦♂️. Kudos to you, sir!
I’ve always wondered this! Honestly, I kept looking everywhere and couldn’t find anything as detailed yet succinct as this! Thank you. But a follow up question, what causes the glitch that rarely happens when you fail this glitch? The one that seemingly shuffles every sprite randomly and makes goombas turn into the back half of bowser?
Now for 3 frames of Mario 3 explained in 3 minutes
These speedrun categories are getting crazy.
You know, for as common as that technique was, I doubt that was the intended use of this hardware feature. It would seem instead to be a method for creating hardware accelerated sprite collision detection in 80s arcade ports. After all, the Famicom was designed to run Donkey Kong above all else, a prototypical game from its era - a trait which made it amazing system for games of that type.
if this happened to me as a kid, I would just take the cartridge out, blow on it, and put it back.
I was today years old when I realized that the cloud sprites are literally just the bush sprites, re colored
7:09 underrated pun
I usually like your vidoes but this one is not it. I couldn’t watch the whole thing. I feel like there are a lot of plot holes in explaining something that isn’t understood well and on top of that, mispronouncing Miyamoto’s name potentially on purpose for more engagement made me almost unsub. You’re better than this.
It's well understood, he's exaggerating
While this video is a technical disaster and the guy’s narrating voice is not the best, he said Miyamoto’s name exactly how literally everyone I know said it before UA-cam came out. I don’t think it’s a big deal.
This is really, REALLY bad. Here's a little bit more if it already hasn't turned a stone elsewhere.
Super Mario Bros. for the Nintendo Entertainment System and/or original Family Computer is a 40kB rom.
32kB for code. 8kB for Graphics. It contains NO mapper, so no extensions.
Graphics can be defined either as part of a BG (background) or as a sprite (free-motion object), both in 8x8 tiles. (code can combine tiles to work together for larger tiling effects)
Both the level and the upper HUD are drawn as BG, where a vertical interrupt every frame skews the internally managed scrolling a quarter-ways through the drawn frame. Such Scrolling is hardware-bound, and was (nearly) exclusive to the NES.
The level includes the Ground, pipes, clouds, hills, and inactive bricks and coins...Essentially anything that is not in current interaction, or does not need independence from hardware scroll.
The HUD is simply the text drawn over the screen. The timer, lives, and coin count are simple containers that constantly read from registers (of which I cannot remember, nor whether or not are hex/dec convertible).
Sprites include the Mario Bros., goombas, koopas, buzzy beetles, Bowser, flames, hammer bros., bumped and broken bricks, power-ups, and, for reasons, "sprite 0", the coin drawn at the top of the screen, which dictates where an vertical interrupt should stop, and the game resume scrolling.
An invalid read/write, and an overflow (caused by a 1up off screen, bumped block, goomba running timer to despawn after being squished, etc.) can push the PC (Program Counter; location of running code) where it shouldn't be to read invalid data, and, inevitably, crash. In this case, you've destroyed the only thing holding the interrupt together, the coin holding at the coin counter, so the PC gets stuck, where only a reset can break it out.
she gi ru ma i e mo to != shi ge ru mi ya mo to
So… a buffer overflow? 😂
*shi-gear-roo mee-uh-mow-toe
The UI didn't like that guy jumping on the Goomba whilst trying to obtain coins from the brick block
Thr sound of that plink was sick af
Honestly, fantastic segway to the ad 9/10
Everybody here hurt by his pronunciation of Myamoto... and the only thing that I can think of is how happy I am that someone finally understand how I feel when people call Ryu "Rayu"
Misery loves company?
People who miss pronounce names of foreign persons for their entire life (because foreign words are hard to pronounce for everyone) feel elitist by telling other people that they pronounce 1 name correct which they themselves can pronounce correctly. Miyamoto wouldn't be able to pronounce my name correctly, so what, why should I care, I care about his good work instead.
GASTER?!?!?
"Niftsky would prove it was possible for a human."
No, it was just possible for Niftsky.
I don't know if I'll ever get over this betrayal. The fact that you lied? Heartbreaking (legit, I snorted at that line)
Suguru Mayamoto?
3:02 YOU CALLED HIM WHAT!?
0:31 just one more coin...
haha 69 funny number big chungus am i right
@@dabmasterarsugandan skibidi chungus eats tide pods
This is such a wholesome chungus Keanu wholesome 42069 moment! Remember to updoot this comment and watch out for any TikTok normies!
@@yeetus2637thank you for the gold kind stranger!
p.s. updoots to the left!
3:03 "Shigero Maiamoto"
The old game's programing is insane. It's so sad we don't have to use these mind blowing techniques and impovise like this anymore because of memory limitations and or other limitations like the hud not following the camera automaticly in this case
ace? this game already has that
3:04
"Shuguru Myamoto"
Epic but i didnt understand anything you said
If you are gonna make a joke, please make it more obvious for us who haven’t played the game or really know about the mechanics. It made it feel as everything you said was true only for me to come into the comments and feel disappointed that the sprite 0 thing was a joke in a seemingly informative video.
Just my two cents
"Let's look at how it happens..."
How it happens involves a midroll ad. Cool. Forward thinking over there at Nintendo.
No
Thanks dog! ♥️
9:00 MissingNo entered mario world?!
I'm glad someone picked up on that
@@Abyssoft I was about to mention it myself. Brilliant joke.
-Don't- let Niftski hear this
Holy shit its gaster undertaled