The Nintendo Entertainment System's Loading Seam

[@Kraigon42]

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.

[@vink6163]

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.

[@ThePreciseClimber]

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

[@Kraigon42]

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

[@leavewe]

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 :)

[@flynntaggart8549]

you should watch some of john carmack's keynote talks at quakecon. super interesting

[@ImSquiggs]

This has bothered me for about 20 years now. It's such a relief to have this weight randomly lifted on a Wednesday morning.

[@l-l]

Squiggs 【Glitches - ROM Hacks - Speedruns】 Good to see you here. Love your videos btw.

[@ImSquiggs]

Woah, thanks friend! This is really cool to me. As a fairly tiny KZbinr, 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! :)

[@franzpattison]

Squiggs 【Glitches - ROM Hacks - Speedruns】 this comment thread caused me to look at your videos 😜

[@DSAhmed]

Yelling at strangers in a KZbin comment. get a life dude.@@JRPrestonIL

[@gez_4515]

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

[@PhantomBladesXI]

"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

[@SavageGreywolf]

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.

[@Snowfireblues]

@@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"

[@djflugel79]

Now I am wondering how Kirby did it better.

[@blunderbus2695]

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

[@josephD32]

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.

[@MythlyInari]

I read this as "Nintendo's Loading Scam" That would be a completely different video...

[@funninoriginal6054]

Same.

[@maksymillian]

I read it as the NES loading screen

[@torreywhiting5402]

I read it as Nintendo Loading seen

[@mortenera2294]

I read this as "Nintendo's virtual console scam"

[@frikkofrik]

ME TOO

[@MattyStoked]

Another brilliant upload. Even its most basic form, games development seemed like a real challenge.

[@ShaunDreclin]

The Game Show yeah devs today are spoiled, back in the day you had to work in machine code to make console games.

[@drewsebastino2889]

Shaun Dreclin Well, assembly, but yeah, you actually needed to know how the hardware worked.

[@NomoregoodnamesD8]

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.

[@NomoregoodnamesD8]

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

[@nekononiaow]

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.

[@goldenelfboots4595]

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.

[@JustWasted3HoursHere]

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!

[@EliaForce1984ita]

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

[@JustWasted3HoursHere]

Anyone else vote for this? ;)

[@absmustang]

This comment needs more votes!

[@saidnobodyever711]

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?

[@nappeywappey]

6 years later but he wrote a program that transforms NES data into after effects data

[@RinoaL]

I never noticed it because my TV cuts it off. lol

[@Rydian]

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.

[@MaddTheSane]

A lot of the monitors of the day were also CRT.

[@ConnorR.mp3]

@@MaddTheSane Monitors didn't overscan like TVs though

[@PabbyPabbles]

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

[@rooneye]

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.

[@ddud4966]

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.

[@IsoFrieze]

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.

[@DamianYerrick]

dotsarecool Kirby also scrolls more slowly because it has to maintain two copies of the nametable in VRAM.

[@boreaousx]

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?

[@HappyBeezerStudios]

Why should they prevent some of the visible screen area from displaying the game.

[@GamesFromSpace]

Possibly because glitches when scrolling vertically would have been more visible and distracting, since it's usually empty space.

[@Scar-wg4qc]

Dude, this editing is so slick and effective

[@koopakape]

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!

[@CaptainSouthbird]

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.

[@vuurniacsquarewave5091]

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.

[@OroborOSX11]

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.

[@ovencake523]

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

[@retrorobbyreviews]

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.

[@robintst]

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.

[@AlBeebe]

Wow. Im speechless. That was brilliant.

[@RoseWaltz]

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.

[@sarcasmo57]

My friend on at Valve says that Half Life 3 is delayed for this very reason.

[@harleyspeedthrust4013]

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.

[@among-us-99999]

HL3 will be released one week after the brexit.

[@akumati86]

Half life 3 is dead. Please stop spreading this joke.

[@harleyspeedthrust4013]

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

[@harleyspeedthrust4013]

@@TemporalDriver People don't usually believe me because of the meme, but it's coming.

[@hisham_hm]

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

[@DiThi]

I didn't notice it in the emulation era because... I played the SNES version instead.

[@coreblaster6809]

These graphics you've made makes understanding this so much easier. Thank you!

[@Daniel15au]

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

[@IsoFrieze]

Thank you!

[@YourNightmar3]

@dotsarecool huh?

[@IsoFrieze]

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.

[@HandreyAlex]

I'm pretty sure that "huh?" meant to be a confused expression since he didn't know that you were the uploader.

[@YourNightmar3]

HandreyAlex Thats right

[@bluecar5556]

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!

[@pepearown4968]

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.

[@marscaleb]

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.

[@cireza_]

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.

[@NicD]

I'm sure you get this all the time but THE CHANNEL JINGLE AT 0:13 IS GENIUS!

[@daffers2345]

