Mega Man 3's Graphical Glitches, the MMC3 Mapper, and a Bad Development Timeline - Behind the Code 

I know you said you cut some details for time, but I honestly would be absolutely delighted to hear you talk about this stuff for hours, maybe this could be worth a unscripted Talking Code video sometime? It would be a lot less stressful to make such a video and it would most likely be just as enjoyable as a fully scripted Behind the Code episode!

The patch actually does too much. It does not just fix bugs and objective designflaws, but it also makes changes that may not be desireable.

@@VinsCool I am happy you wrote this. I created Talkin' Code to be a more casual video series to produce as it takes so long to create an episode of Behind the Code. I had a few people state they liked the scripted stuff better after I released an episode or two, so I therefore made Talkin' Code mostly scripted... and then kinda abandoned it because it wasn't really unique. The game I am currently investigating might be more suited to a casual format. We'll see.

@@DisplacedGamers I'm excited to see what you are cooking up! I've been getting really serious with 6502 ASM lately and just a moment ago I figured out a way to exploit the BRK instruction to turn it very useful, it is so much fun when the Stack is at your mercy and obeys to your requests just like that haha!

Hello ipfan4491 - that's why i made a seperate text file of the "most common complaints" i gotten over many years. So i wrote a few things for people to un-do some changes they don't like

Graphical glitches are more often caused by poor code than "pushing limits". Lag is often what is considered "pushing limits", but is also occasionally attributed to poor code instead. Zelda 2 can be considered an example of poor code leading to lag; the Disk-version did relatively fine due to being optimized for loading data into an on-board cache, but was poorly optimized for bank-switched memory mapping in the Cartridge-version. DG highlighted this in this video (link starts 10:00 into the video): ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-UleSwaVH1MY.htmlsi=U3FtTJu55W8YjnV0&t=600 (but skip ahead to 11:00 if you only want to see the Event Viewer demonstration of the poor MMC-optimizations).

I think a lot of it also has to do with the way the source code was written and stored at the time. Today, source code is easily split into many files you can easily bounce to with special tools to highlight and shortcut a lot of code, that and the easy way to have a repository to view all changes to code as you move along. Back in the 80s, it wasn't like that. Although I don't fully know how their development was done, I know they didn't have pretty code and easily accessible files and repositories and shortcuts. Finding bugs and glitches was more than likely much, much harder. We take for granted how we can go and "fix" all these bugs today so easily to a person that knows how to. I give mad respect to all of these old school developers.

I get what you're saying, but anytime you're doing stuff with hardware that it was never intended to do in the first place it is basically pushing the limits in some respects.

@@Epic_C Absolutely. If we had to use 8-character variable and function names, all in one huge source file with no syntax highlighting, with every comment adding to assembly times which could already be a number of minutes every time the code changes, plus no internet to refer to when it goes wrong, I don't think there would be quite so many people still making games for NES, C64, 2600 and other retro systems, nor digging into 40-year-old bugs.

@@Epic_C My personal example of this is Famitracker - using this program, anyone can make NES music with a vibrant array of effects. But back in the day, if you wanted to make NES music the programmer had to write an engine and the composer had to either use the engine or had to write their music elsewhere and have it meticulously translated over. We could always make music this good but the lack of tooling made it way harder.

Ever play Alex Kidd in Miracle World for the Master System? You start in a vertical section going down before going into the water for a horizontal one. If you're playing on not a CRT, (or a CRT with minimal overscan) watch the left column when you descend into the water. Once the vertical scrolling stops, it blanks the column. The Master System's backgrounds aren't configurable like they are on the NES. It has extra memory for few extra vertical rows of tiles for vertical scrolling, but the ONLY way to do horizontal scrolling with tile refresh is the blanked column. Instead of always having it blanked, Sega opted to have it visible in vertical sections, but not horizontal ones.

Always has been 🌏🗿👈🗿

Oh this got me good. Thank you.

she be writing to my ppu til I w

Interesting. Is this an existing thing that can be done outside of the standard puzzle solving in the game, or did you just want to know what was behind the door. I don't recall the exact door you mentioned, however I have completed Shadowgate.

