Mega Man 3's Graphical Glitches, the MMC3 Mapper, and a Bad Development Timeline - Behind the Code
ฝัง
- เผยแพร่เมื่อ 24 มิ.ย. 2024
- Why is there a flashing line above Shadow Man on the Stage Select screen? Why does the pause menu flicker? How do these NES graphics work, anyway? Let's find out!
If you would like to support this channel, here is a link to the Displaced Gamers Patreon page - / displacedgamers
Twitter: / displacedgamers
Facebook: / displacedgamers
Instagram: / displacedgamers
Music by:
/ hariboosx
/ @wolfandraven
#NES #Programming #megaman - เกม
Thanks for watching, everyone!
Here are a few notes:
1: The code changes were unoptimized in order to showcase how the order of PPU register writes on a single line can alter the results. I mentioned this in the video, but I didn't mention how the location of the Nametable used for the menu will change ($2600 instead of $2800) depending on the area of a stage/mirroring type used.
Fire up Spark Man's stage for an example of this. You'll start with vertical mirroring, so the menu has to be rendered on the "right side" of the Nametable viewer and is pulled from $26C0.
2: I originally had detailed information regarding what the PPU does after it hits dot 256 on a rendered scanline included in this video. I cut it for time. If you're a dev and already know the details, you already know the details. If you are new to the whole PPU timing thing, definitely review this on the nesdev wiki. I highly recommend starting with Mega Man 3 as a case study!
3: Regarding the highest bit being set to zero with the first write to Address register $2006, let me quote the current wiki entry (6/26/2024) from the Explanation section of the PPU Scrolling page for further elaboration as to why I said, "We don't know":
"$2006 is simply to set the VRAM address register. This is why the second write will immediately set v; it is expected you will immediately use this address to send data to the PPU via $2007. The PPU memory space is only 14 bits wide, but v has an extra bit that is used for scrolling only. The first write to $2006 will clear this extra bit (for reasons not known)."
4: A lot of people have been asking about a ROM patch containing these fixes. You may want to check out the "Mega Man 3 Improvement" patch here - www.romhacking.net/hacks/992/ Check out the readme file for not only a list of the work that has been done but also to see just how long the patch has received new improvements and revisions.
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
I like the description of polling vs. interrupts as "Are we there yet?" vs. "Excuse me for a moment."
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)
“You’ll notice the leftmost column in Mega Man 3 is always solid black.”
No, I truly did not notice. Thank you. 😂😐
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 🌏🗿👈🗿
There's so much that goes into all those random glitchy graphics in old NES games. At the time it just felt like the console being pushed to its limits, but it's interesting to see now that they could have been avoided with better understanding of the platform and time to fix all these weird issues.
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): th-cam.com/video/UleSwaVH1MY/w-d-xo.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.
there's something so beautiful about seeing the stage select scroll in perfectly
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 TH-cam 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
It's funny - I always noticed how, in MM3-6, when going through the pre-boss corridors, the left door was always cut off halfway, whereas in MM1 and 2 the left door was fully visible. Now I know why that is.
Learn something new every day.
Holy craps. As a kid I tried so hard to understand everything that was happening on screen, reasoning out game logic and whatnot, but somethings were just impossible to understand.
I love videos like these where I finally get answers to some of the really bizarre edge cases. Thank you for posting this.
I always thought it was just my cartridge glitching out due to poor pin connections.
24:55 - I wonder how satisfying it was to see the fix you implemented on real hardware at that moment. Fine work
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 stage select screen glitchy graphics always upset me as a kid because I thought my NES was malfunctioning. That said I didn't even notice the pause menu glitch until this video.... nor the other things you apologized for pointing out. Another excellent video and another quality explanation of how to fix things through thinking outside of the box.
EDIT: Come to think of it, some of the quirks of the CPU-PPU bridging are quite strange. I wonder just why it is that there's stuff like the "fine-y" top bit always being set to 0. Might be worth looking into at some point.
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.
are you a ppu register? cuz this video is a W
Oh this got me good. Thank you.
she be writing to my ppu til I w
Xmas 1990 my brother and I got Mega Man 3, and we loved the heck out of it! All six games are incredible; some of the best of the NES.
Fighting with the PPU like that feels more like a hardware bug workaround.
I love how this demystifies old games quirks. It's nice to see it working, only took 35 years to debug!
I like to think MMC means, Mega Man Chip.
I wish you had addressed this, but an early PAL version of this game has a HUGE graphical glitch with one of the Wily bosses. The floor will jitter up and down like crazy.
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 TH-cam 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.
All Master System games that scroll horizontally mask off that left side.
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.
Really awesome to have someone fill some of the void of assembly programming content here on youtube!
I love this channel and Retro Game Mechanics Explained for that very reason.
Dangerous Dave in Copyright Infringement, the prototype for what would become the first Commander Keen trilogy, had a similar effect as Mega Man 2's pause menu. Which is saying something when you're talking about a PC game!
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.
Great video! ❤
Has me wondering what the original devs think of these breakdowns and bug fixes. From what I understand, they didn’t have fancy emulators to debug their code and I can’t help but imagine how much better some things would be if they did have tools like what you use.
Love your content dude ❤❤❤
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.
Wow, that interleaved Address/Scroll write is batshit insane, but makes sense with your explanation of v/t (and considering the MMC3). This video is ostensibly about Mega Man 3, but really, it's an amazing overview of the PPU internal Registers! (And also about the debug features of Mesen. Developers would've killed for modern day tooling in the 80's, one can imagine what would've been possible)
Damnit now ill never be able to unsee this stuff when i play MM3!
I'm... sorry.
The SNES port fixes it so try that by infidelity
When i first got Mega Man 3, I thought my cartridge was messed up ha. Later found out, nope thats just how the game is. haha
I love that the love letter to the franchise created that franchise. I had Megaman 2 as a kid but only played MM3 a few times when my friends brought it over. So needless to say, I never exactly noticed the gliches. Flickering graphics was kind of the norm for NES games.
Still it's nice to see a video like this highlighting bugs I never knew existed and showing how they look fixed. It's very satisfying.
Regarding the topmost bit being set to 0, this is what the nesdev wiki has to say:
"Note that while the v register has 15 bits, the PPU memory space is only 14 bits wide. The highest bit is unused for access through $2007. "
Your video actually helped me fix a bug on my game! Thank you so much 😊
Awesome!
Oh, baby, we are back! I love your videos so much!
I'm surprised that with Nintendo's quality certification program, they didn't seem to have a problem with glitchy graphics.
I LOVE that you showed both the problem AND a solution! This is awesome!!
I always look forward to your videos! You always explain them in a way that is interesting and easy to understand
Thanks for pointing out several graphical oddities that I won't ever be able to unsee
(and great video)
Thrilled to see a new DG video! Love this stuff man.
I love this series, keep up the good work!
I love these explainers (and fixes!) for glitches for these ancient games. Thanks. 😊
Wonderful as always, thank you for the information that you give
I don’t know what you’re talking about, but I love to hear you say it.
I would be engrossed in a future discussion and manipulation of Shadowgate in which you break through the “door that can’t be opened” in the Well Room. I wrote to the Nintendo Power game counselors 34 years ago to satisfy my curiosity yet had no help from them.
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.
Mega Man 3 was a decent game, but Capcom REALLY should've given the developers a couple more months to iron out the bugs and graphical glitches
This is awesome. I love these deep-dives into the code to help the original classics play as intended! -- I played these games many times but never noticed just how funky some of it was!
Aaah this is very interesting!
My most extensive programming experience is on the Commodore 64, a system that has some scrolling support but it's implemented much differently than in the NES. On the C64, the whole screen can be shifted by a few pixels left, right, up or down within a range, but it doesn't officially support full-screen scrolling like the NES does. Instead, at the end of that thin scrolling range, the CPU must then copy _every byte_ over by one, and then shift the scrolling register back to the other end of its range. In fact, it would have to do this _twice_, since both characters and color data have to be moved. There isn't enough processor time in a single frame for this to happen, so on that machine cheats have to be used: only scroll part of the screen (one of the reasons why C64 games often have huge status areas), or don't copy video memory (requiring tiles in each row/column to use the same color data), or use an alternate page of screen data and flip to it (which can't be done with color memory so it has that same issue).
This system still uses the scrolling, so it doesn't have to laboriously shift every tile on the screen, but it still has very little time to add new tiles at the side of the screen. Most NES games, that I know of, that use vertical mirroring in horizontally-scrolling areas, have a lot more time to prepare the updated screen. I wonder if MM3 had to reduce the complexity of its levels to make them faster to copy into VRAM?
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.
My favorite disassembling TH-cam channel. 🥰
Man, I've been waiting for this since your tweet about it. So awesome. And also, thanks for apologizing for calling my attention to those things I'll never unsee.
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...?"
Excellent work as always!
Eventually your videos will be 5 minutes of new information and 10 minutes of references to existing videos 😆. Always exciting when a new video drops! Thanks!
It's always a good day when there's a new DG video about fixing Mega Man glitches.
This was a great one - definitely watch it over a few times to catch all the implications.
Amazing explanation and fix! Thanks for the video!
This is a super useful explanation of why the order and timing of the writes need to be juggled around, I'm learning how to code for the NES to do some split screen and raster effects and now have a much better understanding of what I'll need to do.
years waiting for this episode
Years wanting to make this episode!
This is my all time favorite TH-cam channel
10:39 I kind of learned this the hard way when I was working on some code that was supposed to update specific tiles when pressing left or right in my WIP MM1 mod. The screen would jump around for a single frame, making the graphics get more and more messed up each time left or right was pressed. I knew the order of what I was doing didn't really matter in that specific scenario, but I didn't know what was wrong. I spent some time looking at other code that was "talking" to the PPU and I quickly realised I mixed up the PPU addresses $2005 and $2006 in my code. Whoops.
Excellent work! 👏👏👏
excellent work! i believe fixing this is one of the reasons kuja killer released the megaman/rockman 3 improvement patch. though its scale has grown a lot since the original release 15 years or so since!
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.
Top notch work as always.
I am so thankful that you even corrected the sprite positions for the lower faces, I've seen a few hacks fix the overscan, but leave the face sprites the same... And it looks a bit off
Excellent Video! I love that you showed the fixed version on real hardware + a crt. I wonder what the original programmer(s) would think of this fix..
Love this channel!!!
I love these videos. I feel like I'm learning. But so much ofvit is over my head.
I've been waiting for this one. Heck yeah, boys, let's go!
18:45 Always room for a Talking Heads shoutout, I respect that.
Great video. 🎉
I never realized those little glitches were in every copy. I always thought my game was just a bit messed up lol
Thank you. I love learning how game bugs work.
Thank you so much for this video! This glitch was so annoying back in the day!
Awesome video; hope the engagement helps.
I wouldn't have minded an apology for drawing my attention to the nose above shadow man, too; because as obvious as that is here, a younger me on a CRT had no idea. =)
Me sitting in my recliner blowing my bubble pipe without a hope of understanding this. "Hmm.... indeed."
I always thought I had a bad cart pin or something because other games didn't seem to have these sorts of issues. It wasn't until I bought the megaman collection on steam where I realized it was all the copies were that way.
It needed a MMC3 chip to do what the 1982 Commodore 64 does from the factory :)
You should do some C64 code, too. It's cut from the same cloth, and full of neat tricks (and bugs) ❤
It's amazing how developers were able to make functioning games at all on these early platforms. Coding for them looks like a nightmare, or works of art, however you want to look at it. 😁
The Mega Man 2 menu thing is going to bug me now. Thanks a lot 😅
I'm... sorry.
Another fascinating video. It's also amazing to me how weird the fixed screens look to me. 😂
Ahhh thank you so much for this video
OH MY GOD THAT LEVEL SELECT LINE HAS ALWAYS INFURIATED ME THANK YOU 👏
This was dope. Mega Man 3 was one of my favorite games growing up. It's what I'm using now to figure out if I got my timing code correct for MMC3 interrupts in my emulator. I'm still at least a pixel off with the stage select screen. 😆 The top right pixel for the Magnet Man frame is occasionally white. The rest of the glitch lines up. It just starts glitching earlier than it should. Some day I'll get the whole PPU/CPU/Mapper timing thing down.
Impressive stuff man. Not sure I was able to follow this one completely though. I hope you're moonlighting doing ASM consultant work, as I think that could be lucrative. Cheers.
another behind the code, another good video, blessed be this day
i fucking adore your channel and i’m so excited.
AWESOME! 🍻
Now, on to those dreaded slowdowns in Contra Force 😎
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 😎
Thank you for making me understand the last holy grail of NES internal workings that I have never been able to crack just by reading the NESdev wiki: the PPU internal registers. I'll be sure to re-watch a few times to hammer it in better, but now I can see myself designing mid-frame scroll changing effects much better in future homebrew projects.
I definitely left out some of the finer points. It was one of those topics where we all have to read about it, read about it again, read about it again... to start committing stuff to memory and letting the lightbulb turn on.
@@DisplacedGamers It really goes to show that the PC-Engine is the NES on steroids and much more refined in its design. Everything is buffered so you don't have to care about the timings so much, it just "knows" to update the internal scroll registers on the next line. Not to mention that the VRAM remains accessible without penalties even while the screen is being drawn. You can just "pull the rug" from under the display's feet if you change the nametable as it's being drawn but it won't truly break anything like on the NES. Truly a shame that it never became a hit outside of Japan.
Huh, I never knew raster interrupts weren't part of the stock hardware. Most fascinating, thank you!
I was hoping you'd get around to tackle this one day. 😊
It was on my Behind the Code list for at least one year.
As simple as Nes/Famicom games look, they can be incredibly complex. I would say they were likely the most complicated console games of the 3rd generation. What's crazy is that we only saw 3 helper chips throughout the Nes's lifespan, but there were so many more.
I believe all major 3rd parties had their own chips they used to enhance Nes's capabilities. Did you know there was even an FM sound synthesis add-on just like Sega's Matk III and Master System? What really sucks is that because of Nintendo's strict policies on 3rd party distribution, we often got inferior games. In many ways, we really got hosed...
Fun Fact- Did you know some early Super Mario Brothers/Duck Hunt carts had Famicom to Nes converters inside of their cases? Nintendo didn't make enough Nes carts during the systems launch. So, they slapped Famicom carts in with a converter and sold them.
These mappers were used in licensed US-released games: Discrete Logic Chips (mapper numbers 2, 3, 7, 66, 34), MMC1, MMC2, MMC3, MMC5, Sunsoft FME-7, and Namco 108. I'd say that's more than 3 helper chips.
Gumshoe was the first US release to use a mapper, and it was mapper 66 (GNROM).
3 had some of my fave stages and bosses.
It was my first of many Mega Man games.
I was feeling nostalgic for MM3 and this was perfect timing!
Dude, you and Kaze64 are so entertaining to watch as you find solutions that 100% could have been done at the time.
This is excellent. I've always wondered about why Megaman 3's robot master select screen had a glitch. Understanding more about Megaman 3 was in development hell yet managed to still be a great game helps you appreciate the game even more. There's a ROM hack that fixes these bugs and adds some other features, like cycling the gained abilities with the otherwise unused Select button. I love Megaman 3!
Wake up babe new displaced gamer video!!!!!!!
I'd love to get into doing this. I have a course on 6502 on udemy. I'm just so tired of looking at code after work, though.
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've been meaning to tell you about the NES project I have most been interested in accomplishing -- making a mod for Mega Man III that makes it work with the VRC6 soundchip and using an encoding of RushJet1's MM3 soundtrack remaster. I think it's the most impressive NES soundtrack in existence and would be a dream to actually play the game with it
Game Genie a cheating device!? No, it is a patching device!
Fixing bugs, 3 bytes at the time!
So much code! It was great!
Cant believe i watched all this debugging, but it was so well done.
Imo, best MM soundtrack. Its got a special place in my heart, so im a sucker for it.
For me, as a whole, I still like 2 better, but it's dang close. MM3 was also the first game I bought with my own money IIRC.
It's interesting how Megaman3 used the masking feature and didn't experience the graphical tile bugs of scrolling the screen to the right. Just for the fancy UI on the bottom
Yet Super Mario Bros 3 did something similar and still suffered with tiles on the right side experiencing palette issues despite using the masking feature.
Speaking of Mario 3, I think they actually did something similar to fix the UI bug, you can see the graphical flicker near the upper left of the UI so it seems they were aware of hiding it so they hid it on the black border of the game's hud.
I think Kirby is perhaps the one that did a combination of both in this case, even with the game's vertical and horizontal scrolling iirc. Curious to know how that game accomplished such a task.
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.
It's ok that you made me notice these things :0
Back then in the 90s, I thought the emulator was crappy, but it was the game after all! What a revelation! 😱
OMG! I UNDERSTAND EVERYTHING!!!? I LOVE YOU DOOD! Thanks for this information!! ❤❤❤❤❤❤❤
I was just playing this game last week and always admire the rush job they had to do to even make such an amazing game. The soundtrack is possibly the best on the NES
MM3 was actually my first megaman game
i always thought that issue with the menu was just because i had a glitchy cartridge... because i got it from a random back alley 2nd hand store
all these years later... IT WAS THE GAME THE WHOLE TIME!?!? O.o
MOM! cancel dinner!
a new Displaced Gamers video just dropped!
...or breakfast, in my case. (8:00 AM CST)
*Likes video*
OK now time to watch it!
Always love seeing tiny glitch being fixed
6:24 "If you never noticed this before, I'm...sorry" 😂
The technique to split the vertical scroll with pixel precision is well-understood now, but during the NES's commercial lifespan I believe it was pretty much black magic. I don't think games started doing pixel-precise vertical splits until 1988 or so, quite a few years into the console's lifespan. Zelda, for example, only scrolled vertically in 8-pixel chunks.
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.