Here, this will make it even cooler: kzbin.info/www/bejne/aIerqoarlM-Uhtk

[@MattMcIrvin]

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.

[@sarysa]

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.

[@Dargonhuman]

Right? I thought either the emulator or the ROM file were corrupt the first time I notices that.

[@LonelySpaceDetective]

It's nice that emulators nowadays offer configurable cropping of the game display to "emulate" overscan.

[@FunkyFranky80]

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!

[@grasonhumphrey4053]

Great video, always wondered why that happened. Keep explaining!

[@AntZen85]

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!

[@IIFrozenFlame]

Gosh, the production quality of this channel has been amazing ever since apparently. Glad to have found this

[@Avagadro22]

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?

[@iau]

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.

[@ddud4966]

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.

[@ddud4966]

They're mirrored because the memory address lines are all wired into the same place on the circuit board.

[@Hapasan808]

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.

[@renakunisaki]

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.

[@TheNoSwearGuy]

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.

[@RebornAudio]

The intro jingle never gets old.

[@andrewaldrich3602]

These videos are really interesting. Please do more!

[@chemicalhorre]

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!

[@DeniseNepraunig]

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!

[@MiddleClasshole77]

I've needed this channel for so long, so happy to find it

[@focusontheidea159]

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?

[@KuraIthys]

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

[@saanait0]

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.

[@gtaiiilc]

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!

[@johnarmstrong5474]

I just love the thought and quality of your content. Thanks for putting in the hours to make these.

[@Supertimegamingify]

Your visuals are so detailed and perfect, thank you.

[@DavidWonn]

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.

[@VoidHalo]

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

[@MadInu8]

Your channel deserves more subscribers, it's always so interesting and well explained :D

[@The90sGamingGuy]

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!

[@randomcatdude]

The 3DS version just an NES emulator running a ROM of SMB3, so that bug will stay there

[@eduantech]

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.

[@MonkeyBscts]

I love videos like this that actually explain why stuff like this happens in detail instead of just pointing it out. now subscribed!

[@psmith2403]

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!

[@paulgraves1392]

This is an awesome and insightful look into the rendering behind NES games. Subbed.

[@marscaleb]

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.

[@python-b5]

these videos are obscenely high quality

[@lordofthecats6397]

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!

[@Snowfireblues]

Can I just take a moment to point out that, rather than use game BGM like 99% of KZbin 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 KZbin's overused tactic of using the game's visual and (or) auditive merits to cover for the (oftentimes lackluster) arguments presented in the video.

[@peytonbarrett5372]

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

[@KrunchyTheClown78]

That is pretty mindblowing. I always wondered why that was, now I know!

[@psivewri]

Great video! Very informative!

[@Jademalo]

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.

[@CAHSR2020]

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.

[@azraelcorvo9087]

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.

[@matthewstone2545]

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!

[@a2pha]

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.

[@selforganisation]

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

[@InsaneFirebat]

Nice work! I love having video game bugs explained in detail.

[@muizzsiddique]

Found this in my recommended. Was very pleased to have watched this video.

[@maximeeuziere]

Hi! I just realized SMB3 does NOT use 4-screen nametables (with 2Kb of VRAM provided by the cartridge), and actually only a handful of commercial games do that. But imagine if it did, in this case, the seams could be anywhere off-screen, and there wouldn't be any glitches, right? Other question: could SMB3 have avoided the palette glitches by rewriting the rightmost attribute in the middle of a scanline, and resetting it to fit the leftmost tiles during HBlank? Other question: what does Kirby's Adventure does better exactly? I can't see what it is from the small clip shown at 3:30 ...

[@cst1229]

KA probably does it better by moving the seam a bit to be slightly to the right of the masked column, since that isn't rendered anyways.

[@marscaleb]

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!

[@Lambby]

cool video Retro Game Mechanics Explained™

[@totallynotjeff7748]

Lambby yeah

[@master3243]

Great video. Slick animation, nice explanation, and high quality. Keep it up.

[@JAGtheTrekkieGEMINI1701]

Very deep explanation of a typical NES Game "Anomaly".... Thanks

[@Vodotix]

Your editing is epic!

[@briantimkennedy357]

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.

[@khmr33]

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!

[@parker_aug2]

Great vid! Glitchy edges are definitely worth it for the ability to fly in SMB3.

[@poofytoo]

This video is amazing, you deserve far more subscribers and views

[@niaschim]

To those watching my playlist: I know this is about the NES, not the genesis, but it is indirectly about the genesis, since they were both designed to output graphics through the same display medium Skip to 3:41, to observe the shared problem between them ("overscan") (overscan was expected by the developers/designers, plus, most TVs were more square-shaped back then)

[@hobbified]

My first thought was, you do a lot more horizontal scrolling than vertical scrolling on almost every level, so why not use vertical mirroring so that the horizontal scrolling is smooth, and vertical scrolling is glitchy? But I think the answer is, because of the status bar at the bottom of the screen. You can't have vertical mirroring, and vertical smooth scrolling, *and* a status bar, without totally screwing things up.