@@DisplacedGamers As far as I know it cannot be opened and is possibly only there as a red herring. So naturally I want to open it. :) I realize it’s a ludicrous request; I suppose I’m most curious if the game code includes a map layout and if there’s anything designated for that particular space. Shadowgate is an awesome game! Good to hear you’ve played and completed it!

Is it in the original Mac version too? Because my first guess is it is the vestigial remnant of an area that was removed for space.

@@CptJistuce I’m only familiar with the NES version because I was only playing text adventures on an old IBM; but it IS an interesting question! I might hunt down some more info to find out.

Look up the video "The Untold Stories of Shadowgate : The Most SECRET ROOM & MORE - Featuring Game Designer Dave Marsh" and jump to the timestamp 9:35. In the game's design documents there was going to be a puzzle there, but the developers ran out of disk space so it had to be scrapped. Rather than redesign finished rooms to remove doors to scrapped rooms, doors were left permanently locked.

In an industry where developers had some books and general knowledge that helped them travel the paved road for PC software development, id was the team that decided to go off-road.

Awesome! Thank you. I am glad it helps.

Thanks for that! I haven't dove into the C64 yet (and not sure if I ever will, because there's only so much time) but that's fascinating! IIRC, the MSX2 had a similar method of implementing horizontal scrolling. It's so cool to see that developers saw a feature where they can just jog the background by a tiny bit, and expand that into smooth scrolling! It also reminds me of how the SID chip was versatile, but was a bit choked by only having 3 channels. And so, developers worked around it by switching out the waveforms every frame, or arpeggiating, to make it all sound fuller. I remember playing some unlicensed Codemasters games on the NES, and was in awe of how good some of the music was (even if the games weren't always brilliant). They used their experience on machines like the C64 to squeeze more sound out of the 2A03 on the NES as well.

It would be nice to watch some videos about C64 coding/deep dives with games if they exist. I have had a C64 for a long time, but I have not developed on it. Re: Mega Man 3 - it only has to worry about copying a single column's worth of tiles to the Nametable during vertical blank. Aside from their required method of decompressing level data, I don't think much CPU time is required. Could probably get a cycle count before and after the level data read/VRAM write and use the values to track performance on that front. I assume it should be fairly consistent.

At least on the C64 you didn't have to wait for VBLANK to push pixels to the screen. That was a major pain in the ASM on the NES.

@senilyDeluxe That is true. On the other hand, I've learned that the C64 was designed around the VIC-II chip having access to memory ahead of the CPU so that it could build the screen in time for the raster beam, which meant it had to put the 6502 to sleep for like 10% of the time, a problem that the NES's design avoided. It's why the machine runs a little faster with the screen blanked.

@@rodneylives I’m no computer science major (I started learning assembly a few years ago on my own) but that’s crazy! I’m going to have to read about it all on my commutes the next few weeks.

There was a moment as I was writing the script when I thought, "oh man. What if people haven't noticed all this stuff before...?"

I want to say I read something about the DMC causing some issues with that, however I may be mistaken. Mario 3 is also interesting in that it has multidirectional scrolling. Grabbing the leaf power-up and taking off at an angle really opens up the level and adds some exploration to a Mario game. Lots of PPU manipulation and time critical work.

I know Kirby was able to avoid the palette issues by sacrificing both leftmost and rightmost columns. But here it seems that Mega Man II did with just the leftmost column all along. How? Since the palette information is per 16x16 block, it seems a real mystery why you wouldn't get issues when you only sacrifice 8 pixels of width.

Masking the left side of the screen also has another use: Sprites. Because sprites cannot be partially off the screen to the left (no negative X coordinates), you can have those sprites go behind the masked area instead.

Notably, Castlevania 3 didn't understand how to properly do vertical splits. When you're in a vertical-scrolling room, they have a large black area between the status bar and the main screen. Because they couldn't figure out how to change Fine Y, they just waited a different number of scanlines before performing the scroll, then enabled the background several scanlines later.

@@Dwedit Do you know if Ninja Gaiden 3 does vertical scrolling the same way as Castlevania 3? I remember Ninja Gaiden 3's scrolling being severely broken in early NES emulators (which didn't emulate either MMC5 or VRC6 so you couldn't even try to run CV3 on them)

@@alexjackson7929 Looks like it does! I see that it picks a different scanline to scroll at depending on scroll position.

​@@Dwedit Both Rad Racer games do their road rendering by writing to $2006/$2006/$2005, and the first $2006 write is always in the range $20-$2F (as if they were setting the address in order to *write* to the nametable). Because this method always sets the fine Y scroll to a fixed value of 2, only the middle two pixel rows of each tile of road graphics are usable, wasting a bunch of CHR and nametable space. I think the $2006/$2005/$2005/$2006 technique may not have been discovered at all until the modern homebrew era.

Because Capcom doesn't give a damn about stuff they put out. Instead of making better translations and/or fix bugs and glitches in these games, they just spit out emulators with atrocious scaling and a bunch of ROMs from the internet. The same thing applies to their other collections (the X ones being the most painfull example. Look no further than X4, X5, and especially X6. Translations in these games are so, so bad, and they didn't do anything about it). That's how you make a quick buck, and people still will eat it.

