Page 12 of 14

Re: Mockups of games from other platforms

Posted: Sun Apr 19, 2015 7:00 pm
by Drew Sebastino
Well, than in my case, wouldn't it be all right for me to use 8x8 attributes? I don't really think of the MMC5 as "cheating" when isn't it just adding more memory or something for the NES to use? Sorry, I'm really uneducated about this sort of thing. :oops:

Re: Mockups of games from other platforms

Posted: Sun Apr 19, 2015 7:02 pm
by tepples
Perhaps someone should mock up a specification for a CPLD that only provides 8x8 attributes and nothing else.

Re: Mockups of games from other platforms

Posted: Sun Apr 19, 2015 7:34 pm
by tokumaru
tepples wrote:Perhaps someone should mock up a specification for a CPLD that only provides 8x8 attributes and nothing else.
This seems to be the aspect newcomer artists have the most trouble understanding (followed by the fact that color 0 is global to all palettes). That's understandable, that limitation looks pretty arbitrary at first, while the number of tiles, number of colors and number of palettes are easier to understand, since they're all numbers.

Where would you store the extra attribute information?

Re: Mockups of games from other platforms

Posted: Sun Apr 19, 2015 7:43 pm
by Drew Sebastino
tokumaru wrote:(followed by the fact that color 0 is global to all palettes).
Really? :shock:

Just thinking about color 0 (even though this is an SNES question) how does the SNES treat color 0 when it comes to transparency? Does it treat it like any other color, or does it ignore it and make the normally transparent thing solid? I noticed on DKC 3 that on the waterfall levels, behind the waterfall is only using 3 colors when it could be using 4. Color 0 is the color not being used.

Re: Mockups of games from other platforms

Posted: Sun Apr 19, 2015 8:39 pm
by Drag
DevEd wrote:Bump.

Decided to do a Shantae mockup:
Image
BTW This is intended for MMC5.
This scene by itself (minus the transparent HUD, I'm sorry, I don't know any way to make that work) looks like it would easily fit within "vanilla" NES limitations, including attribute regions and tile count. The mossy bricks would need to be sprites though, which is perfectly fine, Marble Madness uses sprites to compensate for attribute artifacts.

Also, don't mind all the purists, use MMC5 if you want, it's not cheating and it has everything you'd want in a mapper, plus the graphical enhancements. At this point, the only reason for using a "lesser" mapper (or no mapper) is if you want the challenge.

Re: Mockups of games from other platforms

Posted: Sun Apr 19, 2015 8:44 pm
by Sik
Espozo wrote:Just thinking about color 0 (even though this is an SNES question) how does the SNES treat color 0 when it comes to transparency? Does it treat it like any other color, or does it ignore it and make the normally transparent thing solid? I noticed on DKC 3 that on the waterfall levels, behind the waterfall is only using 3 colors when it could be using 4. Color 0 is the color not being used.
Color 0 is always transparent, no exception. The only way you can use color 0 is as the background color, i.e. what shows up where every layer is transparent (and in the border area too). This is true for the NES too, and the Master System, and the Mega Drive... (amusingly, this is not true for the Game Boy Color for some reason, which uses the color 0 from the corresponding nametable tile instead).

Re: Mockups of games from other platforms

Posted: Sun Apr 19, 2015 10:18 pm
by tepples
tokumaru wrote:Where would you store the extra attribute information?
Same place Gauntlet, Rad Racer II, and Napoleon Senki store their extra nametable data: on a RAM in the cartridge.
Drag wrote:At this point, the only reason for using a "lesser" mapper (or no mapper) is if you want the challenge.
I imagine that in a mockup thread, known ways of bending hardware limits (such as MMC5 ExGrafix) are fair game because copyright takes away the need to optimize your mockup for actually being able to reproduce it. But it becomes important if you want to reuse the overall art style of your mockup (especially its way of conforming to hardware limits) in an original game that you plan to sell on cartridge.

Re: Mockups of games from other platforms

Posted: Mon Apr 20, 2015 12:05 am
by Bregalad
Perhaps someone should mock up a specification for a CPLD that only provides 8x8 attributes and nothing else.
Well I belive you can simulate 16x8 attributes with MMC3 (or another similar complexity mapper) by:
1) using horizontal mirroring
2) using only even rows of tiles (leaving the odd rows "blank")
3) Compressing them by increasing the scroll by 16 lines every 8 lines so that it looks normal on the screen