[@IsoFrieze]

With vertical mirroring, a horizontal status bar would be mirrored as well. And a vertical status bar on the left or right edge of the screen wouldn't be possible.

[@filanfyretracker]

"Cut off by the overscan" its amazing how many things exploited overscan and not just in gaming.

[@michaelberg9348]

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)

[@RGMechEx]

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!

[@Gooman130]

Very cool and clear explanation. Something I'd noticed but never thought about!

[@KazoWAR]

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

[@MarioFanGamer659]

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

[@heavysystemsinc.]

These 'seams' were seen a lot less frequently on the hardware it was intended for: A CRT. The seams frequently ended up in the overscan areas of the television, hidden by the bezel. Emulators of all kinds reveal a lot of 'under the hood' programming tricks because you're seeing more of the screen than you're supposed to. The original NES on a CRT has unknown but usually there coverup on the top, left, right and bottom most tiles. Therefore, game designers try to not put anything important there. You'll notice no game has score or information on these areas of any game in the library specifically for this reason. On most televisions, the 'seam' on SMB3 is absolutely hidden.

[@FawadBilgrami]

This is some original work on KZbin. Subbed

[@cubecast1]

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

[@izicial7469]

If you use vertical mirroring then we couldn't fly anymore?

[@CaptainSouthbird]

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.

[@CaptainSouthbird]

Video came up in "Recommended", figured I'd see how accurate it was ;)

[@CaptainSouthbird]

Just living up to her name

[@vuurniacsquarewave5091]

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)

[@sa3270]

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.

[@marscaleb]

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.

[@MarioMarioPlushGUY]

I always thought my copy was damaged or something. This is a very interesting and well done video! 🙏

[@DangerWrap]

I always thinking of this glitchy graphic especially in the Ice fortress in World 6.

[@retropulse03]

duuuuuuuuude this video is awesome. If there's more like this I'm totally subscribing.

[@garbageyoutubechannel310]

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.

[@qud3913]

Thanks, I needed this before I sleep

[@Mepholar]

Enjoyed the vid. Well put together. Looking forward to more.

[@SatoshiMatrix1]

I have a question. What is that solid vertical bar seen on the left of the screen of most NES games? Take for example, the six Megaman games. All of them have horizontal scrolling and essentially use the same engine, but only Megaman 1 and 2 show the entire display while 3-6 all use a leftmost line that obscures part of the image. Why?

[@IsoFrieze]

I checked Megaman 3, and it uses horizontal mirroring during horizontal scrolling sections because of the menu. The way the menu is implemented requires horizontal mirroring, or else either the menu would have to be shown at all times, or it can only move up and down in increments of 8 pixels.

[@milesklub4494]

Very well visually represented. good work.

[@pieternaude1469]

OMYGOSH thank you I had been agonizing over what that was for years! However, you did gloss over a crucial detail in the beginning there Mr Narrator... SO WHY ARE TWO OF THE FOUR NAME TABLES MIRRORED/IDENTICAL? Well, our buddy Mario only needs two name tables to make his adventure unfold seamlessly on our old CRT screens (for the first and second game at least). The option of four was there because maybe Nintendo knew they would make something like SMB3 in the future, so they left the possibility open. So what to do with the other two then in the mean time? Leave them blank? HELL NO. The NES will ALWAYS access the four name tables. If you left one or two of the four blank, the software will hit a 'missing file' error, causing your game to crash (unless you told it what to do, which is NOT very economical in terms of processing power). So do you just put a single coloured pixel grid in there? You could, but your NES's resources are far too valuable because it would actually have to draw that colour, even if it was just black. You would be spending what was already very slim resources on drawing nothing essentially, thus limiting what you were showing on screen even further. The solution? Just design the cartridge to send out pixel data in two, parallel lanes. The same amount of rendering time, double the results. Besides, the player never actually has to see or have access to the other two name tables. We have been playing two games at once for most of our childhoods without even knowing it ladies and gentlemen! THAT is why they are mirrored. Otherwise, thanks for the top-notch video! Great to have it explained in such demonstrative detail.

[@animeking1357]

I'm here after Implantgames suggested this video. Quite the thorough explanation.

[@lev7509]

3:50 "each 2x2 square has to be the same color" no, because there are 4 palettes, 2 bits to reference one. yes, there is only one byte per one 2x2 square, but since we need only 2 bits to encode one palette number, and we have 4 tiles within such a square, 2 times 4 is exactly 8 bits. I even checked with a NES emulator (FCEUX), and I can have different palettes per tiles. Link to wiki: wiki.nesdev.com/w/index.php/PPU_attribute_tables

[@nofatchxplzthx]

i mean i always figured it was because it was loading the next part of the screen but never really cared about the details