This. Links are always welcome. Especially these days with the most used search engine getting worse and worse.

I've definitely seen it! In fact, I have been name-dropping you in a few of my comments. Did you use a similar solution for fixing the glitch or do something different?

I dont really remember what I did exactly. But i fixed ALL of the game's scanline glitches except for only 1 i think. The giant metool battles in Doc Needleman level. I wasnt able to do that one but everything else i did fix. Stage select, pause menu, all the boss/mid boss ones, the game ending where megaman walking on the grass field.

There's still some glitchy looking stuff on the scanline above and below the middle section that's scrolling to the left while the other sections are scrolling to the right, even with his fixes. I assume he just didn't fix this since this wasn't mentioned at all in the video (or he didn't notice it). What I see are elongated horizontal cyan lines and some white pixels along the bottom border and some black pixels along the top border as things are scrolling. It's easy to see when using the < and > keys on the keyboard to navigate the video frame-by-frame and is discernible when watched in real-time.

@@Nicholas_Steel If you are referring to the fixed Stage Select screen scroll at the end, I don't see any glitches. You could change the lines for the IRQs if it doesn't split the frame in locations where you'd prefer it to split.

@@Nicholas_Steel Those aren't "glitches" so much as the image being split on the edges of the boss frames and leaving pixels behind during the scroll, and while I do agree you could clean it up to scroll on different pixels to look nicer I would definitely still call it "scrolling perfectly" (especially considering the issues the original has)

@@Blutzen Oh yes, the edits greatly improve the situation, there's no doubt about that.

@@DisplacedGamers Dunno if RU-vid will let me post an Imgur image, but I'm talking about this stuff. Edit: It filtered out the URL... the URL ends in a/d0alcsZ

Or Bil Herd just randomly unhooking telephone receivers asking if anyone is on the other end, especially when Certain People (TM) were in the room. People who were chip designers even though they apparently didn't know what interrupts were for. (the story about developing the Commodore 128 is a pretty fun read) (there's also that "pretty please" register you have to write *twice* to get the chip to do its job)

I always thought it was just my cartridge glitching out due to poor pin connections.

Many games on the NES that scrolled in both the X and Y axes also used this masking feature. Look at Kirby's Adventure or Super Mario Bros. 3.

It is possible someone in the community has investigated the fine y issue and knows why this happens, but they haven't updated the wiki on nesdev yet. Of course, it is also possible that it is just a flaw in the design of the hardware. There are several flaws in the Famicom/NES hardware (another being the DMC/Controller read bug, for example) that devs just have to work around in software.

@@DisplacedGamers Another one that silently plagues games is the Pulse channel sweep unit adder bug. If the sweep is not set to negate mode (increasing pitch and lowering the period) it will silence the pulse channels for all the notes from A-0 to A-1 cutting off the bottom octave, as the target period is continuously updated and if it lies outside the range of 0-7FF it will silence the channel to avoid rolling around the frequency range. Which is the case for the aforementioned notes, regardless of whether the sweep is enabled. So games that didn't know about this had to live with never using the lower range of the pulse channels.

It was a strange sense of calm in a place where I usually pair anxiety with a scowl.

@@DisplacedGamers As if a tiny piece of the universe has been corrected and put back into its proper place, yes?

@@DisplacedGamers Perfect!