It sounds like a status bar won't be possible with this configuration, but bi-dimentional scrolling is possible.

However, personally I don't think 16x16 attributes are such a big deal, and I agree with tokumaru that, while it's not a bad idea to use MMC5, if you use it then it should be justified and impressive.

That screenshot does not seems like it would not be possible using normal NES limitations, except the status bar which overlay with background, which is completely impossible because of the 8 sprites per line limitation.

Re: Mockups of games from other platforms

Posted: Mon Apr 20, 2015 12:27 am
by tokumaru
Drag wrote:Also, don't mind all the purists, use MMC5 if you want, it's not cheating and it has everything you'd want in a mapper, plus the graphical enhancements.
Normally I'd agree with you, but the MMC5 in particular is still fairly obscure. AFAIK, a lot of what we know about it is speculation, seems it hasn't been completely reverse engineered yet (people know WHAT it does, but not exactly HOW it does it). It also hasn't been fully cloned or implemented on flashcarts, and there are few donor carts around (and many of the games are fairly expensive), meaning most people can't even test their software properly, let alone manufacture a number of copies for distribution. At the current state, 99.9% of players will only be able to run MMC5 games in emulators.
At this point, the only reason for using a "lesser" mapper (or no mapper) is if you want the challenge.
What challenge is that? If you're trying to port a 16-bit game to the NES, then yeah, doing it on NROM will be much harder than on the MMC5, but for most NES projects people come up with, the MMC5 is absolute overkill. And it's not like setting up the MMC5 and using ExGraphics is piece of cake either, with all the options and modes, and only 1 screen worth of extended attributes regardless of the NT mirroring, stored in a memory that can only be accessed during rendering... does that sound simple to you? How about an artist wanting to code his first NES ROM?
Bregalad wrote:That screenshot does not seems like it would not be possible using normal NES limitations
That's exactly my point: If you look closely, there are a few details here and there that need 8x8 attributes (the leaves in the palmtrees near the trunk and the mossy bricks are the only ones I can spot), but they're hardly noticeable, and could probably be reworked to fit the regular attribute grid, meaning that the MMC5 features are hardly being used.

Re: Mockups of games from other platforms

Posted: Mon Apr 20, 2015 12:53 am
by lidnariq
tepples wrote:Perhaps someone should mock up a specification for a CPLD that only provides 8x8 attributes and nothing else.
The simplest way to get 8x8 attributes that I can think of is: given a game with CHR-RAM, you could define the first four pages (for whatever bank size you use) of that CHR-RAM to contain the attribute table... But that level of complexity is down in "16R4" level, not "XC95xx" level, so there's a lot of room for something more clever.

Re: Mockups of games from other platforms

Posted: Mon Apr 20, 2015 2:11 am
by Drag
tokumaru wrote:the MMC5 in particular is still fairly obscure. AFAIK, a lot of what we know about it is speculation, seems it hasn't been completely reverse engineered yet (people know WHAT it does, but not exactly HOW it does it). It also hasn't been fully cloned or implemented on flashcarts, and there are few donor carts around (and many of the games are fairly expensive), meaning most people can't even test their software properly, let alone manufacture a number of copies for distribution. At the current state, 99.9% of players will only be able to run MMC5 games in emulators.
There haven't been many MMC5 games commercially, so at this point, we wouldn't need exact 1:1 hardware duplication of how the functions are implemented, just as long as the functions are present and consistent. That'll get us through any new homebrews. As for the lack of RE, we can fix that, it's just that nobody feels like doing it right now, and I don't blame them.
tokumaru wrote:for most NES projects people come up with, the MMC5 is absolute overkill.
If the MMC5 makes it easier to code your game, then why not use it? Don't forget that it does more than just fancy graphics.
tokumaru wrote:And it's not like setting up the MMC5 and using ExGraphics is piece of cake either, with all the options and modes, and only 1 screen worth of extended attributes regardless of the NT mirroring, stored in a memory that can only be accessed during rendering... does that sound simple to you?
It's simpler than you think. Castlevania 3 switches into You could switch into one-screen mirroring when it uses you use the extended graphics mode, and the MMC5 has the facility available for detecting the end of vblank so you can start updating the extended nametable memory, and that's only if you don't want to switch extended graphics off, update the memory in vblank as though it were normal ram, and switch it back on.
How about an artist wanting to code his first NES ROM?
That's going to be hard regardless of any of this. :P
tokumaru wrote:
Bregalad wrote:That screenshot does not seems like it would not be possible using normal NES limitations
That's exactly my point: If you look closely, there are a few details here and there that need 8x8 attributes (the leaves in the palmtrees near the trunk and the mossy bricks are the only ones I can spot), but they're hardly noticeable, and could probably be reworked to fit the regular attribute grid, meaning that the MMC5 features are hardly being used.
Don't forget that you can have 256 unique 8x16 sprites with the MMC5, and GBC-compatible amounts of cart-RAM with the MMC5. Plus, there could easily be screens elsewhere in the game that would have more significant benefits from the extended graphics than the screen presented here.

