It is currently Tue Dec 12, 2017 7:10 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 15 posts ] 
Author Message
PostPosted: Mon Dec 12, 2005 1:44 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
Hi guys,

I've accepted the MMC3 as a sort of "standard" for my projects, as most of the games that interest me use it, wich means it can do a decent job.

However, it's scanline counter is a pain in the butt, with all the limitations. Most of them I can live with. For example, the fact that you have to use specific pattern tables for sprites and BG is not that bad, since the mapper lets you choose the size of the banks for each side (you choose wich one uses 2KB chunks and wich one uses 1KB chunks).

But there is one thing that I fear (wich I'm not even sure if it is one of the forbidden things), and it's the possibility that you can not use the other half of the pattern tables for sprites even when using 8x16 sprites. It makes sense that you can't, as you'd be using a table supposedly used for BG. Is that really breaking a MMC3 rule?

I intended to have sprites using BG tiles, so that some BG stuff could be animated without the need to duplicate tiles and waste a lot of space, specially since I intended that most of them were animated, and bankswitching both copies would be a BIG waste of space.

Maybe I should just set my priorities, and drop one of the two: scanline effects or cool animation...

What do you think?


Top
 Profile  
 
PostPosted: Mon Dec 12, 2005 1:49 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7314
Location: Chexbres, VD, Switzerland
tokumaru wrote:
I've accepted the MMC3 as a sort of "standard" for my projects, as most of the games that interest me use it, wich means it can do a decent job.

Funily, for all reasons you mentionned, I always managed to avoid MMC3. A second reason to avoid it is the fact that no Dragon Quest games use MMC3, they all uses MMC1, and they're still so good. Then Enix directly switched to MMC5 for Just Breed. Also, only Final Fantasy 3 uses MMC3, while the 1 and 2 uses MMC1, and are so good. So yeah, MMC3 isn't needed to do good games (yeah, Mega Man 3, 4, 5, 6 can shut down my theory, I know).
Does 2 8kb banks have any advantage on one 16kb bank about bankswitching ? If would be pretty much the only strong point of the MMC3, if there is.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
PostPosted: Mon Dec 12, 2005 1:54 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19334
Location: NE Indiana, USA (NTSC)
Bregalad wrote:
Does 2 8kb banks have any advantage on one 16kb bank about bankswitching ?

Yes, if you're using DPCM. There are only a few places to put samples:
  • In a hardwired bank. Useful if you have a few short samples that are used often; for example, Contra does this with drums, and Duck Hunt and Kung Fu do this for their sound effects.
  • In a bank switched into $8000-$BFFF or $8000-$FFFF. Decode the samples in software and play them with timed writes to $4011. See Battletoads, Blades of Steel, the intro of Action 52, Big Bird's Hide and Speak, etc. Pro: Can use more sophisticated codec than DPCM. Con: This usually pauses action. Con: Does not work on PocketNES.
  • Bankswitched into $C000-$DFFF. Only MMC3 and more powerful mappers can do this.

U*ROM/S*ROM typical configuration:
$8000-$BFFF Bankswitched code and data
$C000-$FFFF Hardwired code, data, and DPCM samples

T*ROM typical configuration:
$8000-$9FFF Hardwired code and data
$A000-$BFFF Bankswitched code and data
$C000-$DFFF DPCM samples
$E000-$FFFF Hardwired code and data


Top
 Profile  
 
PostPosted: Mon Dec 12, 2005 3:23 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
tokumaru wrote:
and it's the possibility that you can not use the other half of the pattern tables for sprites even when using 8x16 sprites.


That is correct. For the MMC3 IRQ counter to behave 'normally', all BG tiles must be read from the left pattern table ($0xxx), and all sprites (regardless of 8x8 or 8x16) must be read from the right pattern table ($1xxx).

You might be able to get away with breaking the rule sometimes (or even reversing things so that sprites use the left and BG uses the right.. but then you'd need to use 8x8 sprites).. but it'd be risky and you'd have to know pretty well what you're doing.

Quote:
Maybe I should just set my priorities, and drop one of the two: scanline effects or cool animation...


You can always fall back on good old Sprite-0 hit. Or use a different mapper?

But as for choosing one of the two... it depends on what kind of game you're making. For most games, I'd be inclined to opt for a scanline counter and just be more conservative with my sprite graphics.


Top
 Profile  
 
PostPosted: Mon Dec 12, 2005 6:53 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
Bregalad wrote:
Funily, for all reasons you mentionned, I always managed to avoid MMC3.

Yeah, that is a much more intelligent way to look at it... =)

I think MMC3 is interesting because it is very common, simple to use, and has the essential set of features to achieve good effects. Only the limitations in regard to the scanline counter are a pain.

MMC1 has no scanline counter. MMC5 feels a bit too much like cheatting to me, although I'm starting to consider switching to it.

Quote:
Does 2 8kb banks have any advantage on one 16kb bank about bankswitching ? If would be pretty much the only strong point of the MMC3, if there is.

Not for me, no. I'd be interesd in having no hardwired bank though, you know, be able to switch out the lask bank, but still have at least 2 of them (16K), not a full 32K chunk.

Disch wrote:
You can always fall back on good old Sprite-0 hit. Or use a different mapper?

Sprite 0 hit is no good for many of my plans... In many of my ideas, I will be running pretty heavy code, all the time, and there is no way for me to "just wait" for a hit. And I'll most likely need splits at random scanlines, meaning I won't be able to place the waiting before or after the havy code... The hit would have to happen at the most different times and it would just not work...

Quote:
But as for choosing one of the two... it depends on what kind of game you're making. For most games, I'd be inclined to opt for a scanline counter and just be more conservative with my sprite graphics.

I guess you're right... there is no "correct answer", only opinions. In the end I think I'll choose the same as you: keep the counter and hold back on the sprites.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 13, 2005 9:07 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
Oh, man... MMC5 has it all... it's bankswitching scheme is great, it's scanline counter is so *solid*... I'm really feeling like using it.

If I only use the bankswitching and the scanline counter, it may not feel like cheating, but then I'd feel really stupid for having those great graphical enhancements avaliable and not using them... I mean, not only MMC5 would end the scanline counting issue, but it would also come with the awesome EXRAM features, wich ALSO solves many other problems (having attributes applied to individual tiles would REALLY help me in one of my projects).

But then I could kiss good bye to the dream of having my stuff ever running on a real cart, 'cause not only I have no means to transfer them to cart myself (fact that may change in the future, I hope), but MMC5's are kinda difficult to get, right...?


Top
 Profile  
 
PostPosted: Tue Dec 13, 2005 10:23 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7314
Location: Chexbres, VD, Switzerland
tokumaru wrote:

Not for me, no. I'd be interesd in having no hardwired bank though, you know, be able to switch out the lask bank, but still have at least 2 of them (16K), not a full 32K chunk.

The MMC1 can do it, while the MMC3 cannot. The MMC1 also can do one-screen mirroring, that the MMC3 cannot.

About MMC3 standard configuration, I do not have any games in mind that constantly have DPCM samples bankswitched in $c000-$dfff, is there any ?
Anyway, I kinda dislike DPCM channel, due to it's mediocre quality and waste of ROM space. With that configuration, you only get 8kb of bankswitced space insted of 16kb, so it is worse than MMC1, also considering the fact that the 16kb hardwired space is splitted in two.

Overall :

MMC1 cons :
- Cannot have a scanline counter that triggers IRQ
- Cannot have smaller banks than 16kb

MMC1 pros :
- Simple and efficient bankswitching
- Common cartridges with both CHRAM and CHROM
- Common cartridges with SRAM

MMC3 cons :
- Using 8x16 sprites in order to acess BG pattern table is impossible while using the IRQ counter.
- You cannot switch pattern tables midframe for doing background effects or ehencements (unless you disable IRQ counter)
- You cannot switch the higher 16kb PRG bank
- You cannot get one-screen mirroring
- Carts with CHRAM are incredibly rare (more or less only Megaman 4, 6 and Final Fantasy 3 are included), and I personnaly prefer CHRAM on CHRROM (while CHROM is also interesting)
- Carts with SRAM are very rare (at least in europe)

MMC3 pros :
- Has a scanline counter
- Incredibly common cartridges with CHROM and no SRAM (or with non-battery backed SRAM)

MMC5 cons :
- Rare cartridges
- Programming it is somewhat hard, but worth it

MMC5 pros :
- Graphical ehencements
- Larger SRAM size available
- Scanline counter
- Pretty much everything else

Edit : Tokumaru, scince you already started your project with MMC3, I don't think now would be a good time to switch. I think duplicate tiles doesn't waste that much space, don't switch two times the same bank in, but just copy the tiles you want to use for both background and sprites a second time in another bank. It may waste a bit of space, but not that much. And this can allow you to use different palletes setups, but still have the sprite looks to have the same color that when the same object was BG. Just Breed does this with EVERY player and monster in the game, that have each their BG tiles and sprite tiles. Also check if you cannot do what you want to by using only BG or only sprites if possible.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
PostPosted: Tue Dec 13, 2005 11:30 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
Bregalad wrote:
I personnaly prefer CHRAM on CHRROM (while CHROM is also interesting)


I'd go with CHR-ROM any day. I like fast graphic changes and there is no way to do them with CHR-RAM AND still update name tables and attribute tables. Of course, there are things that CHR-RAM can do that CHR-ROM can't, as discussed before. I can easily see the benefits of it in an RPG.

Quote:
Edit : Tokumaru, scince you already started your project with MMC3, I don't think now would be a good time to switch.

Not such a big deal at this point. Not much mapper-specific things have been done yet, as I like to make sure all the stuff works before implementing bankswitching and such. I first get the engine running, mapper 0 all the way. After the logic works, I'll use bankswitch to load levels and change the graphics. And also implement scanline effects.

Quote:
I think duplicate tiles doesn't waste that much space, don't switch two times the same bank in, but just copy the tiles you want to use for both background and sprites a second time in another bank. It may waste a bit of space, but not that much. And this can allow you to use different palletes setups, but still have the sprite looks to have the same color that when the same object was BG. Just Breed does this with EVERY player and monster in the game, that have each their BG tiles and sprite tiles. Also check if you cannot do what you want to by using only BG or only sprites if possible.

I need it mostly for items that the player can pick up. They're laid out in the level as background, but when the player drops them, uses them, etc. (smoother animations) they reappear as sprites. Think "Sonic loosing his rings".

Having the repeated stuff stored as different tiles surely presents the advantage of using different palette setups, as you said, since a sprite palette will hardly mach a background palette perfectly. But if you keep the colors in the palettes sorted based on the brightness of each color, most of the time reusing BG tiles as sprites will look decent enough with a moderatelly close palette.

I'll think about it better, but I'm almost switching to MMC5 anyway...

I don't NEED the MMC5 enhancements (but they may surelly help!), but also can't take some of the MMC3 limitations. If a mapper forbids you to do something you could without it, that can't be a good thing, right? Mappers aren't supposed to take things away... I know it is only so when you're actually using the IRQ counter, but even so...


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 13, 2005 12:08 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 2:13 pm
Posts: 1667
Location: .ma.us
Have you considered the FME-7? It's what I plan to use on my project. Clean registers, 1k VROM switching, cycle counter... it's got everything :)


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 13, 2005 12:28 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
kyuusaku wrote:
Have you considered the FME-7? It's what I plan to use on my project. Clean registers, 1k VROM switching, cycle counter... it's got everything :)

