Mockups of games from other platforms

A place for your artistic side. Discuss techniques and tools for pixel art on the NES, GBC, or similar platforms.

Moderator: Moderators

Drag
Posts: 1615
Joined: Mon Sep 27, 2004 2:57 pm
Contact:

Re: Mockups of games from other platforms

Post by Drag »

tokumaru wrote:
Drag wrote:even if CV3 doesn't, you could switch into single-screen mirroring when you activate the extended graphics mode
That would be a pain in the ass, if the mirroring interfered with the scrolling system. I'd much rather not change the mirroring and just wrap ExRAM updates around.
A large number of games use single-screen mirroring, or simulate single-screen mirroring through duplicate writes (unnecessary on the MMC5 since it legitimately supports single-screen mirroring), to achieve 8-way scrolling, with or without status bar. If your main in-game view uses single-screen mirroring, then your tilemap is 1:1 with the exgfx memory. How is that a pain in the ass?
I still see no reason why you couldn't switch exgfx off, update exgfx, and switch exgfx back on if you wanted to update exgfx in vblank rather than during rendering.
Has enough testing been done to confirm that this works?
To my knowledge, no. Our current documentation states that exgfx ram access is limited only when exgfx is enabled. Put it in "plain ram" mode and you should hypothetically be able to access it in vblank.
beginners already get confused enough with pattern, name and attribute tables, so yeah, I think they'd find it harder.
The MMC5's exgfx is actually more straightforward than the PPU's regular attribute tables, given that you have 1 byte per tile, and you don't have to access it through $2006/2007. Think about what you have to do to update one 16x16 attribute region on the vanilla PPU, and then tell me the MMC5 is harder.
User avatar
rainwarrior
Posts: 8731
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Mockups of games from other platforms

Post by rainwarrior »

Does it matter if it's more difficult to program for or not? These mockups aren't being made for real games anyway. It's obviously doable, what more do you need?
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Mockups of games from other platforms

Post by tokumaru »

Drag wrote:How is that a pain in the ass?
Switching back and forth between mirroring modes while using the same scrolling engine would be a pain in the ass, that's what I meant. It would make more sense to just use 1 screen mirroring all the way. Or using whatever other mirroring type you wanted and accepting that the ExRAM wraps around sooner, it's switching back and forth that's a bad idea. Not for different engines in the game (i.e. cutscenes vs. gameplay), of course.
To my knowledge, no. Our current documentation states that exgfx ram access is limited only when exgfx is enabled. Put it in "plain ram" mode and you should hypothetically be able to access it in vblank.
In theory, yes, but would you risk doing that without testing on hardware first to be sure it works? The lack of proper reverse engineering and testing of this mapper is a very good reason to use it with caution, or to avoid it entirely if you can't carry out proper tests.
The MMC5's exgfx is actually more straightforward than the PPU's regular attribute tables, given that you have 1 byte per tile, and you don't have to access it through $2006/2007.
IMO, having to access part of the tilemap in one place (name table) and the rest in another (ExRAM) is not intuitive at all, specially considering that the update logic will be very different without the PPU's auto incrementing feature, and that maybe you have to update each part at different times (if you indeed can only update ExRAM during rendering - hopefully you're right and it's possible to change modes for writing during VBlank).
Think about what you have to do to update one 16x16 attribute region on the vanilla PPU, and then tell me the MMC5 is harder.
It can be quite simple if you have 32x32-pixel metatiles and don't scroll vertically, but I agree that attribute tables can be frustrating at times, specially for beginners.

I really don't want to fight over this. I think the MMC5 is a wonderful mapper, it's amazing how Nintendo managed to cram all those features in the chip and upgrade the capabilities of the system so much, and it's sad that it was so underused. I just don't want to see people using it lightly, like it was the most common and supported mapper ever, for petty reasons like a few misaligned background elements. If you really want to use the MMC5, be my guest, but please, design your graphics around it to properly make use of the enhancements, and PLEASE, PLEASE test your software on a real MMC5, because this mapper has not been dissected enough to be taken for granted.
Drag
Posts: 1615
Joined: Mon Sep 27, 2004 2:57 pm
Contact:

Re: Mockups of games from other platforms

Post by Drag »

Sorry about the arguing, it just bothers me when people hate on expansions just because they're expansions is all, and I agree that it's a waste to use a giant hulking mapper just for one tiny part of your game (especially because, like you said, it's not very well understood), but if the 8x8 attribute regions make it easier to plan layouts and make the graphics look nice, I'd say that's enough to make it worthwhile and not a waste.
User avatar
Bregalad
Posts: 8055
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: Mockups of games from other platforms

Post by Bregalad »

If you really want to use the MMC5, be my guest, but please, design your graphics around it to properly make use of the enhancements, and PLEASE, PLEASE test your software on a real MMC5, because this mapper has not been dissected enough to be taken for granted.
Actually that's the very reason I stopped developing anything for MMC5 long ago : I didn't feel the heart to destroy any MMC5 cart just to test my shitty programs :) As a newbe to NES development the MMC5 sounded like the coolest thing, but I've grown up and though that it wasn't that great if I couldn't use all it's capabilities. I like the challenge to do as much as possible with as little as possible.
Post corrected, but my point still stands; even if CV3 doesn't, you could switch into single-screen mirroring when you activate the extended graphics mode, therefore, the size of the extended attribute table would match the size of your nametable
We all agree on this then. Any newcommer to NES will have to learn about frame and VBlank anyways, this is unavoidable, so MMC5 does not make this any more complex than it already is. On the other hand it's top-notch easy to use scanline counter makes it much easier to deal with frame time and VBlank, so I think MMC5 can be easier to handle for a newcomer.

I belive the scheme of having "ExGraphics + NTA" for playfield and "NTB with normal attribute table" for status bar is a perfectly sensible way to use the MMC5's ExGraphics mode. Another way would be to use NTA and NTB for normal scrolling and extended name table for status bar. Just Breed have no status bar, so it does not need any of these schemes, still, the reason it uses vertical mirroring is obscure to me. It's probably simply because the developers couldn't get rid of this tradition.
Post Reply