Scary questions abound. Maybe one day I'll make some actual pixel edits...
My new version below I counted in at 52 sprites, which is a lot, but it's not too much, right? ;] I want it to fit the restrictions, but will push the limits whenever possible.
My sole question is... do you push the limits to the
epic cartridge (MMC5) only a few games used? With its 8x8 region background palettes instead of 16x16, its hardware multiply, and its ability to draw from 16384 tiles at the same time? (Also extra audio and a bunch of stuff... it's kind of a monster.) It's why NES restrictions questions are so tough. There's what NES can do on its own, and then there's what
MMC5 can do. And then there's what a bunch of less terrifyingly powerful boards can do which are somewhere in the middle.
I digress. 52 sprites isn't really bad for the whole scene. Depending on how many animation frames you want for each character, those unique sprite tiles could begin to add up in ROM space, though. Assume without MMC5 that you've got 256 KB for all graphics (sprites and backgrounds) in the game. 256 tiles is 4 KB. There's always more to it, but it's not really worth being concerned until a game is actually being made.
However, I must admit defeat on the 8 sprites per scanline rule. This one hits hard and I don't know any way out of it, I know I basically can't with the way they are posed. Can you tell me about any magic that might would make me feel any better about this?
Nope. Flickering is all you get, 8 sprites per scanline is a limitation even MMC5 can't beat. You could draw one of the characters using the background, but then you can't really have an
actual background. Depending on how iconic his fighting stance is, the really easy thing to do is just have him hold his sword at a 45ish degree angle. Then all the sprites of his sword won't be occupying mostly the same scanlines even disregarding whether or not there are overlays.
I would intend to have mutliple enemy portraits that would show in a similar fashion. Would this mean that all of them would have to be on every tileset? Only Griffith would appear on this background, but many different enemies would appear on multiple different backgrounds.
If you are using tile ROM, the answer is yes. Any time a portrait needs to appear over a background, it needs to be stored with that background. Because the background and the portraits occupy the same scanlines in your mockup. (Unless you're using MMC5, which is often the exception to, "You can't do that.")
You wouldn't need to store the portraits multiple times if the game were using tile RAM. Every portrait could appear with every background with no redundant tiles, even. BUT, if you did that you would have to be much more careful about using ONLY 256 tiles for the entire screen. (I don't know a cartridge offhand that gives you both tile RAM, and the ability to swap out tilesets on a specific scanline. I guess it's a thing that could be built if it doesn't exist, though. )
You mentioned that variable width fonts are possible, how would that be done?
The NES in general doesn't care if it's accessing ROM or RAM. ROM is obviously ROM and can't be written to. RAM can be edited, so you could generate and edit tiles on the fly (with many caveats).
Here are some tiles from Tetris (4X for clarity):
Nintendo decided that for their copyright notice that would look nicer, so they used the extra six tiles despite there also being 26 letters+punctuation+number tiles in that same set. Tetris' tile data is ROM, but if one used tile RAM, one could generate tiles like "Nintendo" above at runtime. Essentially you load the letters from CPU ROM, mash them together and write the result to tile RAM which is then displayed. It's not easy to program, not many commercial games did it, and there are other caveats too. But it's doable. See
RHDE. Some translation patches have actually done a simpler thing where common sets of letters that look bad monospaced just have their own tile. <ll>, <. >, <'t>, <'d> or things like that. RHDE straight up generates everything, which is hardcore.
More specific to your case, assume you have a single row dedicated to pre battle trash talk. (which is actually not quite the case right now, but it makes the example easier.) That's 32 tiles across. It's a good idea to not draw things on the leftmost/rightmost pixels either. (Err... I just realized that sort of affects a lot of your mockup as well >_>. That's the thing about non handheld consoles.
Television Safe Area) So 30 tiles. When you draw the screen, you'd draw that row with blank tile, tiles226-255, blank tile.
You then draw C to tile 226 one frame. You draw a single pixel of A to tile 226, and the rest of the A to tile 227 on the next frame. You draw half of N to tile 227, and the other half to tile 228 on the next frame. And you continue like that. Because you are editing tiles that are already being used to draw the background, they'll appear. For a single row, it's even better that storing the alphabet and looks nicer. 30 unique tiles reserved for variable width font row, vs 26+?!.,'etc.
I also wanted to ask you about the 8x16 sprites. Could they be of any use here or no? I read your description of them in the restrictions guide, but it soared right over my little head.
I basically never recommend 8x16 sprites. That sword is not even a full tile tall. Using 8x16 sprites would ensure that every part of it is now two tiles tall, making even parts of it that would be fully transparent eat into the 8 sprites per scanline limit of things below it. (or above it.) As well, you'd have a significant amount of redundant fully transparent tiles eating up space in your set.
On the top are the tiles you'd have to use in your set of 256 to display the sword parts I removed. Note the 3 totally blank tiles. All those orange and green pixels represent space the sword sprites might occupy in regards to the 8 sprites per scanline limit.
If you hit the 64 sprite limit they can be worth looking into, but they tend to use more tiles in the set to display the same thing as in 8x8 mode. The other benefit of 8x16 mode is they can use less CPU time to draw the same scene. (Half as many "Is this sprite offscreen?" checks, provided all the space is actually occupied.) Hitting the 64 sprite limit isn't necessarily the end of the world anyway, you could "flicker" which sprites are displayed in the 64, the same way you could as if you hit the scanline limitation. (Though it's much harder to reasonably do.)
Admittedly the 8x16 sprite explanation in the post is lacking, but it's really not simple. At some point I want to make an interactive ROM that people can play around with to see the limitations, but it's very low priority.
Of course the dream would be to have a little playable demo on the actual hardware.