nesdev.org

pigpen wrote:

65024U wrote:I'd worry about NROM first, with 32K program and 8K graphics. If your 1st game is over that, you might be getting a -tad- froggy.

I'm not sure what that means but im not asking about this stuff for my first game...im asking to keep my conceptual knowledge ahead of my technical knowledge so i know what direction to head in.

Well if you are making a game,. even if it's not your first, if it's your first on a NES, use NROM.

But anyway, yeah, the MMC1 repropak can make a lot of games work on it that are MMC1. Pretty much all of them, even MMC1 boards not used in the USA like SXROM. But the most commonly used mapper is MMC3 it seems, and that is not on a repropak yet, so for games like that, donors are needed and the one with the right hardware will be needed, since it can't be added like the repropak, which you add what you need to the MMC1 board.

65024U wrote:if it's your first on a NES, use NROM.

Personally, I do not a agree that everyone's first NES game has to be an NROM game. UNROM and CNROM for example are very decent mappers for beginners, as long as they understand the concept of bankswitching, since these are not as restrictive with the graphics.

I for example have never finished a NES game (yet), but I've done a lot of practicing and I know I can do a lot more than what NROM would allow me to, so my first game will most likely not be on an NROM board.

What you can't expect is that mappers do all the work for you. Using an MMC5 will not automatically make your game great if you can't think of interesting ways to use the mapper's features.

Also, using a mapper doesn't mean you have to make a big game and fill up 512KB of ROM, you could very well make a 32KB MMC3 game just because you're interested in its scanline counter. If you understand how the scanline counter works, it will actually be much easier to use it than go with NROM and have to monkey around with time code, sprite 0 hits and DPCM IRQs to achieve a similar effect.

tokumaru is right. While I agree with the idea behind NROM first if you mean don't bite off more than you can chew, in practice for an actual game even if it is your first you should use whatever mapper you want.

Most people don't actually release their first NES programs as they are still learning and likely just making things to test out. They aren't yet making a full game. And tokumaru is right again that a mapper doesn't dictate if your game is fun or not. There are great games that use no mapper or very simple mappers like SMB1 and Castlevania/MegaMan. There are also pretty bad games, even horribly awful games that use very complicated mappers. Just see mapper 90 for some great examples of this.

Heck no, NROM games (especially Mario) show that NROM is very flexible despite the size not being huge. I just really don't think that a mapper shouldn't really be used while your still learning so you can learn your way around other hardware first and make something playable within a small space, so then when you get the extra space, it's easier to cope with the fact you want from 16/32K to 256K and such.

65024U wrote:Heck no, NROM games (especially Mario) show that NROM is very flexible despite the size not being huge. I just really don't think that a mapper shouldn't really be used while your still learning so you can learn your way around other hardware first and make something playable within a small space, so then when you get the extra space, it's easier to cope with the fact you want from 16/32K to 256K and such.

tokumaru wrote:Also, using a mapper doesn't mean you have to make a big game and fill up 512KB of ROM, you could very well make a 32KB MMC3 game just because you're interested in its scanline counter.

It seems you completely ignored my comments about space. Using a mapper isn't necessarily about getting more space... You might pick the MMC3 for its scanline counter, or UNROM so that you can use CHR-RAM in order to be able to animate your background tiles, and so on, but that doesn't mean you have to use more than 16/32KB. You are just allowed to, and that's a good thing.

Most absolute NES newbies do start with NROM programs, but like MottZilla said they never get released because they are not complete games, just tests used for learning. Also, just because a person just got started with the NES, that doesn't mean they are complete newbies to classic console programming. Some have already worked with other platforms, and already have a good understanding of bankswitching and other common aspects, they are just getting acquainted to the 6502 or the PPU, and there is no need for these people to hold back.

Another important point is that a smaller program is not always simpler than a large program. consider this: an uncompressed screen on the NES is 1KB large (32x32 tiles + 64 attribute bytes). If I'm a newbie and want to make a game with several (100 or so) screens, what would you say is easier: using UNROM to store all the uncompressed screens across the available banks or spending a lot of time understanding how compression works and coding compression and decompression algorithms? I'd say it's much easier to code a 3-line bankswitching function and use the uncompressed maps. I know this is a crude example, but it goes to show that smaller isn't always the same as simple.

Yes, It isn't always about getting more space that's needed, but I mean, why use something with such a feature and abilities and not tap anything more complex at all then *just* that feature? It doesn't make sense to me kinda but oh well.....It's just kind of a "Waste of Resources" thing it seems to do such a thing.


Yeah, a MMC3 demo would be fine to test stuff and you have to do some to learn to use stuff like that. But to only make a 32K game not something with lots of levels and such seems almost like a waste IMO.



I hope we get a MMC3 cart on RetroUSB soon....that'd be epic.

65024U wrote: I hope we get a MMC3 cart on RetroUSB soon....that'd be epic.

If you want pics, I've got em

Haha, nah. I think I'll just stare at the MMC1 board and act like it's the same thing.

65024U wrote:I just really don't think that a mapper shouldn't really be used while your still learning

The problem is that even developers of games, like Sivak, are still learning things. You probably never stop learning things. Honestly I don't see why mappers are such a big deal. I can agree to the point that if you never developed a NES game before you shouldn't grab MMC5 and start some crazy complex game using every feature it has. But using a mapper like MMC1 or UNROM or CNROM is perfectly reasonable. The concept of bank switching is not exactly that hard to grasp.

tokumaru wrote:consider this: an uncompressed screen on the NES is 1KB large (32x32 tiles + 64 attribute bytes). If I'm a newbie and want to make a game with several (100 or so) screens, what would you say is easier: using UNROM to store all the uncompressed screens across the available banks or spending a lot of time understanding how compression works and coding compression and decompression algorithms?

You'll need metatiling even if only to align game objects with the attribute grid. Most games' collision appears to be based on metatiles as well, apart from single-screen puzzle games such as LJ65.

As for using UNROM just for its CHR RAM: BNROM is the same thing, just with 32 KiB bankswitching so that you can forget about the bank register entirely on 32 KiB games.

tepples wrote:You'll need metatiling even if only to align game objects with the attribute grid.

I know that and you know that, but maybe the newbie that just learned how to use a name/attribute table editor doesn't, and if he wants to make a game with what he knows, he'll need more than 32KB or PRG-ROM.

But like I said, that was a crude example. The bottom line is that having more space can actually make things simpler some times, since you won't need to think of ways to cram a lot of data in the little space you've got.

I think that the reasoning most people use is that it's easier to generate 32KB of data than 128KB, and that might even be true if you are generating all your data with .db statements by hand, but once you use tools like map editors and music trackers you can generate a lot of data in no time, and it sure will be easier to spread that data across several program banks than invent crazy ways to compact the data and make it fit in 32KB.