The master system was somewhat better equipped for these things from the beginning, since it included a scanline counter, automatic stabilization of the top two tile rows for a HUD and some other things. Sadly the vertical resolution is much lower than on the NES so that's a big disadvantage, as well as being able to flip BG tiles, but not sprites.

@@vuurniacsquarewave5091 I'm pretty sure the Master System has no hardware vertical raster, so anything that scrolls up with a BG HUD can't be implemented properly. Ys I on SMS had a very plain looking HUD because of that.

@@solarflare9078 I believe it also has a solution for that, a vertical HUD mode that freezes a few tile columns on the right side is available.

Awesome!

Me too. Also, when I first put in Batman for the NES, I thought my game was messed up when I saw the intro to it. Batman would flash quickly and it would go dark and the music would stick for about 4 seconds. I took it out and blew on it, put it back in and it did the same thing. I later figured out that the game intro was meant to to that. 😂

The tile map in the ROM was incorrect. I changed a hex value for an empty tile to the one for the left side of the M. I didn't go into detail because the video was so long.

It blows my mind that I've played these games for so many years and despite the fact I already knew about the lag and scanline glitches of the menus, I have never noticed that single tile was missing and now this will haunt me forever lol Just another reason to hurry up writing my image to tilemap converter program where a precalculated lookup table is generated with all the necessary data specifically to avoid this kind of silly mistake!

I played Rockman growing up and don't recall seeing the graphical glitches mentioned in the video. I booted up the emulator and found indeed there's a missing R on the top right for Rockman, and a missing scan line in boss selection at the same spot of Mega Man 3. But there's no dithering line, so perhaps it is a bug introduced when localizing the game?

While they did have emulators, the features weren't as vast. More than that, however, the machines were a lot slower. Who knows - I may try to replicate an 80s dev environment for NES programming and make some videos on it at some point. My assumption is that devs that are good enough to crank out something like a Mega Man game would have squashed all of these bugs if they'd had more development time. Maybe there was a notepad that had scribbles on it like "fix menu bug" and "fix stage select screen bug," but that notepad was thrown in the trash decades ago... and the bugs were never fixed.

​@@DisplacedGamersThat notepad was probably put aside when they lost the finished Top Man stage due to outage and had to scramble to make a new one that ended up in the game.

​@@arciks11Boss AI. They lost Top Man's AI at basically the last second. As I understand it, they were supposed to be sending floppies to the ROM factory literally tomorrow when Top Man died, and they had one day to create a working boss. And that's why his pattern is so dead-simple. I really would like to see what he was supposed to do.

@@CptJistuceWait, is this real?! I looked it up but couldn’t find anything and this sounds really dang interesting.

@@SonicMaster519 It is 100% true unless I'm wildly misinformed.

Fixing bugs, 3 bytes at the time!

At the time, when we were very little kids playing MM3, my sisters and I never even noticed MM3 had these glitches. Our copy of Kid Icarus was always crashing and going fuzzy. A lot of our cartridges did this, so even though MM3 had these glitches in every copy, we just assumed that we had an iffy cartridge, bc that was so common for our collection of cartridges

Oof. That is tough. Relaxation between working hours is so important. I can certainly understand how 6502 would not be considered... "relaxing."

I feel the same way! My open source contributions are pretty few because my brain needs a break after eight hours.

I love this channel and Retro Game Mechanics Explained for that very reason.

Oh yeah, the Fake Wily battle had that weird floor thing. I always just ignored little glitches like that. To me, it was just a quirk of the game.

Whoa. I'll have to read about that or find a video of it.

@@DisplacedGamers As much as I'd like to link a video, it appears that RU-vid is automatically removing comments with links... A video that shows the bug in action has a CRT filter, so maybe try looking for that?