A cycle counter... that's interesting... gives you more control over when the IRQ fires... but it may take longer to translate scanline numbers into cycles dynamically in software, though (especially because of the 113.66666... cycles per scanline thing).

This is a nice mapper indeed (swaps ROM in 8kb chunks and all), but I'll go with either MMC3 or MMC5. If am to change to a less common mapper I'll just go with MMC5, wich is close to perfect (ok, I'm exagerating a bit here) in all aspects.

I wish I knew something about electronics to design my own mapper! =)


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 13, 2005 12:50 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
Heh... I've actually noticed that many of the famicom mappers I've worked on for my emu are just so superior to MMC3. Kind of is disappointing when you consider the "standard" mapper is put to shame by many 3rd party mappers.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 13, 2005 3:33 pm 
Offline

Joined: Tue Nov 23, 2004 9:35 pm
Posts: 630
Quote:
- Carts with SRAM are very rare (at least in europe)


I think this applies to almost everything. Only eleven games that used battery backup outside the US:

Pirates!
Zelda II: The Adventure of Link
Legend of Zelda, The
Maniac Mansion
NES Open Tournament Golf
Deja Vu
Kirby's Adventure
Shadowgate
Wario's Woods
Startropics
Elite


Top
 Profile  
 
PostPosted: Tue Dec 13, 2005 8:23 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19334
Location: NE Indiana, USA (NTSC)
Bregalad wrote:
About MMC3 standard configuration, I do not have any games in mind that constantly have DPCM samples bankswitched in $c000-$dfff, is there any ?

