MMC1-5 Graphic Limitations

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

Moderator: Moderators

User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: MMC1-5 Graphic Limitations

Post by tokumaru »

Like tepples said, sprite flicker is not automatic. Every scanline, the PPU searches through a list of 64 sprites (OAM) looking for the ones it must display, from slot 0 to slot 63. When it finds 8 sprites, it simply stops looking, so any sprites after that are not visible all.

This means that lower numbered sprites have higher priority, and higher numbered sprites have lower priority. Programmers explicitly cycle the priorities of the sprites every frame so that different sprites are dropped each frame, and this is what causes flicker.
WizardBones
Posts: 33
Joined: Mon Sep 12, 2016 7:41 pm

Re: MMC1-5 Graphic Limitations

Post by WizardBones »

Very cool. OK so I hate to beat a dead horse, but I'm trying to give myself a "guideline template" if you will, to work within.
This is obviously a dumb down over look, but hopefully serve as a kind of reference guide for someone more interested in the art limitations and not deep understanding of specs. So forgive me, and all corrections of my ignorance is welcome : P

256 tiles for movable sprites.
256 tiles for background.
Sprites can be built with 8x8 or 8x16 pixels, depending on preference.
128 total visible tiles on screen at a time.
More than 8 on the scan-line will result with flickering. decent to keep in mind when thinking about level design and how not to piss players off : )

Depending on hardware and programmer, you can rewrite CHR RAM mid-level. Which means you can have more sprites if you need? So with rewriting in mind, would it be safe to say, an artist could draw 512 movable sprite tiles, and 512 background tiles that could be used in the game?
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: MMC1-5 Graphic Limitations

Post by tokumaru »

WizardBones wrote:Sprites can be built with 8x8 or 8x16 pixels, depending on preference.
It's worth noting that this setting is universal, you can't mix 8x8 with 8x16 sprites, it's either one or the other.
128 total visible tiles on screen at a time.
This is for sprites, if you use all 64 8x16 sprites.
Depending on hardware and programmer, you can rewrite CHR RAM mid-level. Which means you can have more sprites if you need?
CHR-RAM can be changed mid-level, but it's slow and not many programmers are willing to deal with the complications. Alternatively, a mapper like the MMC3 can instantly switch chunks of 64 or 128 tiles at a time, and this was commonly used for animating backgrounds or a select number of objects (mainly the player).
So with rewriting in mind, would it be safe to say, an artist could draw 512 movable sprite tiles, and 512 background tiles that could be used in the game?
If you're gonna be rewriting CHR-RAM or bankswitching CHR-ROM, the total number of tiles you can have is only limited by the final ROM size. These numbers you have are actually quite small considering that many games had 128KB (8192 tiles) or 256KB (16384 tiles) of CHR.
WizardBones
Posts: 33
Joined: Mon Sep 12, 2016 7:41 pm

Re: MMC1-5 Graphic Limitations

Post by WizardBones »

If you're gonna be rewriting CHR-RAM or bankswitching CHR-ROM, the total number of tiles you can have is only limited by the final ROM size. These numbers you have are actually quite small considering that many games had 128KB (8192 tiles) or 256KB (16384 tiles) of CHR.
Ah yes, I just tried to keep a small number for beginners. But thanks for your input good sir : ) Think there is anything missing? For an artist to keep in mind or should be concerned about?
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: MMC1-5 Graphic Limitations

Post by tokumaru »

At the moment, I can only think of limitations related to scrolling. Are you planning on scrolling? In how many directions? How big will leveled be?
WizardBones
Posts: 33
Joined: Mon Sep 12, 2016 7:41 pm

Re: MMC1-5 Graphic Limitations

Post by WizardBones »

Actually, I assume it is scrolling yes. In the question I mention ghostbusters II, that is because, the first two levels are similar to how I plan on my first two levels. One level is "run and gun" - go left or right, and the second level you are in a car, still the basic same type of scrolling? That's my starting point for sprites. I would like to mention, because I like seeing it, is anything complicated involved when you see inside a house like Friday the 13th? Maze-like walls. I wouldn't mind a couple parts like that, but that is just ideas floating for later.

Edit: I did think of something to ask, how about overlapping tiles? is that common? It's something to think about while designing tiles and how they will fit together as a sprite.
User avatar
Myask
Posts: 965
Joined: Sat Jul 12, 2014 3:04 pm

Re: MMC1-5 Graphic Limitations

Post by Myask »

inside a house like Friday the 13th
Perspective walls? It's "complicated" as you aren't just copying a tilemap so much as deciding what to copy. Art-wise…well, I haven't
Anything missing?
Palette limitations.

Background tiles can have one color shared between all, and each 16x16 grid square can have one of the four palettes, each of which has three other colors.

Similarly, sprites all have transparent and their own separate four three-color palettes. (Each sprite picks one palette.) Of course, these don't have to be aligned to any grid.

These colors are drawn from the…52? colors total that the NES PPU allows. I don't have the palette handy, as they tend to vary by TV.

You can overlap sprites (Megaman does this to give his face extra colors, using sprites with different palettes) but it counts no less against the per-line and total spritelimits.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: MMC1-5 Graphic Limitations

Post by tokumaru »