He's talking about that level where Wily is in a huge moving robot like thingy that moves its two legs one after the other where you have to slide under its body, and then the body comes down, trying to crush you. The body of course is on the background layer, so it has to move the entire screen y-wise and then at the right scan line it has to snap back to render the floor. IIRC playing the NTSC version on an emulator, that level had some 1-frame glitches every few seconds, which barely affected gameplay. They were noticeable as they moved the floor up like the height of the floor to the bottom of the screen, around 1/3 of the screen. The PAL version however was glitching wildly (on real hardware with a real MM3 cart) and was barely playable, glitching like crazy. Sometimes the floor would glitch up 1/3 of the screen, but sometimes 2/3, so two thirds of the -floor- screen were made of floor. It also had massive slowdown. My guess would be that the game logic with too much stuff on the screen would miss the interrupts (which you can disable which would happen unintentionally if you, like, place your entire game engine in NMI - not sure here), but the PAL NES has more raster time available per frame and more PPU Writable Time in the blanking period, so the PAL version should have less problems with slowdown. (at least that's what I've incorporated in my four player version of Bomberman - if it detects PAL, it pushes more updates to the screen. The game engine has no trouble running anyways as there isn't any complex gameplay going on, especially with no AI opponents). Damn it's almost 10 years since I last programmed for NES. I jumped to the Interton VC4000 family as it's quite niche and didn't have any homebrew before I hit the scene lol. (if you wanna see homebrew, check my channel, but before you jump to the conclusion that my games suck, check the rest of the console's library - the hardware sucks. Well actually my Flappy Bird totally sucks. Canabalt has a major bug that randomly makes the game crash right at the beginning but it only happens randomly on powerup and once it's gone, it's gone and I can't get it to happen on an emulator, Kaboom is kinda meh compared to the Atari version and the collision detection is... iffy. At least Tetris is solid, but graphically one of the lamest games on the system)

So... the bug is there in JP and US versions as a flickering line along the top of the ground. The timing changes for the european version apparently broke THE EVERLOVING HELL out of that bug so that when it was released (apparently untested), the ground flickered across the whole damn screen instead of just one line. Then they got lots of complaints and had to release a bugfix version that has the ground acting solid like it is supposed to.

I'm... sorry.

The SNES port fixes it so try that by infidelity

@@vacantseaofplanetsThere was an SNES port? Or do you mean Mega Man: The Wily Wars on the Sega Genesis?

And also probably completely rework Gamma and the Doc Robots. Seriously, you expect the Wood Man Doc Robot to be possible Buster Only?!

​@@SonicMaster519And all the Wily stages and bosses. After Doc Robots the game turns extremely easy outside of Wily Machine 3, and that definitely wasn't the intended design. They clearly ran out of time.

@@genyakozlov1316 Yeah, the latter half of Mega Man 3 needs serious reworking. The game was clearly rushed to oblivion.

Ha! Not a comp sci prof, but what a curriculum!

SMB3 has tall levels that are more than one screen tall. The video memory is arranged vertically, and contains the full height of the level, and the status bar together. Then there's no more video memory remaining to have clean scrolling when you scroll horizontally. But when the game needs to scroll vertically, nothing new has to be loaded in, because the full height of the level is always there.

kuja killer's patch kinda blew my mind. The amount of time invested in Mega Man III is legendary. What a great contribution to the community.

I'm... sorry.

Years wanting to make this episode!

I think that is just a matter of unoptimized code. It looks like people have overclocked the emulators as a workaround.

@@DisplacedGamers copy that, but even though, I'd still love to see you digging into it 😎

It would totally fit. It looks like they were probably changing things up quite a bit as development continued, and stuff was left behind and/or unoptimized.

Thank you!

I believe so.

Just thinking about what you said about the development cycle, what i described is a frivolous as hell set of features to be added while ignoring obvious and eye straining graphical glitches. Also if its a bug, that seems like a wild set of bugs and it would be interesting to see below the hood while its going on.

I think the official collections still have all the old bugs left in. I don't recall any changes.

The Mega Man Legacy Collection still features this bug. However, since the NES rom is just present in the exe of the game, a simple dll injection/patch could easily apply the fix there.

And would've made the console more expensive making it less accessible to consumers.

...or breakfast, in my case. (8:00 AM CST)

I don't have my fixes available as a romhack, however kuja killer's Mega Man 3 Improvement patch may have what you need.

@@DisplacedGamers Thank you! :)

They probably just didn't have time to optimize the code and tighten up the timings.

Modern emulators let you "overclock" the NES using a technique similar to how the Dendy works.

I believe a fix is available on romhacking. I don't know if they used the same code changes that I did, but it should get the job done.

Just added a link to a pinned comment if you would like to check it out.