Mega Man 4 and MMC3 - NESdev BBS

Mega Man 4 and MMC3
by anwerman on 2010-06-17 (#63059)

Hello everyone,

I joined up because I've been researching up on how the NES works. I never really appreciated the hardware before, but now that I've been reading up on the system, I'm really impressed by how it works.

Anyway, I know that with various mappers, you can extend the capabilities of the Nintendo. And I'm really stumped at how Capcom implemented the scrolling features found in Mega Man 4, specifically Dustman's stage.

http://www.youtube.com/watch?v=VRVSWJsKsck (Starts around 1:45)

Looking at the nametable viewers in FCEUX, I can see that the moving pillars is just the background being scrolled. However, the bottom of the screen is fixed.

From what I've read up, I'm assuming that an IRQ interrupt is being called and thus is causing the CPU/PPU to draw a different part of the nametable.

What I don't get is how the collision detection works. So, my best guess is that up until the IRQ interrupt, Mega Man's collision detection hitpoints look up X + OffsetX, Y + OffsetY, and after the IRQ interrupt, OffsetX and OffsetY change to different locations within the nametable. OffsetX and Y would also be used to determine what tiles to draw onto the screen.

In a dumbed down sense, is this how Mega Man 4 with the MMC3 mapper work?

by tokumaru on 2010-06-17 (#63061)

I haven't studied this game in particular, but ideally, collision detection should not be directly related to graphics. Well coded games have a clear separation between the simulated world and what's displayed on the screen, the latter being a mere visual representation of the former.

The graphical part is probably done, like you said, through an IRQ firing right before the scanline where the floor must be, at which point the vertical scroll is modified to display the proper name table section. This is a common technique used in several games, not only for effects like this but also for status bars and such.

About the logical part, it would make sense if the moving pillars and blocks were treated as objects in the code, and like any game object they can move around. But I can't know for sure since I haven't studied the game's code.

What I mean is that the name table is not (or shouldn't be) used for collision detection. The name tables are only used to display graphical representations of levels and/or objects that are modeled as the game's programmer sees fit somewhere else in ROM and/or RAM.

by anwerman on 2010-06-17 (#63062)

"What I mean is that the name table is not (or shouldn't be) used for collision detection. "

Ok, I was reading up on the article on "Making M.C. Kids"
http://games.greggman.com/game/programming_m_c__kids/

The data in that game specifically is based off of 16x16 blocks, of 4 tiles each, and block holding a number that contains data about which tile is which and the collision detection routine.

So that although the nametables only display what should be drawn, that data that determines what goes on the nametable needs to come from somewere. Wouldn't there be linked memory banks that would hold block/tile data (e.g., solid, nonsolid, which tiles, etc.) And much like nametables, the game would stream in level data into approperiate level table as necessary? E.g., whenever a column gets updated in the nametable, a similar table gets updated with new pieces of level data that reference whehter a block/tile is solid, an enemy, etc. That the game only interacts with a screenful of objects and tile data at a time?

Like I said, I'm a novice on the NES and the system. But from what I've noticed, it seems that the nametables is just a graphical representation of what data the game is interacting with behind the scenes. And I could be way wrong on this hahaha.

by Dwedit on 2010-06-17 (#63063)

The crushing ceiling that moves up and down is just vertical scrolling, then after a certain point, it changes a nonscrolling floor.

It uses the IRQ feature of the MMC3 so it knows at what time to change the scrolling location to the floor. It's not absolutely necessary to have an MMC3 to do this effect, but that chip makes it a lot easier.
It's basically the same as any other game with a status bar positioned on the bottom that scrolls independently of the playfield.

by tokumaru on 2010-06-17 (#63064)

How games store their maps internally varies greatly from game to game, but to me it seems unlikely that any programmer would make a moving area (pillars) and a static area (floor) parts of the same map.

I know that I, as a programmer, would treat them as different things, even though both get rendered to the same name tables (because the NES has only 1 background plane), in order to facilitate interaction of the player with both, which would otherwise be tricky as you detailed in your first post.

by anwerman on 2010-06-17 (#63066)

Ok, that makes sense. Different things.
I've just always wondered how old games just did this type of stuff, as I too am a programmer.

I'm actually just working within C# on an 'emulator' type system where I can develop a game that would marginally look like an NES game and I'm just tryin to figure out how the old games did stuff.

... and as a programmer I hate 'special cases' when it comes to programming hahahaha.

So your best bet is that this stage is actually two maps layered ontop of each other then, with one just being offset from the other? The only thing that I can think of that could argue this point would be that when Mega Man scrolls onto and off of the screen, the pillars move to the top of the screen in a fixed position .e.g, no IRQ offset being used at that point.

Who knows. All I can really say is that I need to experiment with this; Capcom's programmers were paid to screw around with this stuff, I'm just doin it for free

And thank you for your help.

by tokumaru on 2010-06-18 (#63067)

anwerman wrote:
I'm actually just working within C# on an 'emulator' type system where I can develop a game that would marginally look like an NES game and I'm just tryin to figure out how the old games did stuff.

I see... You have a framework with graphical limitations similar to those of the NES, right? These kinds of raster effects might not translate well from the NES to such an environment, because they require perfect synchronization to the screen's refresh rate, so that modifications to PPU parameters are made as specific scanlines are rendered. So for this kind of effect you'd probably have to simulate this scanline-by-scanline rendering (no need to work pixel-by-pixel I guess).

Quote:
So your best bet is that this stage is actually two maps layered ontop of each other then, with one just being offset from the other?

Without looking at the game's code, that would be my best guess, and how I would implement it myself. The NES has only 1 background plane, but if I cleanly split it in the middle I can pretend I have 2 and use raster effects to move them independently. In the code, the maps would be separate entities and the main character would be offset differently to each map, and I'd test for collisions with both of them.

Quote:
The only thing that I can think of that could argue this point would be that when Mega Man scrolls onto and off of the screen, the pillars move to the top of the screen in a fixed position .e.g, no IRQ offset being used at that point.

I don't see how that invalidates the idea... When Mega Man enters and exits the "special effects" area there seems to be some "snapping" of the pillars, so there most likely is something going on to properly position them.

IIRC, MM4 tries to simulate single-screen mirroring (meaning that all the action happens in a single name table at a time) by constantly switching mirroring types, so maybe it's using one of the name tables for the "special effects" section and the other for regular sections, and switching between the two at will. There are a number of ways to deal with this.

Quote:
And thank you for your help.

Don't mention it. I'm just sharing my opinions. =)

by Wave on 2010-06-18 (#63068)

Megaman 3-6 uses 1 nametable for the "playfield" and another for the menu.
When you scroll vertically, it changes mirroring and uses the same nametable to do scrolling, then resets mirroring again.

by Bregalad on 2010-06-18 (#63069)

If I were to implement this in my game, I'd do the pillar as an object, and have it's collision detection routine crush anything that would contact with them (since no object will ever be above the pillars).
Of course the routine would "tell" the main engine to handle the IRQ and vertical scroll split.

The hard part is where they have destroyable blocks that scrolls with the pillar. I don't know how they implemented this, but it sounds like a headache ! Handling each block as an individual object sounds like it would be slow as hell, and I can't come with anything else in my mind.

Anyways you're sure that the collision detection doesn't "change on a scanline based timing" like vertical scrolling does, it doesn't make any sense.

by tepples on 2010-06-18 (#63070)

tokumaru wrote:
So for this kind of effect you'd probably have to simulate this scanline-by-scanline rendering (no need to work pixel-by-pixel I guess).

Likewise, for one of my PC games, I simulated something similar to Mode 7 of Super NES with HDMA (automatic raster effect system that the Super NES provides). The framework came in handy when I revamped it on Game Boy Advance, as I could just reimplement that framework to fix the screen height to 160 and use the GBA's counterpart to Mode 7 and HDMA. (It only looks like a total rewrite because I changed the menu entirely and carefully used lower-precision math for speed on a 16 MHz CPU.)

That said, in the Mega Man level, I'd represent the plane with the pillars and debris blocks as The Level, and the floor as a platform that moves up and down. Compare the Boss Bass levels of Super Mario Bros. 3.

by tokumaru on 2010-06-18 (#63071)

tepples wrote:
I'd represent the plane with the pillars and debris blocks as The Level, and the floor as a platform that moves up and down.

Indeed, that would be much simpler, seeing as the floor is just a flat surface. You would have to be careful to not screw up things on the physics side though... jumping from a moving platform usually isn't the same as jumping from a static surface.

by tepples on 2010-06-18 (#63072)

tokumaru wrote:
You would have to be careful to not screw up things on the physics side though... jumping from a moving platform usually isn't the same as jumping from a static surface.

Yes. Way too many games get this wrong: the initial velocity should be based on that of the platform that a character is standing on.

by Dwedit on 2010-06-18 (#63073)

Reminds me of two games that really contrast as how they did moving platforms.

In Castlevania 2, there are blocks which bob up and down. If you jump while they are moving down, you jump much lower than if you jump while they move upward.

In Megaman 1, your Y veolcity keeps increasing as you stand on a moving platform, and you are just repositioned onto the platform each frame. Just watch how in gutsman's stage, you instantly fall down at a very high speed when you fall off the platforms. Compare how fast you fall if you've recently jumped or not.

by psycopathicteen on 2010-06-18 (#63074)

If the Snes had more than 2 hardware background layers, why was 2nd layer collision used way more on the Nes?

by anwerman on 2010-06-18 (#63084)

I just looked at the nametable viewer for the Big Bass levels of SMB3 and they did the same trick that Capcom did as well. The Y offset of the nametables moves, causing it to appear like the stage is moving up and down.

For the Mega Man scenario, the only solution I could come up with is that if there's a collision detection point above the scaline, add to it the Y' value's offset and have it test with the map for a collision. If the point isn't keep it the same.

Egad. These people were geniouses who did this

by Disch on 2010-06-18 (#63090)

anwerman wrote:
Egad. These people were geniouses who did this

It's not really all that impressive, IMO. >_>

As far as raster tricks go, it's about as simple as they get.

by tokumaru on 2010-06-18 (#63091)

Since I'm pretty stubborn I went and checked that section of Mega Man 4. The effect is pretty poor if you ask me. In the YouTube video, when MegaMan leaves that area the crushers suffer a slight snapping when they stop moving, because at the time that happened they were close to their original position, but by playing you can see that no matter their position when you leave that area (I saved a state before leaving and and left several times with the crushers in different positions), they simply "pop" back to their original position at the top. It's a very unpleasant effect IMO, indicating that the coding behind it isn't polished at all. Personally, I'd be ashamed to release something that looks like that, but Capcom did anyway.

Also, by looking at the name tables I could see that although the game usually uses one of them for gameplay and the other one for the menu, it uses the one with the menu to draw the top of the crushers, so that they can scroll in from the top of the screen.

by anwerman on 2010-06-18 (#63095)

I actually like that effect hahahaha.

I'm also a bad programmer. Lol.
So I'm still stumped on how they enabled collisions though. Does anyone know how they did it in the SMB3 Big Bass levels, since that would be a similar effect?

by MottZilla on 2010-06-18 (#63097)

Dwedit wrote:
In Megaman 1, your Y veolcity keeps increasing as you stand on a moving platform, and you are just repositioned onto the platform each frame. Just watch how in gutsman's stage, you instantly fall down at a very high speed when you fall off the platforms. Compare how fast you fall if you've recently jumped or not.

Mega Man 1 always bothered me when I noticed that super fast fall off the platforms. I never thought about why this behavior existed but that makes perfect sense. I think Castlevania 1 and perhaps others have you dropping like a rock if you walk off the edge of a platform. It looks pretty bad when you step off the edge and instantly reach terminal velocity...

by tepples on 2010-06-19 (#63105)

anwerman wrote:
So I'm still stumped on how they enabled collisions though. Does anyone know how they did it in the SMB3 Big Bass levels, since that would be a similar effect?

Tides.

SMB3 has levels up to 27 metatiles tall (except in the case of "tall" levels), and levels can be set to autoscroll. The Boss Bass levels enable autoscroll only on the Y coordinate. So the level is just moving up and down, and the height of the water line (a value that I'll call tide_height) changes depending on the autoscroll state. The only thing that changes is the code testing collision with water, which uses tide_height.

by Memblers on 2010-06-19 (#63116)

psycopathicteen wrote:
If the Snes had more than 2 hardware background layers, why was 2nd layer collision used way more on the Nes?

Care to rephrase that? I'm not sure what you mean by 2nd-layer collision. I think most collision setups would be virtually identical between NES and SNES.

by tokumaru on 2010-06-19 (#63121)

Maybe he meant that even though the NES doesn't have a second layer in hardware it had more games that interacted with a simulated second layer than the SNES had with actual second layers.

I don't know if this is true though. I get the impression that most of the time, fake scrolling planes on the NES are pure eyecandy and have nothing to do with gameplay.

by Dwedit on 2010-06-19 (#63125)

Little Nemo, and Tiny Toon Adventures 2 both use full collision dectection on a split scrolling level.

Also, don't underestimate the number of SNES or GBA games which use raster effects to split a background layer into multiple parts.

by tokumaru on 2010-06-19 (#63128)

Dwedit wrote:
Little Nemo, and Tiny Toon Adventures 2 both use full collision dectection on a split scrolling level.

Bucky O'Hare can be pretty extreme at simulating multiple background layers too. There are no raster effects in this particular area, just clever name table layout/updates and sprite spikes. There are many other multi-layer areas throughout the game, both with interactive second layers and without. Everyone should check it out.

Quote:
Also, don't underestimate the number of SNES or GBA games which use raster effects to split a background layer into multiple parts.

Don't forget the Genesis/MD.

by Wave on 2010-06-20 (#63135)

tokumaru wrote:
Dwedit wrote:
Little Nemo, and Tiny Toon Adventures 2 both use full collision dectection on a split scrolling level.

Bucky O'Hare can be pretty extreme at simulating multiple background layers too. There are no raster effects in this particular area, just clever name table layout/updates and sprite spikes. There are many other multi-layer areas throughout the game, both with interactive second layers and without. Everyone should check it out.

Quote:
Also, don't underestimate the number of SNES or GBA games which use raster effects to split a background layer into multiple parts.

Don't forget the Genesis/MD.

I think Bucky O'Hare is the game that pushes nes graphic tricks to the limit.

by tokumaru on 2010-06-20 (#63164)

Wave wrote:
I think Bucky O'Hare is the game that pushes nes graphic tricks to the limit.

I think it's pretty amazing. Sometimes I miss simultaneous vertical and horizontal scrolling though (so that levels would feel less constrained). I don't think the game has any areas like this.

by psycopathicteen on 2010-06-20 (#63166)

That looks like an interesting trick in Buck O'Hare. Is the background layer on the right the real background, while the layer on the left the fake? I think they used spiked sprites to cover up scrolling glitches.

by tokumaru on 2010-06-20 (#63168)

psycopathicteen wrote:
Is the background layer on the right the real background, while the layer on the left the fake?

I don't know what exactly you mean by "real" and "fake", but the one on the right is pretty detailed, while one on the left simply uses patterns that repeat horizontally. This makes it easy to move that layer, which is done by rewriting just the rightmost tile of each row (with metal tiles to make it move right and background tiles to make it move left). The fact that the background repeats itself horizontally helps too.

Quote:
I think they used spiked sprites to cover up scrolling glitches.

Yes. The background "scrolls" 8 pixels at a time, leaving attribute glitches every other step. The sprites are used to cover these color glitches.

Also, since steps of 8 pixels aren't very smooth, they made it look like the "layers" are moving 4 pixels each, in opposite directions. This looks smoother than if one of the "layers" was static, even though technically they're still moving a total of 8 pixels away from each other. Since the background repeats horizontally every 8 pixels, they use CHR bankswitching to offset it by 4 pixels every other step to make it look still.

It's a pretty interesting effect that doesn't even require special mapper features, which means you could do that even with no mapper at all. Even though it uses bankswitching for the background, you could achieve the same effect with CHR-RAM (the whole background uses only 4 tiles I think) or make the background pattern repeat every 4 pixels and not bankswitch at all.

This effect would probably work vertically as well, you'd just have to be careful about the sprites that hide attribute glitches, not aligning more than 8 of them.

by Bregalad on 2010-06-21 (#63178)

Yeah I guess Bucky o Hare use amazing tricks like that. However, I don't like the game-play of this game very much, it feels rushed to me.

That being said, it looks amazing to us because we know what the NES is capable and that the game does a lot of thing the NES "should" not be able to do, but to some random retro gamer I don't think it would be amazed as we are.

I like the "background repeat each n pixels" trick. I plan to use that in my game to have a huge boss moving on a non-black background :p
A black background is a particular case of a background that repeats each pixel in both directions by the way.

by tokumaru on 2010-06-21 (#63199)

Bregalad wrote:
That being said, it looks amazing to us because we know what the NES is capable and that the game does a lot of thing the NES "should" not be able to do, but to some random retro gamer I don't think it would be amazed as we are.

True. In fact, even the guy that's reviewing/playing it in the video I linked to says that "the graphics aren't groundbreaking, but they are more than adequate". I'm definitely more impressed by the graphics than he is, probably because I'm terribly familiar with the limitations of the system.

Quote:
I like the "background repeat each n pixels" trick. I plan to use that in my game to have a huge boss moving on a non-black background :p

You'll have to watch out for attribute glitches in the areas where the boss meets the background... You can of course add some details and hide glitches with sprites, like Bucky O'Hare does. Or make very chunky, square bosses... =)

Quote:
A black background is a particular case of a background that repeats each pixel in both directions by the way.

That's true.

I think I find these simple tricks more clever and interesting than common raster effects that require mappers. I mean, a trick like this doesn't do anything weird like messing with the display as it renders, it's just well though background layout and VRAM updating, it's awesome.

by Smallhacker on 2010-06-25 (#63344)

tepples wrote:
SMB3 has levels up to 27 metatiles tall

(Please excuse some slight off-topicness)

Hey, I recognize that number! That's how high vertical levels are in Super Mario World. I've always found that choice quite odd, seeing as it's such an uneven number and makes X/Y coordinate to RAM address calculations less efficient.

...and now you tell me that SMB3 has the same odd level height?

Why? What's so special about the number 27? Did they pick a random number and simply decided to stick with it, or is there some brilliant reason I'm missing here?

by tokumaru on 2010-06-25 (#63345)

Smallhacker wrote:
Why? What's so special about the number 27? Did they pick a random number and simply decided to stick with it, or is there some brilliant reason I'm missing here?

The NES has 2 name tables, and each one is 30 tiles (240 pixels) tall. In SMB3 they are arranged one on top of the other for a total of 60 tiles. The bottommost 6 rows are used for the status bar, which means that 54 are free for the level, enough for 27 metatiles.

On the SNES I'm not sure. I don't think background maps are 30 tiles tall on the SNES, so I see no reason for them to stick with that limitation. Maybe that game was built on top of SM3, and they simply never changed that aspect of the engine.

by tepples on 2010-06-25 (#63347)

Early prototypes of SMW apparently resembled SMB3. I imagine that development started by porting its engine to the Super NES.

by RushJet1 on 2010-07-01 (#63541)

Back on the subject of MM4 and split scrolling, why does the area to the right flicker a lot on the border of the two scrolling areas? Mega Man 3 did this a ton too. Mega Man 6 on the other hand,

http://www.youtube.com/watch?v=x-BGRgdRN_4

http://www.youtube.com/watch?v=3MacJblqTMw#t=1m23s

The water in the 2nd one changes physics when you're in it, and even does this for the enemies that are in it. It also fades out nicely too instead of snapping or something when you get to the next screen.

by tokumaru on 2010-07-01 (#63542)

RushJet1 wrote:
Back on the subject of MM4 and split scrolling, why does the area to the right flicker a lot on the border of the two scrolling areas?

Timing reasons, I guess. It may be that the emulator used for making the video is not accurate, but it was not uncommon to have games modifying the scroll at times that would cause visible glitches even on hardware back then.

Quote:
It also fades out nicely too instead of snapping or something when you get to the next screen.

Indeed, that's much more professional.

by RushJet1 on 2010-07-01 (#63543)

It's not the emulator, I notice this in Mega Man 3 all the time. Either the right half of the screen where the borders meet flickers, or a row of pixels is (visibly) lost when the dual scrolling starts, or BOTH.

PERFECT example:

http://www.youtube.com/watch?v=Ieqs1zFr03k

by tokumaru on 2010-07-01 (#63545)

RushJet1 wrote:
http://www.youtube.com/watch?v=Ieqs1zFr03k

It appears they are modifying the scroll too early, which causes what's supposed to be the first scanline of the new area to show up all glitched, and after the Y scroll is incremented at the end of that scanline the one that's supposed to be the second one shows up where the first one should be, shifting everything up by 1 scanline.

I know that back then compiling and testing a new build didn't take a second like it does nowadays, but leaving that kind of glitch in is a very sloppy thing to do. If they couldn't calculate how many cycles to wait based on where the scroll was being visually changed and fix the problem right away, they could at least have adjusted a cycle-killing loop gradually across builds made to test other things. That's a very serious bug IMO, and no programmer should settle for that kind of glitch, especially if it can be fixed so easily.

by Bregalad on 2010-07-01 (#63548)

Quote:
It's not the emulator, I notice this in Mega Man 3 all the time. Either the right half of the screen where the borders meet flickers, or a row of pixels is (visibly) lost when the dual scrolling starts, or BOTH.

PERFECT example:

http://www.youtube.com/watch?v=Ieqs1zFr03k

Well, in the PAL version this is worse - the whole screen completely flickers and this boss is almost unbeatable, and yes, using an official cartridge, official NES, etc... I even tried 2 different cartridges to be sure but the glitch is present in both of them.

I guess they fixed this in the PRG1 verison (both cartridge I have are PRG0), but anyway THIS is innacetpable. I agree minor glitches are lame, but a major flicker that makes you unable to see what happens on the screen is REALLY inacceptable. Can't belive Nintnedo put their seal of squality on it.

by tokumaru on 2010-07-01 (#63553)

That is terrible! They probably just took the NTSC game, adapted the music to PAL (or not, I don't know!) and didn't even bother to check the rest of the game. Man, not adapting raster effects when converting software to PAL is a huge FAIL. But seeing as they didn't even get them right on the NTSC version this is not such a big surprise.

by Bregalad on 2010-07-01 (#63554)

Yeah this is terrible, and a big Fail. Japanese companies really din't care about Europe until more recently. Capcom however is one of the first company to fixes the music for PAL - Mega Man 1 already fix it - tempo AND pitch. Other companies started to do that ~1989 I guess.

However, the tempo fix in MM3 creates errors with Proto Man's whistle - when proto man appears in one of the stage, the whistle "continue" and you hear some more notes - which are supposed to be only heard in the ending.

I will also mention that a lot of sound effecs in Mega Man 1 (E) and Mega Man 2 (E) sounds completely wrong, because the messed up something in the pitch fix, where pitch to high would result in a low tune. It's another fail, though not as big as the end boss of Mega Man 3.

by Disch on 2010-07-01 (#63566)

You perfectionists have to realize what it's like to work under a deadline with far inferior tools than what's available now.

I doubt fixing a slight graphical glitch was very high on the priority of things to fix in that game. I don't think anyone playing the game when it was first released even really cared about it. I know I didn't.

Also I still kind of don't care about it.

So whatever. It's not "unacceptable" or "unbelievable" by any stretch of the imagination.

by tokumaru on 2010-07-01 (#63569)

Disch wrote:
I doubt fixing a slight graphical glitch was very high on the priority of things to fix in that game.

I think the exact opposite: if they let something this obvious slip, I wonder what other dirty little details are under the hood. And from what Bregalad is saying, in the PAL version it wasn't a "slight" glitch at all.

Quote:
It's not "unacceptable" or "unbelievable" by any stretch of the imagination.

I disagree. I didn't care until now because I figured it was just an emulator error, but to know that this actually happens on hardware is outrageous. I would certainly have questioned this as a kid. I would eventually let go, of course, but that's too weird to go unnoticed.

by MottZilla on 2010-07-01 (#63572)

I agree with Disch. It's a minor glitch. To most players of the day they wouldn't be bothered. It doesn't look nice, but its far from game crippling. The PAL version who knows. Back in its day I believe I played through all of MM3. I never noticed or got annoyed by it. And in many NES games there are odd little glitches but it's no big deal, so long as the game works, doesn't crash, and the graphics don't become corrupted and the player can't continue.

by Disch on 2010-07-01 (#63573)

Deadlines to meet, bigger fish to fry, etc, etc.

Companies not willing to spend the money on additional man hours and delaying the release of a project because it isn't 100% glitch free. That's not unacceptable or unbelievable, it's common practice in every professional environment.

Perfection is not cost effective. Gamers of the late 80s / early 90s didn't care if a scanline flickered, so why would a game company spend thousands of dollars (or more) to fix it?

It's easy to be ideological about game releases when you're not confronted with the fiscal reality of it.

Hobbyists have the luxury of being perfectionists because they're on nobody's timetable but their own. In the professional world, if you get hung up on minor details like this, then you don't finish the actual product.

tokumaru wrote:
I think the exact opposite: if they let something this obvious slip, I wonder what other dirty little details are under the hood.

I'm sure there are tons.

Every program you use, have used in the past, or will ever use has tons of "dirty little secrets".

Welcome to the world of software development.

Quote:
And from what Bregalad is saying, in the PAL version it wasn't a "slight" glitch at all.

The team in charge for porting to PAL probably did minimul changes on a short time table.

If they noticed the glitch, they probably would have had to dig through timing code that someone else wrote, figure out how it worked, figure out how to fix it, retest it, etc, etc.

They probably didn't know as much about timing details as we do now. They definitely didn't have the tools we have now.

These things take time. Time is expensive. Companies aren't always willing to pay.

The question they were asking themselves is not "is this a bug we can fix?"... it was probably "will taking the time to fix this bug increase or decrease our revenue?"

Quote:
I disagree.

You're in the minority. MM3 was an extremely popular game. Lots of people payed good money for it back in the day, and it is still enjoyed by a relatively large audience even today.

Glitched graphics and all.

Most people simply don't care. If they even notice.

And since people "accept" the game and enjoy it, that by definition makes it "acceptable".

EDIT: of course "Acceptable" is competely subjective. Perhaps your standards are just higher.

I guess what I'm saying is... your standards are unreasonably high.

I see people on these boards talking about how they wouldn't be satisfied if one pixel was out of place in a scene. I don't know if you're one of them... but that's kind of the vibe I'm picking up.

There's just no way that such attention is cost effective in the commercial world.

EDIT2:

Real world example:

I know these 2 guys on IRC. kuja_killer and Sivak.

kuja_killer is making this awesome MM3 hack. He's ripped apart the engine, whole new levels, added MMX style E-tanks, redid all the menus, added SRAM, MMX style Heart Tanks, new graphics, etc. He even switched to MMC5 and is using extended attributes.

He isn't happy until he's iron out every little imperfection. He even optimises code that doesn't really need to be optimised.

Meanwhile... Sivak has coded and released what... like 4 or 5 games? At least one of which was put on a cart and sold online and became popular worldwide (in niche circles).

So Sivak is finishing stuff, and making coin in a fraction of the time.

kuja's been at it for years. He's not even halfway done yet. He sometimes jokes that he'll never be finished.

Sivak is working on his next game. He's got a marketing plan for that one too, I think. I even heard him talking about the game he's going to do after that.

by Dwedit on 2010-07-01 (#63574)

"Unacceptable" was leaving in the debug cheats on player 2's controller.

by Jeroen on 2010-07-01 (#63576)

^^I actually find this acceptable as a.) you'd have to know about it b.) It doesnt hurt anybody c.) you gotta remember that back then finding cheats and stuff was actually part of the game in a way....remember all those nintendo power tricks?

by Bregalad on 2010-07-02 (#63579)

Dish, you seems to confuse things. Tokumaru was whinning about "small" glitches and said it was unaccepatable. I was pointing that on the PRG0 PAL version, during the last (well, one before last) boss, the whole screen flickers completely (the tiles that are supposed to be the ground shows up on the top every other frame I guess), and I was saying this is REALLY unacceptable (as opposed to little glitch tokumaru mentions).

You seem to like to talk about financial things. Is it right that Capcom would "spend" thousands to have employees fix the minor glitch above Shadow Man's face ? Put that way, yeah it's accetpable. But is it right that a player spends I have no idea how much for a game that is not beatable because the whole screen flicker on the last boss, because Capcom's employees didn't port the game to PAL proprely ? No it's not - I want to buy functional games.

by Kasumi on 2010-07-02 (#63580)

Bregalad: You are right. Tokumaru was talking about "small glitches" and saying that was unacceptable. I am quite sure Disch (I've read that the C is for Cool) was responding to him, not your statements about the PAL version which I agree are unacceptable. I am also responding to such statements about smaller things.

Edit: No wait. I reread it. My bad. He addressed PAL as well. He's on his own there.

Edit 2: Since I don't think a video of the PAL version of this glitch was posted, and to make amends about my mistake about Disch's intentions, I offer this: This is what we're dealing with at (47:00) (No need to download, there's a streamed one)

Disch wrote:
I see people on these boards talking about how they wouldn't be satisfied if one pixel was out of place in a scene.

I'm reminded of the single wrong pixel in EarthBound.

I must have played through the game 10 times before I even saw it. Someone else must have noticed it because it was fixed in Mother 1 + 2 on GBA.

I'm pretty anal about little imperfections in the game I'm working on now. A lot of what's in my current known "bug list" are things the player would not notice, or would write off as a one-off thing. (For instance landing on a very specific pixel in between two specific slope heights would force the player slightly to the left and up. I know it's there, and it's still really tough to do.) I'm not anal about it because I think the end user will be bothered, though. I'm anal because it bothers ME as the creator of the game. If I had a deadline, you can bet I'd stop caring about that kind of thing, and move onto the big stuff.

Code:
;if you don't want to read a lot about bigger glitches
jmp postshorten

I'm actually really forgiving about glitches in other games. I understand they had deadlines and all that. And I love glitches and oversights. When I heard about the debug functions on player 2's controller? My first thought was, "AWESOME! I GOTTA TRY IT!" The wrong scanline? I noticed it, but didn't care, just like I don't care about the wrong pixel in EarthBound. To me it's funny. Something to giggle about and tell your friends. I think a lot of gamers are like that. It might be a programmer's mindset that looks on these things with disdain. But look up a video of someone who's discovered some glitch. They're laughing about it. These things happen. Crashes? Sure, that's unacceptable. It totally frustrates the end user. Bad code that makes the game more difficult than it'd be if it was done correctly? Also unacceptable. Glitches that affect multiplayer? Also pretty bad. People then get into fights about whether or not to use the glitches, and that also frustrates some of the user base. Single player stuff is fine. It's easier to not use a glitch you know about, than to play against people who won't use it to gain an advantage "for honor". (I like Wavedashing in Smash Bros. Melee. People got frustrated when I did it outside the tourney scene sometimes. Meanwhile there are similar things in other games that I DISLIKE and would rather not use or play against.) Other glitches? Eh... whatever. If it isn't bothering the end user, I don't see it as a problem. (If it's in a game I'm playing and not making)

Here's one (Not NES) I'd be embarrassed about if it showed up in a game of mine. But the gamers were not disappointed a bit. They're having fun with the oddity.

Minor graphical things don't even phase me. The first game I noticed NES' tiles being the wrong color on the sides of the screen was in Kirby's Adventure. It wasn't even the first time I played it. I just... noticed it one day. I thought it was interesting. Now that I know how much trouble they would have had to go through to make it NOT happen, I don't hold it against them, not that I ever did. The same goes to scanline issues in Megaman. (Not the PAL version by the way. I would have been put off even as a youngster.)

I don't think the developers did a terrible job when glitches are found, even game breaking ones like invincibility in Battle Kid, or screen warping in Link's Awakening. I can't say whether or not I'd have avoided creating those glitches if I had been in the position to make either game, but I can say with CERTAINTY, I would not have found them through play testing. So it's totally forgivable.

Whenever I hear about a glitch, I think, "Well, okay, why does this happen? How can I avoid it in my game?" I don't mind, because I might have made the same mistake, if they hadn't made it first. Even when I young, I loved glitches, and trying to figure out why they did what they did. I can get game cube's Tony Hawk Pro Skater 3/Sonic the Hedgehog/Super Mario 64 DS/Yoshi's Island (well... kinda)/many others to consistently crash and while that's bad, I have to be TRYING to make it happen.

Code:
postshorten:

I can see nonstandard (so tile attribute NES stuff/sprite flickering doesn't count etc. It comes with the territory) graphical problems during fairly normal gameplay in Ristar/Earthbound (above, heh)/Sonic 3&K/Pokemon Red and Blue/Super Mario Bros. 2/Super Mario World (I'd have to double check that one)/others and I have never been bothered by them. It's kinda like in a sitcom how sometimes the microphone above the actors drops into the camera's view. It happens.

When you guys worried about this MM3 scanline thing see this stuff, is your first reaction really one of (seeming) disgust? If so, dang, I guess I really do need to fix every little thing to please you. I'm pretty sure most people aren't like that, but that thought worries me...

Another long somewhat off topic post...

by tepples on 2010-07-02 (#63588)

Dwedit wrote:
"Unacceptable" was leaving in the debug cheats on player 2's controller.

No, "unacceptable" was making debug cheats that don't pop up "DEBUG" on the screen.

Jeroen wrote:
It doesnt hurt anybody

Except people who compare scores.

Jeroen wrote:
remember all those nintendo power tricks?

True, "Classified Information" listed cheat codes, but there was also a brag board. Anyone could take a photo of the console and TV and get a high score published in a national magazine. Nintendo required the photo to make sure the Game Genie wasn't used, but what they didn't tell you was that a VCR could circumvent that.

Kasumi wrote:
I'm reminded of the single wrong pixel in EarthBound.

That looks like a crumb to me, adding variety to the graphics that arguably make them slightly more believable. If this were a PC point-and-click adventure game, the player would be expected to examine the crumb.

Kasumi wrote:
Even when I young, I loved glitches, and trying to figure out why they did what they did.

I told NovaYoshi that one learns more about programming from glitches than from things that work.

by RushJet1 on 2010-07-02 (#63590)

In the MM3 PAL vid i noticed some weird stuff. More of the Wily map song plays than in the NTSC version, some sound effects (most noticeably the boss exploding sound) sound wrong. That flicker on the boss is terrible. I wondered if MM4 was any different...

In MM4, the "shooting" sound is off, as is teleport, and especially the "charge" sound. During Dust Man's level the scrolling area is handled identically to the NTSC version, buggy scanline and all, but not flickering madly.

edit:

Kasumi wrote:
When you guys worried about this MM3 scanline thing see this stuff, is your first reaction really one of (seeming) disgust?

When I first got Mega Man 3, I assumed my cart was dirty, or that it was somehow defective. I didn't really know this was a glitch till much later.

by tokumaru on 2010-07-02 (#63591)

I understand what you guys are saying, we just happen to disagree on how severe the glitch is. This will vary from person to person.

The fact that a company isn't willing to fix these bugs for financial reasons doesn't make me feel better about the game, it just makes me think even less of it. Instead of aiming for a good product, they are simply making it barely "good enough". And the low standards most consumers have is what allows this to happen. We, not particularly rich people, fill the pockets of these big companies and they are not even trying hard enough to provide something that's unarguably good. They do "just enough" to get the money out of us.

This is why I'm gradually abandoning software development as a form of income. Several times I had to settle for less quality because of deadlines, and I don't feel good with myself because of that. I'll try to use programming exclusively as a hobby, so that I have full control of what I do, without ever having to settle for less because of others.

RushJet1 wrote:
In the MM3 PAL vid i noticed some weird stuff. More of the Wily map song plays than in the NTSC version

That's probably a side effect of fixing the music's tempo... it plays at the same speed as the NTSC version, but the rest of the program runs slower because delays, distances and such weren't adapted for the slower frame rate, so as a consequence the music gets out of sync with the video. Most of the time this isn't a problem, but there are a few timed events that will expose this.

I'm not sure, as a game developer, of what would be the best way to handle this. If you adapt everything that's related to gameplay (delays, distances, etc) to PAL, the game might play at the same apparent speed, but it might end up behaving differently because of fixed-point rounding errors. And there are some aspects that are tied to the frame rate because of VBlank use (such as CHR-RAM updates) that wouldn't work even if the timing was fixed. Of course PAL has a longer VBlank and could easily accommodate video updates for 2 frames, but the logic to handle that would not be trivial, and RAM usage would increase significantly.

All of that was to say that I can't think of a good way to make NTSC and PAL versions of the same game play exactly the same (from a player's perspective). But this is probably a subject for another thread.

by kuja killer on 2010-07-02 (#63592)

i know about those little scanline glitches of mm3.
I once managed to fix every single one that ever existed in mm3 originally.

yea basically every single IRQ the game has, has cycle timining issues or whatever. I eventually found out how to fix every single one 100% purely perfect so none of that little pixel shaking stuff would ever happen in any major battles and such.

I dont remember what i had done though since it was a few years ago. I think it was usually simply changing what scanline number the irq happens at by 1 scanline up or down, which would fix most or all of them.

by Bregalad on 2010-07-02 (#63593)

Quote:
The fact that a company isn't willing to fix these bugs for financial reasons doesn't make me feel better about the game, it just makes me think even less of it. Instead of aiming for a good product, they are simply making it barely "good enough". And the low standards most consumers have is what allows this to happen. We, not particularly rich people, fill the pockets of these big companies and they are not even trying hard enough to provide something that's unarguably good. They do "just enough" to get the money out of us.

Well I'm not saying you're wrong, but a small graphical glitch or lack thereof isn't what makes a game good or bad. Capcom always tried their best to make very good games - and didn't want them to be just "good enough". Okay I know there is also some bad games from Capcom, but Mega Man 3 is objectively a very good game. The fact there is some graphical glitches is a shame - especially for the PAL version - but it doesn't prevent the game from being very good. If you're still hesitant about it, play AD&D - Heroes of the Lance, Action 52, Ghost busters, or and you'll see what I mean.

However, now that I've throught about it - Dish' reasonment that "Capcom didn't want to pay $xxxx for fixing the glitch" doesn't hold very well. If you'd think like that - you might say you don't want to pay $xxxx for having a lot of music tunes, and compose only a song for the whole game. Then you don't want to pay $xxxx to have different graphics in different levels, so you only have one tileset. Etc, etc.. and it ends up like Ghostbusters.

Video games are in the gray zone - they're art but still an industry.

by MottZilla on 2010-07-02 (#63594)

Wow the PAL version of Mega Man 3's boss glitch is terrible. I would say that is unacceptable behavior. While I disagree that it makes the sequence impossible to complete, it certainly is annoying. As I said before, minor graphical glitches are acceptable to a point. Even modern games have them.

I think that Capcom should have spent the money to fix the PAL version of MM3, or atleast improve it. But the NTSC version clearly didn't need the extra polish. Also leaving the P2 controller debug cheats on was not a huge deal. I suppose it's not very professional but it's realistic to how mistakes can be made when there are deadlines.

I don't think your comparison with 1 song holds up well. That is related to game play standards of the day. A game with just 1 song in MM3's time frame would not be acceptable. Ultimately whoever decided not to spend extra time on fixing the minor glitches (or in PAL major) probably was nothing more than a management person who asked, how much more time would you need? And given they answers they got they said no we aren't doing it.

by artakserkso on 2010-07-02 (#63597)

Uh-oh... And what's the first NES game I decided to buy and play on my PAL machine until I fix up an NTSC one? Yup, you guessed it... MM3.

I haven't checked out the glitch to avoid spoilers, hopefully it won't prove insurmountable!

EDIT: Aw, man... My g/f and I just got to Dr. Wily. I could barely keep my lunch. The PAL glitch really is terrible. I'll wait till I can put together an NTSC NES and play the rest on my PowerPak.

by Bananmos on 2010-07-02 (#63604)

Quote:
Yeah this is terrible, and a big Fail. Japanese companies really din't care about Europe until more recently. Capcom however is one of the first company to fixes the music for PAL - Mega Man 1 already fix it - tempo AND pitch. Other companies started to do that ~1989 I guess.

Come again? No PAL MM1/MM2 cart or ROM image I've ever encountered has showed any PAL fixing. MM3 I can't remember honestly... but none of the early Capcom games I know of fixed the music, except for the ones where the work was outsourced to other companies. (Ghost n' Goblins by Micronics comes to mind, just wish they had spent some more time fixing visual glitches instead before the deadline ;)

by Disch on 2010-07-03 (#63621)

Begalad wrote:
you seems to confuse things. Tokumaru was whinning about "small" glitches and said it was unaccepatable. I was pointing that on the PRG0 PAL version, during the last (well, one before last) boss, the whole screen flickers completely (the tiles that are supposed to be the ground shows up on the top every other frame I guess), and I was saying this is REALLY unacceptable (as opposed to little glitch tokumaru mentions).

Ah. Yes I agree that is unacceptable.

tokumaru wrote:
Instead of aiming for a good product, they are simply making it barely "good enough".

I would definitely say MM3 was a good product. I actually thought it was by far the best in the NES series.

From what I can tell, a lot of people put it in their top 2 favorite (most people I've talked to like MM2 or MM3 the best).

Do you really feel that a few glitchy scanlines destroy the entire game?

Quote:
This is why I'm gradually abandoning software development as a form of income. Several times I had to settle for less quality because of deadlines, and I don't feel good with myself because of that.

I hope you're ready to gradually abondon working for any company in any field anywhere. Because they all do that. Perfectionism just doesn't pay.

The quality to time ratio is a tradeoff. Like a bell curve. If you have a crappy product, no one will buy it and you lose money. And if you spend the time to make a fantastic, flawless product, sure people will buy it, but you will have lost more in labor/production than was made up for in sales.

Success lies in finding a middle ground.

Begalad wrote:
However, now that I've throught about it - Dish' reasonment that "Capcom didn't want to pay $xxxx for fixing the glitch" doesn't hold very well. If you'd think like that - you might say you don't want to pay $xxxx for having a lot of music tunes, and compose only a song for the whole game. Then you don't want to pay $xxxx to have different graphics in different levels, so you only have one tileset

If you take it to extremes, of course it no longer makes sense.

If they didn't want to pay $xxxx to make the game at all, they would just be selling empty cartridges.

The company has to choose where it's going to spend money. Sometimes there isn't enough money to fix every single problem. So you have to prioritize and pick which problems are most severe.

Apparently the execs thought that money was better spent elsewhere in the game than on fixing a few graphical glitches. Or maybe the developers simply ran out of time.

by Bregalad on 2010-07-04 (#63660)

Quote:
I hope you're ready to gradually abondon working for any company in any field anywhere. Because they all do that. Perfectionism just doesn't pay.

Well not always. The industry in my country is reputed to produce high quality products and export them in many countries - so people are definitely ready to pay more in order to get higher quality products - so yes perfectionism can pay. (I'm not saying it will always pay of course).

Quote:

The company has to choose where it's going to spend money. Sometimes there isn't enough money to fix every single problem. So you have to prioritize and pick which problems are most severe.

Apparently the execs thought that money was better spent elsewhere in the game than on fixing a few graphical glitches. Or maybe the developers simply ran out of time.

I fully understand that. Another point is that Capcom's programmer likely didn't have half of the knowledge of the NES hardware that we have - and had no idea of how the PPU was fetching tiles. They just figured that writes to $2006 could change the tile shown and exploited that in their games.
Other comanies (Squaresoft, Rare) obviously took more time to examine the NES hardware and it's tricks (so they probably took the choice to pay employees to do that). That doesn't necessary make them do better games, but games that exploit more the hardware.

by tepples on 2010-07-04 (#63666)

Bregalad wrote:
The industry in [Switzerland] is reputed to produce high quality products and export them in many countries - so people are definitely ready to pay more in order to get higher quality products

Swiss watch makers can get away with charging luxury prices for the level of engineering that goes into a luxury product because there's definitely a segmented market between a Rolex and the Casio on my wrist. Video games, on the other hand, have a nearly uniform retail price. Except for games that come with dedicated controllers, virtually no game disc for a current console costs more than 60 USD per copy (excl. VAT) in the United States.

by strat on 2010-07-09 (#63955)

Did anyone see the latest AVGN? When he played the second Dr. Wily boss in Megaman 5 that you use two sections of its body as platforms, the sections stayed in place but the collision still worked, so he had to fight the boss blind. I'm guessing the mapper hardware was faulty and the scanline irq didn't trigger.

by Dwedit on 2010-07-09 (#63956)

I've also seen scanline IRQ fail once in Gremlins 2, made the ending stop at the wrong cutscene. It's strange because the graphics seemed okay, but there were graphical glitches elsewhere at other times.