Re: Mockups of games from other platforms

Posted: Mon Apr 20, 2015 2:24 am
by Bregalad
Castlevania 3 switches into one-screen mirroring when it uses the extended graphics mode
Huh? It does not. Or if it does you'll have to tell us where exactly. The game uses few of the MMC5's graphical possibilities, because it originally was made for a VRC mapper, which doesn't have any extended graphics.

Re: Mockups of games from other platforms

Posted: Mon Apr 20, 2015 9:30 am
by rainwarrior
MMC5's extended attributes have become to video mockups what the VRC6 already is to audio. Only a few games used them, mostly only in Japan, and they give the NES a different class of abilities than it normally has. Lots of people love it, because it lets them feel like they're still making "NES" stuff, but it's easier to work with and you can make pretty things, and a lot us wouldn't use it, mostly because it's not at all characteristic of what the NES can normally do.

The MMC5 extended attributes capabilities end up feeling pretty closely aligned with the Sega Master System's capabilities, actually. Personally, I do find it a little strange people so often want to "max out" the NES in this trivial way, when there's similar platforms that have that kind of capability in their typical form. (PC-Engine might be another alternative.)

The other thing that's maybe worth thinking about is that the MMC5 doesn't cost anything to someone who only works with emulators. You don't have to work for it, you don't have to pay for it, you don't have to offer any merits of your own to get this extended capability, you can just take it. In the actual NES era, it was a hefty additional cost per cartridge, not a decision made lightly, and of course, Nintendo first had to actually realize it was possible and build the chip that could do it. Even though Nintendo built the chip, they never saw fit to use it for any of their own games, interestingly enough, and it wasn't because they didn't want those capabilities. MMC5 had a very real cost, and that's why it was so rarely used.

I understand wanting to use it. NES + MMC5 is a retro platform that (marginally) existed in the real thing, and maybe some people enjoy it more when they don't have to work with the attribute limit, or they like having 3 extra channels of sound, or whatever. If you look at it by itself, ignore rarity, history, etc. and just look at what it can do, it's a fun platform to work with, I guess? Not the one I'd choose, but maybe you like it.

I'm just curious, where does the term "ExGraphics" come from?

Re: Mockups of games from other platforms

Posted: Mon Apr 20, 2015 9:55 am
by tokumaru
rainwarrior wrote:MMC5's extended attributes have become to video mockups what the VRC6 already is to audio.
well put.
rainwarrior wrote:I'm just curious, where does the term "ExGraphics" come from?
I don't know... I think it's because of the Extended RAM, which could optionally be used to enhance the Graphics. I don't know if this term is official (probably not), and I can't even guarantee it was actually used by other people... I could very well have "invented" it in this thread... :oops:

Re: Mockups of games from other platforms

Posted: Mon Apr 20, 2015 10:15 am
by DevEd
I made that with NES Screen Tool, which doesn't support MMC5 attribute tables. I photoshopped in the 8x8 attributes, Shantae, and the HUD later. Here's how it looked before I added the 8x8 attributes:
Image

BTWI made the Shantae sprite with NES Screen Tool as well.
Link to image due to lack of a spoiler tag