Scrolling doesn't impact the design of the graphics very much, but scrolling in multiple directions can be complicated, and some programmers may ask artists to design the levels in more specific ways in order so the scrolling code can be simpler. If you plan to scroll in one axis only (either horizontally or vertically, never diagonally), you don't have much to worry about.
how about overlapping tiles? is that common? It's something to think about while designing tiles and how they will fit together as a sprite.
It's not particularly common because of the 8 sprites per scanline limit, which is met quicker if you start stacking many sprites.
WizardBones
Posts: 33
Joined: Mon Sep 12, 2016 7:41 pm

Re: MMC1-5 Graphic Limitations

Post by WizardBones »

That true! how can we forget the color palettes! lol I have that stuff stored in my brain now, should have thought to put it here.
WizardBones
Posts: 33
Joined: Mon Sep 12, 2016 7:41 pm

Re: MMC1-5 Graphic Limitations

Post by WizardBones »

tokumaru wrote:Scrolling doesn't impact the design of the graphics very much, but scrolling in multiple directions can be complicated, and some programmers may ask artists to design the levels in more specific ways in order so the scrolling code can be simpler. If you plan to scroll in one axis only (either horizontally or vertically, never diagonally), you don't have much to worry about.

It's not particularly common because of the 8 sprites per scanline limit, which is met quicker if you start stacking many sprites.
Yeah I wanna just side to side anyway, should make things easier.

As of now, the sprites are gonna be stacked together, but I was thinking about a run cycle, the top of the body being 2 tiles and the bottom of the body being 2 tiles, and they meet in the middle making 3 tiles tall, and 2 tiles wide perhaps. From an animation point it would be ideal for me because I always connect my legs with the torso to fit that way lol but before I do it, i'd like to know if thats a pain in the ass to work with lol.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: MMC1-5 Graphic Limitations

Post by tepples »

WizardBones wrote:Depending on hardware and programmer, you can rewrite CHR RAM mid-level. Which means you can have more sprites if you need? So with rewriting in mind, would it be safe to say, an artist could draw 512 movable sprite tiles, and 512 background tiles that could be used in the game?
Yes. Haunted: Halloween '85 has a sprite page with 512 different 8x16 pixel sprite tiles, though only about 416 are used. And each of its levels has 300 to 500 8x8 pixel background tiles, though the data conversion tool ensures that more than 256 aren't used on the same 264-pixel sliding window (1 full screen width plus 1 partially displayed tile).
WizardBones
Posts: 33
Joined: Mon Sep 12, 2016 7:41 pm

Re: MMC1-5 Graphic Limitations

Post by WizardBones »

tepples wrote: Yes. Haunted: Halloween '85 has a sprite page with 512 different 8x16 pixel sprite tiles, though only about 416 are used. And each of its levels has 300 to 500 8x8 pixel background tiles, though the data conversion tool ensures that more than 256 aren't used on the same 264-pixel sliding window (1 full screen width plus 1 partially displayed tile).
Thanks for that, I been wondering what kinda sprites people have been working with. Very interesting stuff.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: MMC1-5 Graphic Limitations

Post by tokumaru »

WizardBones wrote:I was thinking about a run cycle, the top of the body being 2 tiles and the bottom of the body being 2 tiles, and they meet in the middle making 3 tiles tall, and 2 tiles wide perhaps.
You can do that, but keep in mind that in the section where the top and the bottom overlap you're gonna have 4 sprites sharing the same scanlines, and that's half of your entire budget for a scanline, used by a single character. This is not necessarily bad, many games use a lot of sprites in a single character... Astyanax for example, when player attacks with the axe, its graphics use up to 7 sprites in some scanlines, leaving only 1 for everything else! Just be aware that this can greatly increase the presence of flickering.
WizardBones
Posts: 33
Joined: Mon Sep 12, 2016 7:41 pm

Re: MMC1-5 Graphic Limitations

Post by WizardBones »

tokumaru wrote: You can do that, but keep in mind that in the section where the top and the bottom overlap you're gonna have 4 sprites sharing the same scanlines, and that's half of your entire budget for a scanline, used by a single character. This is not necessarily bad, many games use a lot of sprites in a single character... Astyanax for example, when player attacks with the axe, its graphics use up to 7 sprites in some scanlines, leaving only 1 for everything else! Just be aware that this can greatly increase the presence of flickering.
This is true, I think I'm still underestimating the scanline budget. lol I spent most of last night re designing the tiles to stack instead of layer. I'm finding it's working out better that way, I'm using less tiles (done a lil adjusting so a lot more tiles are duplicates.) Liking it better than the layered sprite first planned : )
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: MMC1-5 Graphic Limitations

Post by tokumaru »

WizardBones wrote:I think I'm still underestimating the scanline budget.
4 sprites per scanline on 1 object/character isn't so bad... even Mega Man has frames with 5 sprites on the same scanlines due to the overlaid face. I usually limit my own characters to 4 tiles per scanline, but I try not to worry too much if I have to use 5 or even 6 on some occasional frames. Another game that got away with using a lot of sprites per scanline is Felix the Cat... not only Felix can use all sorts of vehicles and attacks that consume a lot of sprites, but the game can only display 7 sprites per scanline instead of 8, because it uses a tall column of solid black sprites on the far right of the screen to hide background scrolling glitches!
Post Reply