I know a lot of people like to talk about modern game design, but I honestly find things like this, explaining much older games that had much more limited resources, to be much more interesting.
Absolutely! It's fascinating to find out how people worked around the limitations forced on them by the hardware of the day. When you can just do anything you want because there are no restrictions, it's much less interesting.
> When you can just do anything you want because there are no restrictions There are ALWAYS restrictions. Why do you think we still get new consoles with more powerful hardware?
>the point> >your head< Because at that point your kind of going on about polygons = emotions (if you'll excuse the meme). I mean, yes, without people specifically pushing the limits of hardware we wouldn't get where we are today at least in terms of gaming, but while the greater freedom of creation is better for creators, to me it always seems that the better products have always come about because of creators figuring out creative solutions rather than just going with the bigger and the better. Sure, there are bound to be limitations to how large or detailed you can make a 3d platformer in Unity, but it will I am much more interested in hearing about the making of Super Mario 64 or how Banjo Kazooie overcame its severely limited memory space to transition between songs by basically making 8 different versions of the same track. And don't take this to mean that there aren't interesting behind-the-scenes discussion to be had on the big-budget newer games -- I for one would like to hear a bit about the Witcher 3's cutscene process -- but the fact is that it's more interesting to see a painting done entirely in red paint produce a wide range of colors than to see a painting with a full palette that's either dull or clashing with itself.
Restrictions often breed a lot more beauty than having all of the tools in the world available to you, at least that's what makes it interesting to me :)
Woah, thanks friend! This is really cool to me. As a fairly tiny UA-camr, I would never expect anyone that watches my videos to actually find me in the comment section of another video, hahah. Especially one that's not even about ROM hacking. This is pretty awesome to me and it made my day. Thanks again! :)
@@JRPrestonIL idiot, it was just in the back of his head because he was wondering, and had no way of knowing or learning this. He wasn't ACTIVELY thinking about it for 20 years. Stop randomly harassing people on the internet, and get a life.
it's not quite that simple. If they fixed it that way, as he says, it would limit the number of objects you could show on a scan line. This was a BIG deal in NES games- it's responsible for the infamous NES 'flicker'. The simple fact is that the hardware was being pushed to its limit and minor visual glitching at the edge of the screen that didn't interfere with gameplay, and where many contemporary TVs didn't show the image anyways was considered acceptable.
@@djflugel79 I'm not sure, but my guess would be that they update the name tables in such a way that more of the weird tile effects happen on the left side of the screen, where 8 pixels are already covered.
I believe this was one of the first games to support horizontal and vertical scrolling simultaneously on the NES, so this could've been an issue that might've simply been overlooked or not even realized until so late into the production of the game that going back to fix it might not have been easily accomplished. What seems like such an obvious fix now might not have been so obvious back then as the problem itself was new.
I remembered these "glitchy" edges from the first day I bought SMB3. I bought that game same day it was released! I recall that the funky edge bothered me the most in some screens, such as the treasure rooms. Given the time, I played it on CRT TV sets and it was always very apparent no matter TV. I wonder if it is more pronounced on PAL version.
Game development is still a superset of computer science. From kinematics and dynamics (physics) to just rendering pixels on a screen, a software engineer will find it hard to become a competent developer even though any competent developer could become a great software engineer.
Oh, and the developer to machine language gap has been superseded with a communication gap between developer and developer. On teams with 4 or more individuals, the primary difficulty is having everyone on the team know what they are doing. If two or more people are working on the same code, code conflicts occur
Game programming is a very small subset of computer science (which by definition encompasses every kind of programming related topic). Also the idea that game programmers are more talented than the average software engineer is naive, very few of the most advanced techniques of computer science are used in games and game coders rarely do research and instead just borrow from more advanced fields. Advanced techniques are confined to very limited areas (rendering, physics), most of the rest of what we do on a day to day basis is frankly very ordinary.
I would like to see a behind the scenes video on how you make these videos. Specifically, the synchronized gameplay and explanatory diagrams. This makes the concept very easy to follow, even for non-techies. Kudos!
I'm only speculating here, but I suspect that he wrote a bunch of custom code :) Possibly extended an open-source emulator to add features which record debug output into image files dumping the nametables with the boxes / lines drawn in?
Throughout the video I was wondering if you'd mention how TVs tended to cut off the edges anyways, glad you got to that at the end. A lot of things older games did (or got away with) was because they were for display on TVs at the time and not monitors.
Graphics were made with the fuzzy "pixels" of crts in mind, too. Link's purple hair in LttP was a big meme for a while but if you played it in the 90s on a faded crt it looked fine, probably better than if they used a "correct" color
Man. Kinda makes me appreciate and miss the old games of game development. Devs had to be SMART, accurate, and clever. The amount of complexity for even something as old as the NES just to pull off what we perceive as a simple game is incredible.
no wonder why a japanese company excelled. Maybe im stereotypical but from this to tears of the kingdom Nintendo has a pretty clear history of innovation
Nice explanation. I always wondered why SMB3 used horizontal mirroring even though vertical scrolling in that game is pretty rare, 95% of the time you're just scrolling horizontally on the ground of the level. Seems like it would make more sense to have the seam visible during vertical scrolling. I'm thinking it might have something to do with the split rendering with the status bar at the bottom, but not sure.
I believe that may have been the reason, but it would still be possible. Kirby's Adventure was able to do that, so I don't see why SMB3 wouldn't. KA was released 5 years after SMB3, so make it was just better knowledge of the system.
I'm not up to any sort of level of knowledge on this stuff, but what if they "letterboxed" the game at the top and bottom and made it appear to be widescreen?
I've ALWAYS wondered this. Thank you so much. Now explain that weird glitchy line over Shadow Man in the stage select screen of every copy of Mega Man 3!
That gets into a concept commonly called a "scanline interrupt", where you have program code execute at the precise moment when the PPU reaches a certain line during its display cycle. This is how you can take the single, rigid background layer and manipulate it into appearing to be more flexible than it is, e.g. Super Mario Bros. 3 changes the vertical scroll position at the ~208th line (in horizontally scrolling levels) so that the HUD (which always occupies the lowest 4 rows in this case) appears locked into place at the bottom. Technically right at the HUD cut-off in SMB3 is a similar problem to what you're seeing with MM3's stage select. In either case, a scanline interrupt occurs and you've done work in the background but you just didn't have quite enough time between the previous scanline ending and the new one beginning, and the overrun is manifesting as a glitchy in-between mess. While scanline interrupts are used for the triple-split of the stage select in MM3, the greater question is really why they didn't shut off the effect once it locks into place.
That was simply an incorrectly set up interrupt timing for the MMC3 mapper chip. Same with some of the other line glitches during fights against larger bosses.
For the longest time I was always wondering why that one side of the screen looked like that. Glad this video finally explains it. Its something I can put to rest and not wonder about anymore. Great job on explaining it.
This is so neat. I remember we weren't allowed to play NES on the newer TV in the living room since Mom and Dad thought the lines on the right were the TV getting damaged by the NES, so we used to play on the smaller TV in the back room.
This is just completely random: 0:12 The sky colours. All slightly different for palette reasons I assume, BUT the original Mario Bros sky colour is just perfection. Not your typical sky colour that anyone would normally choose (they'd choose the Mario 2 colour I'm sure). But it's just RIGHT. That whole game is just INFITE PERFECTION.
If you had a REALLY old TV back then from the maybe the 70s, yeah, the overscan and framing around the tube were big enough to hide things like that but televisions OF that time from the mid-to-late 80s like we owned had smaller framing that still let you see a little bit of the loading seam and the masking on the left. It also depended on the model and company that manufactured the TV. I remember my grandma's TV from 1984 had a thick outer frame around the tube but the NES would always displayed it's video a full inch from the left edge of the frame so the left-side masking in Mario 3 was VERY apparent.
Glad I’m not the only one who saw the blocks turn green towards the right of the screen. They turned more colors, but that was the easiest to spot due to its stark contrast from the terrain.
Half Life 3 is slated for release sometime in July of this year. We are currently adding fine touches to the maps and verifying continuity in the story. The game makes use of new rendering techniques, but we will not release a public demo or announcement about Half Life 3 until March.
@@TemporalDriver I don't work at Valve as a game designer and I am not willing to reveal my position because I am not even supposed to be talking about this. Anyway we have had to push the announcement and right now it is slated for June 5th. I am not guaranteeing anything; it may very well be pushed again.
I spent the whole video waiting for you to mention the fact that 80s and 90s TVs would cut off these seams anyway and that we only got super aware of them in the emulation era. You saved it to the last sentence!!
This reminds me of the HMOVE artifact that created short black "comb" lines at the left side of the screen in many Atari 2600 games (you can see it really clearly in the attract mode of Space Invaders, when the screen background cycles through screensaver colors). There, it was prominent enough that TV overscan usually wouldn't just cover for it. Some games hid it by just drawing a vertical black bar on the left (which could be expensive, since game objects were in much, much shorter supply on the 2600), or using an entirely black screen background. But few players really cared--they didn't have high expectations for game graphics in those days.
Dude, thank you so much for this explanation! Growing up I always wondered why the colors of the screen edge were all wonky! Even playing this game on my sony PVM a few months ago, my head started to itch. Especially since my brain is wired in such a way that it attempts to understand the technical aspect of everything. What a hell of a thing to stumble on. I instantly subscribed after seeing how well you described everything!
Good video...I never noticed this as a kid because my television covered up the edges. Pretty rude awakening when I noticed this happening all the time in an emulator.
ANOTHER FUN FACT: Games that use bi-directional scrolling (like Mario 3) COULD have also got around this problem by using veritcal mirroring instead, because the top and bottom eight pixels of the display are automatically cropped off of the display anyway. However, Mario 3 could not utilize this because they needed to use horizontal mirroring so they could have the status bar at the bottom of the screen, otherwise the status bar would shift oddly as the edge of the map gets updated over it. This is also why Mario 3 levels are set with the same height of about two screens, so that they never have to move the status bar.
Good explanation, thanks. To be noted, the Master System also exhibits the same issue only with horizontal scrolling games, but not for the same reason. What actually happens on Master System is that there is only room to put exactly 1 screen in length, which means that there is no room left to prepare what is going to be displayed when the screen will scroll. To deal with this, developers also used to hide one column of 8 pixels to the left of the screen. This means that they had no other choice but to refresh constantly the background by chunks of 8 pixels, which worked in the end of course. The issue does not exist for vertical scrolling games as there is room available top/down. The Master System was a very well built system, but still this is a bit of an oversight from SEGA, as well as the fact that it cannot flip sprites.
I've been supporting you on Patreon for a while, but the consistent high quality of your videos has convinced me to increase my contribution. Thanks for the awesome videos :D
For each video I put out I feel like it's not as good as the last one. I've always guessed it's just me being hard on myself, but it's good to have someone else confirm that for me, heh.
Even on old TVs of the era (1970s TVs), this was noticeable by other means. Kick a shell into a block that is right at the edge, and you’d see phantom artifacts of that block on the other side. I’m surprised this glitch wasn’t mentioned in the video.
I am sure there's a technical reason for this, but why didn't they use horizontal scrolling and just hide the artifacting under the status UI at the bottom of the screen?
Focus on the Idea The status UI is part of the background layer. When scrolling vertically this scrolls as well, but by careful timing you can scroll the screen twice to restore it's position. However this means if you scroll vertically on an area larger than the nametable height, you have to do weird extra calculations about where the scrolling part ends and the status bar begins otherwise you overwrite the status bar itself. The vertical scrolling in SMB3 is limited to an area 2 screens tall, so you never have to deal with this. The status bar is always the bottom of the entire nametable, and because you don't rewrite any horizontal rows of the nametable, only vertical columns, you don't have to worry about it as much. As long as you write vertical columns of tiles say, 50 tiles high instead of the full 60, you won't mess up the status bar. If you used a horizontal nametable with vertical scrolling you would now have to track which row you are updating and ensure you never write over the part of the display that is the status bar. It's a minor bit of extra work, but still more work. Plus, it wouldn't actually hide the problem. Now instead of being visible at the sides of the screen the exact same problem would show up at the top of the screen and at the edge between the play area and status bar. Remember the status bar is NOT on TOP of the background, it is part of it. So it doesn't hide anything..
Thanks for this really good explanation. I always wondered why SMB 3 has glitches on the right side, and i wondered even more why they were still present in the virtual console release. Now i know. Keep up the great work!
1:17 The blue rectangle showing where the screen is has a slight discrepancy in it. The screen is always 256 pixels wide and 240 pixels high, but most emulators have the screen resolution set to 256x224p and have eight pixels cropped at the top and bottom by default. Some emulators, like BizHawk, have no way of changing this to make the screen resolution correct, but other emulators, like FCEUX and Nestopia, have video settings that can change the screen resolution.
This is really educational! Well explained! I had no idea these kind of mechanisms went into platformers (and probably other kinds of Games with moving backgrounds) Subscribed!
You should make a video about the glitchy line in the lower left corner. It's just above the left side of the status bar. You'll see a short line flickering and changing colors and such. I heard it has something to do with IRQs that the game uses, but that's as much detail as I know. It'd be great to get your side of things Cheers. And thanks for the amazing channel. =D
WOW this is a fantastic video for someone who is just starting with NES development and learning about the inner workings of the NES. Thank you so much!
Just found you, and I love the subject matter so I bet you will see a bump of at least one on most your videos in the next day or so from me. Thanks for putting this info out!
Awesome video. The entire time, I kept thinking that I should write a comment about how overscan likely masked this issue anyway before emulators came along - and then you addressed even that. I've subscribed.
I actually learned all of this about a year ago when I was studying the NES's capabilities. I spent a lot of time studying the nametables while playing games, trying to understand what was going on, and asking questions on message boards. It would have been so much easier to follow if I could have just witched this video to explain it!
I noticed this for the first time about 4 years ago when playing Mario 3 on my original NES and looked it up immediately. At first i thought there was something wrong with my game or NES. This loading seam is also present on the 3DS port of Super Mario 3. I learned a few new things about this glitch. Thank you for the info!
Why are two name tables mirrored? around 0:39, you mention that the NES has enough VRAM to do two name tables, and mirroring is used to fill the other two. Is there some reason there needs to be four?
Avagadro22 Not an expert, but my guess is that the 4 tables allow the NES to support diagonal scrolling, even though most games would not use it. At around 2:35 you can see how SMB3 takes advantage of the 4 tables to scroll diagonally. I don't think that kind of movement would be possible with just 2 tables.
I was confused as well, but this is how I understand it. He said the PPU has enough "room" for 4 name tables. However, there is only enough VRAM for 2. Therefore, the PPU just draws the 2 name tables in VRAM twice.
The name tables tell it which tiles to draw in a large grid. The NES only has enough memory for 2 grids, but you can choose whether they stack horizontally or vertically, or you can provide extra memory in the cartridge to use all 4 at once. SMB3 took the route of 2 grids stacked vertically, since most TVs would crop the miscolored tiles anyway.
Wonderful ! I've always been interested in the mechanics of the NES, which, as hardware buffs should know, is actually more complex than the SNES for its many mappers.
Very high quality. Nice job. It's these sorts of technical limitations that I find really interesting about game development, even if I don't do it myself.
Actually the "sole reason" the seam exists on the edge is because of the status bar at the bottom of the screen. If they didn't need that status bar, they could have used vertical mirroring. And since the vertical area drawn to the screen is smaller than the vertical space available in vertical mirroring, there is enough room to update that image without having the seam on the top/bottom edge. This was commonly done in RPGs. However, since they had that status bar on the bottom of the screen, it was easier to use horizontal mirroring so they could keep the status bar in the same place in the name table, and just accept a not-really-noticeable glitch on the far side of the screen.
What a great explanation! I remember this being quickly mentioned at a GDQ years ago, but I could never find the clip and I've been wondering ever since.
GDQ often mentions interesting topics but glosses over the specifics or digs into the details but lacks enough charisma to make it interesting. This channel does an excellent job of finding the sweet spot between interesting/cursory and dull/informative.
Interesting how emulation, or displaying image on a modern display device, allows you to see things that weren't normally visible to the player when played on the assumed CRT SDTV. Overscan, which I knew is why this was just ignored, is one thing. Another is for example the way display on a CRT is smoothed out, both because the TV has really no concept of horizontal resolution (it has only a defined number of lines), and the way the digital image (be it in a full frame buffer, or generated on the fly) is converted into the analog signal. This is why, when playing on an emulator that just displays the framebuffer verbatim, in for example Silent Hill on Playstation 1, there's visible noise, which is actually a feature of the GPU, ordered color dithering, designed to simulate a larger number of possible colors by changing the color of adjecent pixels semi0randomly, and taking adventage of how the image will be blurred on a TV. Or another example I think is that some games fake semi-transparency, by rapidly switching the visibility of objects, and taking advantage of the ghosting effect of CRTs, so on modern displays it doesn't work and you just see flicker. That's why more advanced emulators simulate some of those features,.
The loading seam is also visible in MOTHER / EarthBound Beginnings. The game allows for diagonal movement, which at the time was a rarity in JRPGs, so there was a seam visible at the top of the screen.
Cool trick you can do in a couple spots on the first level: if you throw a shell a block on the seam, it will trigger but turn green and will stop interacting with anything.
Ok, so I had a handful of NES games I thought were defective in some way because they seemed off center and weren't displaying properly. Turns out you just explained what may be the common thread amongst them all. Dragon Warrior I & II, Kirby, SMB3, Golgo13, A Boy And His Blob, The Legend Of Kage... Now I have to balance overscan on my PVM across multiple systems to come up with a good compromise and finally stop worrying about it, thanks!
Just playing SMB3 on my Switch and I thought it was a graphical glitch, and now fate brought me to this video. *_insert is google always listening meme here_*
Wow, thank you so much, I just recently found your channel and this is the 4th video I watched. Thanks for the info alot! I've been wondering why that happens for a long time now. You just answered my several year question! Thank you!
The 'overscan' argument was really the one that brought it all together. Up until that point my main question was.. Why place 'the unavoidable flaw' on the horizontal edge?' Or rather the main traveled one. Especially in the shown example of 1-1: changing the mirroring would move the glitch to the exceptional situation (screen doesn't scroll up if you aren't flying), in which you're usually moving forward anyway (so you would have the glitch regardless)
I might do a followup video explaining this because a lot of people are asking the same thing. It has to do with the status bar and how interrupts are used to move the screen position mid-frame so it always shows up at the bottom of the screen. With vertical mirroring, the status bar would be mirrored too, and it would show up in the middle of the level!
When you started talking about scrolling nametables, and how they worked, it just fell into place for me due to the fact that SMB3 uses both vertical and horizontal scrolling.
I remember back in the day, that the schoolyard would rumor that a hidden block in the coin bonus sky would lead to a secret level. If I only knew this back in the day.
Impressive indeed. However modern devs have a point. Back then, consoles were more up to speed with their hardware. It was entirely possible to get a pc for the same or a higher price than a console that out performed it in raw power. Nowadays, consoles lag far behind in comparison to PCs.
Most CRTs I've used from the 80s onwards have had room to display about 168 color clocks of information going across, which works out to about 252 pixels on the NES. But many older sets, you probably could not see that much.
the way to fix this is to have the palette swap on the other side of the screen, e.g. have it swap immediately upon loading in another 8x8 tile. this would put the loading seam on the left side of the screen, which would be masked by the PPU.
Nintendo should have used a horizontal name table. horizontal scrolling is used way more often, and also when vertical scrolling is used, the hud can hide the artifacting tiles. just give priority to the tiles shown at the top of the screen and the wrap around on the botton with the wrong tiles will be behind the hud
There is just one issue: The HUD is part of the tilemap so you would need to deal with complicated IRQ to handle vertical scrolling, not to mention possible artifacts appear on the _top_ of the screen. Horizontal mirroring and not too large levels is easier. Edit: Though you can use vertical mirroring so the status bar is outside of the level tilemap... and get into the issue that you can't scroll the screen vertically as you'll see the status bar if you scroll the screen vertically. Or you can scroll the screen vertically at the cost of losing horizontal scrolling (that's how SMB3 handles vertical levels, btw).
Can I just take a moment to point out that, rather than use game BGM like 99% of UA-cam channels dedicated to 'game analysis' you chose to keep it silent. I absolutely say that the silence helped me keep my attention on the explanation rather than on the game on screen. Thanks! It's a welcome break from UA-cam's overused tactic of using the game's visual and (or) auditive merits to cover for the (oftentimes lackluster) arguments presented in the video.
Why can't Mario 3 use vertical mirroring and write a 8 pixel MMC3 interrupt to the very top of the screen? The HUD covers the bottom area already. Boom, everything is masked
Actually the problem you're facing here is how the HUD is drawn. In levels that scroll horizontally, the top-to-bottom vertical span goes from the top of the level to the bottom and then the last 4 rows are occupied by the HUD. With the way the HUD works, using your idea would require it to be completely overwritten with level background in the scanlines above it and then it would need to be entirely replaced at the scanline where it starts. There's just not enough CPU or PPU bandwidth to pull that off. Of course if we were to simplify the HUD and draw it without using the nametables at all, at the expense of some of the very limited hardware sprite space, your idea might be workable.
The MMC3 has a scanline interrupt feature, which means the interrupt can only ever be triggered at the end of a scanline (during horizontal blanking I believe)
![10 Weird NES Facts! [Nintendo Entertainment System] | Nintendrew](http://i.ytimg.com/vi/DKOtyWggaNI/mqdefault.jpg)
I know a lot of people like to talk about modern game design, but I honestly find things like this, explaining much older games that had much more limited resources, to be much more interesting.
Absolutely! It's fascinating to find out how people worked around the limitations forced on them by the hardware of the day. When you can just do anything you want because there are no restrictions, it's much less interesting.
> When you can just do anything you want because there are no restrictions
There are ALWAYS restrictions. Why do you think we still get new consoles with more powerful hardware?
>the point>
>your head<
Because at that point your kind of going on about polygons = emotions (if you'll excuse the meme). I mean, yes, without people specifically pushing the limits of hardware we wouldn't get where we are today at least in terms of gaming, but while the greater freedom of creation is better for creators, to me it always seems that the better products have always come about because of creators figuring out creative solutions rather than just going with the bigger and the better. Sure, there are bound to be limitations to how large or detailed you can make a 3d platformer in Unity, but it will I am much more interested in hearing about the making of Super Mario 64 or how Banjo Kazooie overcame its severely limited memory space to transition between songs by basically making 8 different versions of the same track. And don't take this to mean that there aren't interesting behind-the-scenes discussion to be had on the big-budget newer games -- I for one would like to hear a bit about the Witcher 3's cutscene process -- but the fact is that it's more interesting to see a painting done entirely in red paint produce a wide range of colors than to see a painting with a full palette that's either dull or clashing with itself.
Restrictions often breed a lot more beauty than having all of the tools in the world available to you, at least that's what makes it interesting to me :)
you should watch some of john carmack's keynote talks at quakecon. super interesting
This has bothered me for about 20 years now. It's such a relief to have this weight randomly lifted on a Wednesday morning.
Squiggs 【Glitches - ROM Hacks - Speedruns】 Good to see you here. Love your videos btw.
Woah, thanks friend! This is really cool to me. As a fairly tiny UA-camr, I would never expect anyone that watches my videos to actually find me in the comment section of another video, hahah. Especially one that's not even about ROM hacking. This is pretty awesome to me and it made my day. Thanks again! :)
Squiggs 【Glitches - ROM Hacks - Speedruns】 this comment thread caused me to look at your videos 😜
Yelling at strangers in a UA-cam comment. get a life dude.@@JRPrestonIL
@@JRPrestonIL idiot, it was just in the back of his head because he was wondering, and had no way of knowing or learning this. He wasn't ACTIVELY thinking about it for 20 years. Stop randomly harassing people on the internet, and get a life.
"look at this deep and complex issue. Here is how they could have fixed. But didnt bother because TVs just covered the edges on their own' holy shit
it's not quite that simple. If they fixed it that way, as he says, it would limit the number of objects you could show on a scan line. This was a BIG deal in NES games- it's responsible for the infamous NES 'flicker'.
The simple fact is that the hardware was being pushed to its limit and minor visual glitching at the edge of the screen that didn't interfere with gameplay, and where many contemporary TVs didn't show the image anyways was considered acceptable.
@@SavageGreywolf ^^ 100% agreed, the video didn't say "I can do this better" rather "here's why they didn't get rid of it despite being able to"
Now I am wondering how Kirby did it better.
@@djflugel79
I'm not sure, but my guess would be that they update the name tables in such a way that more of the weird tile effects happen on the left side of the screen, where 8 pixels are already covered.
I believe this was one of the first games to support horizontal and vertical scrolling simultaneously on the NES, so this could've been an issue that might've simply been overlooked or not even realized until so late into the production of the game that going back to fix it might not have been easily accomplished. What seems like such an obvious fix now might not have been so obvious back then as the problem itself was new.
I read this as "Nintendo's Loading Scam"
That would be a completely different video...
Same.
I read it as the NES loading screen
I read it as Nintendo Loading seen
I read this as "Nintendo's virtual console scam"
ME TOO
I remembered these "glitchy" edges from the first day I bought SMB3. I bought that game same day it was released! I recall that the funky edge bothered me the most in some screens, such as the treasure rooms. Given the time, I played it on CRT TV sets and it was always very apparent no matter TV. I wonder if it is more pronounced on PAL version.
Another brilliant upload. Even its most basic form, games development seemed like a real challenge.
The Game Show yeah devs today are spoiled, back in the day you had to work in machine code to make console games.
Shaun Dreclin Well, assembly, but yeah, you actually needed to know how the hardware worked.
Game development is still a superset of computer science. From kinematics and dynamics (physics) to just rendering pixels on a screen, a software engineer will find it hard to become a competent developer even though any competent developer could become a great software engineer.
Oh, and the developer to machine language gap has been superseded with a communication gap between developer and developer. On teams with 4 or more individuals, the primary difficulty is having everyone on the team know what they are doing. If two or more people are working on the same code, code conflicts occur
Game programming is a very small subset of computer science (which by definition encompasses every kind of programming related topic). Also the idea that game programmers are more talented than the average software engineer is naive, very few of the most advanced techniques of computer science are used in games and game coders rarely do research and instead just borrow from more advanced fields. Advanced techniques are confined to very limited areas (rendering, physics), most of the rest of what we do on a day to day basis is frankly very ordinary.
I would like to see a behind the scenes video on how you make these videos. Specifically, the synchronized gameplay and explanatory diagrams. This makes the concept very easy to follow, even for non-techies. Kudos!
I'd like to know that too, how do you record the video and make the cut-out of the map into an animated diagram ??
Anyone else vote for this? ;)
This comment needs more votes!
I'm only speculating here, but I suspect that he wrote a bunch of custom code :) Possibly extended an open-source emulator to add features which record debug output into image files dumping the nametables with the boxes / lines drawn in?
6 years later but he wrote a program that transforms NES data into after effects data
I never noticed it because my TV cuts it off. lol
Throughout the video I was wondering if you'd mention how TVs tended to cut off the edges anyways, glad you got to that at the end. A lot of things older games did (or got away with) was because they were for display on TVs at the time and not monitors.
A lot of the monitors of the day were also CRT.
@@MaddTheSane Monitors didn't overscan like TVs though
Graphics were made with the fuzzy "pixels" of crts in mind, too. Link's purple hair in LttP was a big meme for a while but if you played it in the 90s on a faded crt it looked fine, probably better than if they used a "correct" color
Man. Kinda makes me appreciate and miss the old games of game development. Devs had to be SMART, accurate, and clever. The amount of complexity for even something as old as the NES just to pull off what we perceive as a simple game is incredible.
no wonder why a japanese company excelled.
Maybe im stereotypical but from this to tears of the kingdom Nintendo has a pretty clear history of innovation
Nice explanation. I always wondered why SMB3 used horizontal mirroring even though vertical scrolling in that game is pretty rare, 95% of the time you're just scrolling horizontally on the ground of the level. Seems like it would make more sense to have the seam visible during vertical scrolling. I'm thinking it might have something to do with the split rendering with the status bar at the bottom, but not sure.
I believe that may have been the reason, but it would still be possible. Kirby's Adventure was able to do that, so I don't see why SMB3 wouldn't. KA was released 5 years after SMB3, so make it was just better knowledge of the system.
dotsarecool Kirby also scrolls more slowly because it has to maintain two copies of the nametable in VRAM.
I'm not up to any sort of level of knowledge on this stuff, but what if they "letterboxed" the game at the top and bottom and made it appear to be widescreen?
Why should they prevent some of the visible screen area from displaying the game.
Possibly because glitches when scrolling vertically would have been more visible and distracting, since it's usually empty space.
I've ALWAYS wondered this. Thank you so much.
Now explain that weird glitchy line over Shadow Man in the stage select screen of every copy of Mega Man 3!
That gets into a concept commonly called a "scanline interrupt", where you have program code execute at the precise moment when the PPU reaches a certain line during its display cycle. This is how you can take the single, rigid background layer and manipulate it into appearing to be more flexible than it is, e.g. Super Mario Bros. 3 changes the vertical scroll position at the ~208th line (in horizontally scrolling levels) so that the HUD (which always occupies the lowest 4 rows in this case) appears locked into place at the bottom.
Technically right at the HUD cut-off in SMB3 is a similar problem to what you're seeing with MM3's stage select. In either case, a scanline interrupt occurs and you've done work in the background but you just didn't have quite enough time between the previous scanline ending and the new one beginning, and the overrun is manifesting as a glitchy in-between mess. While scanline interrupts are used for the triple-split of the stage select in MM3, the greater question is really why they didn't shut off the effect once it locks into place.
That was simply an incorrectly set up interrupt timing for the MMC3 mapper chip. Same with some of the other line glitches during fights against larger bosses.
For the longest time I was always wondering why that one side of the screen looked like that. Glad this video finally explains it. Its something I can put to rest and not wonder about anymore. Great job on explaining it.
This is so neat. I remember we weren't allowed to play NES on the newer TV in the living room since Mom and Dad thought the lines on the right were the TV getting damaged by the NES, so we used to play on the smaller TV in the back room.
This is just completely random: 0:12 The sky colours. All slightly different for palette reasons I assume, BUT the original Mario Bros sky colour is just perfection. Not your typical sky colour that anyone would normally choose (they'd choose the Mario 2 colour I'm sure). But it's just RIGHT. That whole game is just INFITE PERFECTION.
If you had a REALLY old TV back then from the maybe the 70s, yeah, the overscan and framing around the tube were big enough to hide things like that but televisions OF that time from the mid-to-late 80s like we owned had smaller framing that still let you see a little bit of the loading seam and the masking on the left. It also depended on the model and company that manufactured the TV. I remember my grandma's TV from 1984 had a thick outer frame around the tube but the NES would always displayed it's video a full inch from the left edge of the frame so the left-side masking in Mario 3 was VERY apparent.
Dude, this editing is so slick and effective
Glad I’m not the only one who saw the blocks turn green towards the right of the screen.
They turned more colors, but that was the easiest to spot due to its stark contrast from the terrain.
My friend on at Valve says that Half Life 3 is delayed for this very reason.
Half Life 3 is slated for release sometime in July of this year. We are currently adding fine touches to the maps and verifying continuity in the story. The game makes use of new rendering techniques, but we will not release a public demo or announcement about Half Life 3 until March.
HL3 will be released one week after the brexit.
Half life 3 is dead. Please stop spreading this joke.
@@TemporalDriver I don't work at Valve as a game designer and I am not willing to reveal my position because I am not even supposed to be talking about this. Anyway we have had to push the announcement and right now it is slated for June 5th. I am not guaranteeing anything; it may very well be pushed again.
@@TemporalDriver People don't usually believe me because of the meme, but it's coming.
I spent the whole video waiting for you to mention the fact that 80s and 90s TVs would cut off these seams anyway and that we only got super aware of them in the emulation era. You saved it to the last sentence!!
I didn't notice it in the emulation era because... I played the SNES version instead.
Wow. Im speechless. That was brilliant.
This reminds me of the HMOVE artifact that created short black "comb" lines at the left side of the screen in many Atari 2600 games (you can see it really clearly in the attract mode of Space Invaders, when the screen background cycles through screensaver colors). There, it was prominent enough that TV overscan usually wouldn't just cover for it. Some games hid it by just drawing a vertical black bar on the left (which could be expensive, since game objects were in much, much shorter supply on the 2600), or using an entirely black screen background. But few players really cared--they didn't have high expectations for game graphics in those days.
Dude, thank you so much for this explanation! Growing up I always wondered why the colors of the screen edge were all wonky! Even playing this game on my sony PVM a few months ago, my head started to itch. Especially since my brain is wired in such a way that it attempts to understand the technical aspect of everything. What a hell of a thing to stumble on. I instantly subscribed after seeing how well you described everything!
These graphics you've made makes understanding this so much easier. Thank you!
Good video...I never noticed this as a kid because my television covered up the edges. Pretty rude awakening when I noticed this happening all the time in an emulator.
Right? I thought either the emulator or the ROM file were corrupt the first time I notices that.
It's nice that emulators nowadays offer configurable cropping of the game display to "emulate" overscan.
The intro jingle never gets old.
ANOTHER FUN FACT:
Games that use bi-directional scrolling (like Mario 3) COULD have also got around this problem by using veritcal mirroring instead, because the top and bottom eight pixels of the display are automatically cropped off of the display anyway. However, Mario 3 could not utilize this because they needed to use horizontal mirroring so they could have the status bar at the bottom of the screen, otherwise the status bar would shift oddly as the edge of the map gets updated over it.
This is also why Mario 3 levels are set with the same height of about two screens, so that they never have to move the status bar.
Good explanation, thanks. To be noted, the Master System also exhibits the same issue only with horizontal scrolling games, but not for the same reason. What actually happens on Master System is that there is only room to put exactly 1 screen in length, which means that there is no room left to prepare what is going to be displayed when the screen will scroll. To deal with this, developers also used to hide one column of 8 pixels to the left of the screen. This means that they had no other choice but to refresh constantly the background by chunks of 8 pixels, which worked in the end of course. The issue does not exist for vertical scrolling games as there is room available top/down.
The Master System was a very well built system, but still this is a bit of an oversight from SEGA, as well as the fact that it cannot flip sprites.
I've been supporting you on Patreon for a while, but the consistent high quality of your videos has convinced me to increase my contribution. Thanks for the awesome videos :D
Thank you!
@dotsarecool huh?
For each video I put out I feel like it's not as good as the last one. I've always guessed it's just me being hard on myself, but it's good to have someone else confirm that for me, heh.
I'm pretty sure that "huh?" meant to be a confused expression since he didn't know that you were the uploader.
HandreyAlex Thats right
Even on old TVs of the era (1970s TVs), this was noticeable by other means. Kick a shell into a block that is right at the edge, and you’d see phantom artifacts of that block on the other side. I’m surprised this glitch wasn’t mentioned in the video.
I'm sure you get this all the time but THE CHANNEL JINGLE AT 0:13 IS GENIUS!
Here, this will make it even cooler: ua-cam.com/video/2VHySu_jaPw/v-deo.html
I am sure there's a technical reason for this, but why didn't they use horizontal scrolling and just hide the artifacting under the status UI at the bottom of the screen?
Focus on the Idea The status UI is part of the background layer.
When scrolling vertically this scrolls as well, but by careful timing you can scroll the screen twice to restore it's position.
However this means if you scroll vertically on an area larger than the nametable height, you have to do weird extra calculations about where the scrolling part ends and the status bar begins otherwise you overwrite the status bar itself.
The vertical scrolling in SMB3 is limited to an area 2 screens tall, so you never have to deal with this.
The status bar is always the bottom of the entire nametable, and because you don't rewrite any horizontal rows of the nametable, only vertical columns, you don't have to worry about it as much.
As long as you write vertical columns of tiles say, 50 tiles high instead of the full 60, you won't mess up the status bar.
If you used a horizontal nametable with vertical scrolling you would now have to track which row you are updating and ensure you never write over the part of the display that is the status bar.
It's a minor bit of extra work, but still more work.
Plus, it wouldn't actually hide the problem.
Now instead of being visible at the sides of the screen the exact same problem would show up at the top of the screen and at the edge between the play area and status bar.
Remember the status bar is NOT on TOP of the background, it is part of it.
So it doesn't hide anything..
Thanks for this really good explanation. I always wondered why SMB 3 has glitches on the right side, and i wondered even more why they were still present in the virtual console release. Now i know. Keep up the great work!
This is something I've been curious about for years but never curious enough to actively search for an answer. Very relieved to finally know
1:17 The blue rectangle showing where the screen is has a slight discrepancy in it. The screen is always 256 pixels wide and 240 pixels high, but most emulators have the screen resolution set to 256x224p and have eight pixels cropped at the top and bottom by default. Some emulators, like BizHawk, have no way of changing this to make the screen resolution correct, but other emulators, like FCEUX and Nestopia, have video settings that can change the screen resolution.
This is really educational! Well explained!
I had no idea these kind of mechanisms went into platformers (and probably other kinds of
Games with moving backgrounds)
Subscribed!
Great video, always wondered why that happened. Keep explaining!
You should make a video about the glitchy line in the lower left corner. It's just above the left side of the status bar. You'll see a short line flickering and changing colors and such. I heard it has something to do with IRQs that the game uses, but that's as much detail as I know. It'd be great to get your side of things Cheers. And thanks for the amazing channel. =D
Gosh, the production quality of this channel has been amazing ever since apparently. Glad to have found this
WOW this is a fantastic video for someone who is just starting with NES development and learning about the inner workings of the NES. Thank you so much!
Just found you, and I love the subject matter so I bet you will see a bump of at least one on most your videos in the next day or so from me. Thanks for putting this info out!
That is pretty mindblowing. I always wondered why that was, now I know!
Awesome video. The entire time, I kept thinking that I should write a comment about how overscan likely masked this issue anyway before emulators came along - and then you addressed even that. I've subscribed.
just found this channel with this video... I love it. it looks like you answer so many things I have wondered but couldn't find answers to!
These videos are really interesting. Please do more!
I actually learned all of this about a year ago when I was studying the NES's capabilities. I spent a lot of time studying the nametables while playing games, trying to understand what was going on, and asking questions on message boards. It would have been so much easier to follow if I could have just witched this video to explain it!
I noticed this for the first time about 4 years ago when playing Mario 3 on my original NES and looked it up immediately. At first i thought there was something wrong with my game or NES. This loading seam is also present on the 3DS port of Super Mario 3. I learned a few new things about this glitch. Thank you for the info!
The 3DS version just an NES emulator running a ROM of SMB3, so that bug will stay there
Why are two name tables mirrored? around 0:39, you mention that the NES has enough VRAM to do two name tables, and mirroring is used to fill the other two. Is there some reason there needs to be four?
Avagadro22 Not an expert, but my guess is that the 4 tables allow the NES to support diagonal scrolling, even though most games would not use it.
At around 2:35 you can see how SMB3 takes advantage of the 4 tables to scroll diagonally. I don't think that kind of movement would be possible with just 2 tables.
You can have extra hardware in the cartridge that enables the full 4 tables to be mapped in, I don't think any game actually did that though.
They're mirrored because the memory address lines are all wired into the same place on the circuit board.
I was confused as well, but this is how I understand it. He said the PPU has enough "room" for 4 name tables. However, there is only enough VRAM for 2. Therefore, the PPU just draws the 2 name tables in VRAM twice.
The name tables tell it which tiles to draw in a large grid. The NES only has enough memory for 2 grids, but you can choose whether they stack horizontally or vertically, or you can provide extra memory in the cartridge to use all 4 at once.
SMB3 took the route of 2 grids stacked vertically, since most TVs would crop the miscolored tiles anyway.
I'm always impressed when I learn about some of the work arounds that developers had to use back in the day. This was really interesting! Thank you!
Wonderful ! I've always been interested in the mechanics of the NES, which, as hardware buffs should know, is actually more complex than the SNES for its many mappers.
Very high quality. Nice job. It's these sorts of technical limitations that I find really interesting about game development, even if I don't do it myself.
these videos are obscenely high quality
Not sure why this video was recommended to me, but I was definitely not disappointed by the content. You just earned yourself a new subscriber sir.
Actually the "sole reason" the seam exists on the edge is because of the status bar at the bottom of the screen.
If they didn't need that status bar, they could have used vertical mirroring. And since the vertical area drawn to the screen is smaller than the vertical space available in vertical mirroring, there is enough room to update that image without having the seam on the top/bottom edge. This was commonly done in RPGs.
However, since they had that status bar on the bottom of the screen, it was easier to use horizontal mirroring so they could keep the status bar in the same place in the name table, and just accept a not-really-noticeable glitch on the far side of the screen.
What a great explanation!
I remember this being quickly mentioned at a GDQ years ago, but I could never find the clip and I've been wondering ever since.
GDQ often mentions interesting topics but glosses over the specifics or digs into the details but lacks enough charisma to make it interesting. This channel does an excellent job of finding the sweet spot between interesting/cursory and dull/informative.
Fun fact: the game Felix the Cat uses the method you described of having objects on the far edge of the screen to mask out the seam.
"Cut off by the overscan" its amazing how many things exploited overscan and not just in gaming.
Interesting how emulation, or displaying image on a modern display device, allows you to see things that weren't normally visible to the player when played on the assumed CRT SDTV. Overscan, which I knew is why this was just ignored, is one thing.
Another is for example the way display on a CRT is smoothed out, both because the TV has really no concept of horizontal resolution (it has only a defined number of lines), and the way the digital image (be it in a full frame buffer, or generated on the fly) is converted into the analog signal. This is why, when playing on an emulator that just displays the framebuffer verbatim, in for example Silent Hill on Playstation 1, there's visible noise, which is actually a feature of the GPU, ordered color dithering, designed to simulate a larger number of possible colors by changing the color of adjecent pixels semi0randomly, and taking adventage of how the image will be blurred on a TV.
Or another example I think is that some games fake semi-transparency, by rapidly switching the visibility of objects, and taking advantage of the ghosting effect of CRTs, so on modern displays it doesn't work and you just see flicker.
That's why more advanced emulators simulate some of those features,.
The loading seam is also visible in MOTHER / EarthBound Beginnings. The game allows for diagonal movement, which at the time was a rarity in JRPGs, so there was a seam visible at the top of the screen.
I love videos like this that actually explain why stuff like this happens in detail instead of just pointing it out. now subscribed!
I always thought my copy was damaged or something. This is a very interesting and well done video! 🙏
Cool trick you can do in a couple spots on the first level: if you throw a shell a block on the seam, it will trigger but turn green and will stop interacting with anything.
This is an awesome and insightful look into the rendering behind NES games. Subbed.
I just love the thought and quality of your content. Thanks for putting in the hours to make these.
Very deep explanation of a typical NES Game "Anomaly".... Thanks
Your visuals are so detailed and perfect, thank you.
Great vid! Glitchy edges are definitely worth it for the ability to fly in SMB3.
I've needed this channel for so long, so happy to find it
Ok, so I had a handful of NES games I thought were defective in some way because they seemed off center and weren't displaying properly. Turns out you just explained what may be the common thread amongst them all.
Dragon Warrior I & II, Kirby, SMB3, Golgo13, A Boy And His Blob, The Legend Of Kage...
Now I have to balance overscan on my PVM across multiple systems to come up with a good compromise and finally stop worrying about it, thanks!
Found this in my recommended. Was very pleased to have watched this video.
This was your first video I watched. I always wondered about this glitch, and you explained it in an in-depth very well made way. +1 Subscriber!
I always thinking of this glitchy graphic especially in the Ice fortress in World 6.
Very cool and clear explanation. Something I'd noticed but never thought about!
Just playing SMB3 on my Switch and I thought it was a graphical glitch, and now fate brought me to this video. *_insert is google always listening meme here_*
Wow, thank you so much, I just recently found your channel and this is the 4th video I watched. Thanks for the info alot! I've been wondering why that happens for a long time now. You just answered my several year question! Thank you!
cool video Retro Game Mechanics Explained™
Lambby yeah
The 'overscan' argument was really the one that brought it all together.
Up until that point my main question was..
Why place 'the unavoidable flaw' on the horizontal edge?'
Or rather the main traveled one.
Especially in the shown example of 1-1: changing the mirroring would move the glitch to the exceptional situation (screen doesn't scroll up if you aren't flying), in which you're usually moving forward anyway (so you would have the glitch regardless)
I might do a followup video explaining this because a lot of people are asking the same thing. It has to do with the status bar and how interrupts are used to move the screen position mid-frame so it always shows up at the bottom of the screen. With vertical mirroring, the status bar would be mirrored too, and it would show up in the middle of the level!
I always liked seeing this effect, I just see it as part of the retro aesthetic.
Your channel deserves more subscribers, it's always so interesting and well explained :D
Nice work! I love having video game bugs explained in detail.
When you started talking about scrolling nametables, and how they worked, it just fell into place for me due to the fact that SMB3 uses both vertical and horizontal scrolling.
I remember back in the day, that the schoolyard would rumor that a hidden block in the coin bonus sky would lead to a secret level. If I only knew this back in the day.
Today Devs: Hardware is too underpowered.
Old Devs: Pluuuaasee!
JustMe! "Pluuuaasee!"?
Plu-Aw-Sei
Impressive indeed. However modern devs have a point. Back then, consoles were more up to speed with their hardware. It was entirely possible to get a pc for the same or a higher price than a console that out performed it in raw power. Nowadays, consoles lag far behind in comparison to PCs.
Sounds plausible.
Today's Gamers: i can count those pixels
Old Gamers: Pluuuaasee!
Great video. Slick animation, nice explanation, and high quality. Keep it up.
I'm here after Implantgames suggested this video. Quite the thorough explanation.
Most CRTs I've used from the 80s onwards have had room to display about 168 color clocks of information going across, which works out to about 252 pixels on the NES. But many older sets, you probably could not see that much.
i mean i always figured it was because it was loading the next part of the screen but never really cared about the details
I've never played the original release of SMB3, but it's still cool to see how glitches like that occurred
the way to fix this is to have the palette swap on the other side of the screen, e.g. have it swap immediately upon loading in another 8x8 tile. this would put the loading seam on the left side of the screen, which would be masked by the PPU.
I've been playing Super Mario since at least 1989, but I've never noticed this issue before.
First video of yours i watched. Informative and well presented :)
Maybe speak a bit louder into the mike?
Aside from that gj and i subbed
Your editing is epic!
Great video! Very informative!
This video is amazing, you deserve far more subscribers and views
I've played this game thousands of times since it came out when I was a kid. I never noticed this before, but now it's all I'm going to see.
Nintendo should have used a horizontal name table. horizontal scrolling is used way more often, and also when vertical scrolling is used, the hud can hide the artifacting tiles. just give priority to the tiles shown at the top of the screen and the wrap around on the botton with the wrong tiles will be behind the hud
There is just one issue: The HUD is part of the tilemap so you would need to deal with complicated IRQ to handle vertical scrolling, not to mention possible artifacts appear on the _top_ of the screen. Horizontal mirroring and not too large levels is easier.
Edit: Though you can use vertical mirroring so the status bar is outside of the level tilemap... and get into the issue that you can't scroll the screen vertically as you'll see the status bar if you scroll the screen vertically. Or you can scroll the screen vertically at the cost of losing horizontal scrolling (that's how SMB3 handles vertical levels, btw).
Can I just take a moment to point out that, rather than use game BGM like 99% of UA-cam channels dedicated to 'game analysis' you chose to keep it silent. I absolutely say that the silence helped me keep my attention on the explanation rather than on the game on screen.
Thanks!
It's a welcome break from UA-cam's overused tactic of using the game's visual and (or) auditive merits to cover for the (oftentimes lackluster) arguments presented in the video.
yikes, took me like 25 years to finally get it... thanks for showing this up!!
Why can't Mario 3 use vertical mirroring and write a 8 pixel MMC3 interrupt to the very top of the screen? The HUD covers the bottom area already. Boom, everything is masked
If you use vertical mirroring then we couldn't fly anymore?
Actually the problem you're facing here is how the HUD is drawn. In levels that scroll horizontally, the top-to-bottom vertical span goes from the top of the level to the bottom and then the last 4 rows are occupied by the HUD. With the way the HUD works, using your idea would require it to be completely overwritten with level background in the scanlines above it and then it would need to be entirely replaced at the scanline where it starts. There's just not enough CPU or PPU bandwidth to pull that off.
Of course if we were to simplify the HUD and draw it without using the nametables at all, at the expense of some of the very limited hardware sprite space, your idea might be workable.
Video came up in "Recommended", figured I'd see how accurate it was ;)
Just living up to her name
The MMC3 has a scanline interrupt feature, which means the interrupt can only ever be triggered at the end of a scanline (during horizontal blanking I believe)
duuuuuuuuude this video is awesome. If there's more like this I'm totally subscribing.