Super Mario Bros. 3 is the big popular one that switches $C000 for samples. Klax is another one (although it uses RAMBO-1, a modified clone of MMC3).

Quote:
Anyway, I kinda dislike DPCM channel, due to it's mediocre quality and waste of ROM space.

What's a better way to make realistic drum hits or realistic "woof-woof" or "quack-quack" sounds?

Quote:
also considering the fact that the 16kb hardwired space is splitted in two.

Is this a problem in practice? You just have a few more segments in your ld65 link script: CODE80, CODEE0, RODATA80, RODATAE0, etc.

Quote:
MMC3 cons :
- You cannot switch pattern tables midframe for doing background effects or ehencements (unless you disable IRQ counter)

Yes you can; just use $8000/$8001 instead of $2000. Or am I misunderstanding a fundamental tenet of the MMC3's operation?

Quote:
- You cannot get one-screen mirroring

Even in the TLSROM configuration?

Quote:
MMC5 cons :
- Rare cartridges

I thought "Rare cartridges" were A*ROM not E*ROM. [/sarcasm]

tokumaru wrote:
I'd go with CHR-ROM any day. I like fast graphic changes and there is no way to do them with CHR-RAM AND still update name tables and attribute tables.

Put your status bar at the bottom and turn the screen off 16 lines early. This gives you time to stuff about 12 tiles per frame if you use a transfer buffer properly. Or make PAL50 games ;)


Top
 Profile  
 
 Post subject:
PostPosted: Wed Dec 14, 2005 10:52 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7314
Location: Chexbres, VD, Switzerland
Tepples : Heh, just unlike me, you seem rather MMC3 friendly, aren't you ?
Anyway, you're right for pattern table switching, you can do it trough $8000/$8001 by toggling the CHR banking bit and by changing all swapped banks, but it takes more time that just toggle $2000 so you'll get glitches in your scanline in some cases.

Quote:
I thought "Rare cartridges" were A*ROM not E*ROM

How fun... not my fault if that company choose a stupid name.

Tokumaru : Yeah, CHROM is better in some aspect, but it has tilessets limited to its switching size, don't allow to design your graphics via the code itself (so Stuff like FF2's map would be impossible with CHROM), and you need to burn a second ROM chip, wich is boring when placing your game on a real cartridge especially considering the fact that CHROM usually needs more crap rewiring than PRGROM.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Dec 14, 2005 3:44 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
Bregalad wrote:
Tepples : Heh, just unlike me, you seem rather MMC3 friendly, aren't you ?


Or simply fact-friendly.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 15 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group