nesdev.org

I know this is an SNES game (ignore the background) but the lettering on R-type III looks nice and I don't think it is using that many tiles. (More than you are currently, though.)
You just kind of have to go for a stylized look. I think the letters in the DOOM logo look really cool and I don't think that it would take that many individual tiles. (Again, more than you are currently.)

Suggestion 1: Ditch the dialogue/status box boundaries and merge them with the title screen letters; that'll save you enough tiles.
Careful palette trickery could enable you to still have them look the same, at the expense of a palette color there.

Suggestion 2: Center the box-borders in the tiles (saves 2 tiles) and move the corner to sprites so you can use flipping to save more tiles (saves 4 bg tiles, costs 1 sprite tile and 4 on-screen sprites)
(side benefit: If you're doing something with Sprite 0, you can do so with a lower or upper corner.) (bottom/right)

Suggestion 3: Use any of the self-contained blocks as the corners. (saves 4 tiles); if you center the boundaries too then you save two more. (left)
Suggestion 4: if you just plain use "real" BG tiles as boundaries you can ditch all eight. (top)

Of course, the palette wouldn't still be that green one.

Separately, you appear to be over-budget on palettes for the screen I picked; unless you put the boundary-foliage and trunk-corners into the sprite table so you can put dark blue on the foliage/grass palette...but then, you've used all but one sprite palette, too. But it doesn't look like a screen where you'll need them.

There must be a good modular font online that could serve as inspiration to create something interesting that reuses a lot of tiles.

I'm really not familiar with the NES, but couldn't you always put the title screen in a separate bank than the level? Unless you plan on putting this game on a real cartridge, I wouldn't think space would be that big of an issue.

Separately, you appear to be over-budget on palettes for the screen I picked; unless you put the boundary-foliage and trunk-corners into the sprite table so you can put dark blue on the foliage/grass palette...but then, you've used all but one sprite palette, too. But it doesn't look like a screen where you'll need them.

I think the game is supposed to use the MMC5, where, If I'm not mistaken, it should work.

Espozo wrote:I'm really not familiar with the NES, but couldn't you always put the title screen in a separate bank than the level? Unless you plan on putting this game on a real cartridge, I wouldn't think space would be that big of an issue.
[...] I think the game is supposed to use the MMC5, where, If I'm not mistaken, it should work.

All of Alp's demos have been targetting plain NROM:

Alp wrote:...Why would I leave NROM?! O_O
Extreme restrictions, are so much fun! =D

That said, tepples made the point that NROM is actually two 4 KiB banks, and you can swap which is used for backgrounds and which is used for sprites as you wish.
Galaxian, for example, used this to stuff its title screen into the otherwise rather underused sprite bank. (I'm certain many other NROM games did, too.)

What do chips like the MMC5 even do? I know you can have a separate palette for every 8x8 tile instead of 16x16 and some other stuff, but I'm a bit surprised you can do something like this. Probably not, but could you have something like 4bpp graphics on the NES, I doubt it, but it seems like the PPU inside the NES can be upgraded by expansion chips, unlike on the SNES where only the CPU can. (I'm probably not making any sense. )

Espozo wrote:I'm really not familiar with the NES, but couldn't you always put the title screen in a separate bank than the level? Unless you plan on putting this game on a real cartridge, I wouldn't think space would be that big of an issue.

Separately, you appear to be over-budget on palettes for the screen I picked; unless you put the boundary-foliage and trunk-corners into the sprite table so you can put dark blue on the foliage/grass palette...but then, you've used all but one sprite palette, too. But it doesn't look like a screen where you'll need them.

I think the game is supposed to use the MMC5, where, If I'm not mistaken, it should work.

No, the attribute clash requiring per-tile paletting is a separate problem, present in the three-tile-tall ocean and the one-tile-thick green ground-cover.
Pal0: Sky/Chimney/Cloud/Mountain: light blue, grey, black, white
Pal1a: House: Light red, medium red, black, ?
Pal1b: Tree trunk/ground/roof: Dark red, medium red, black, dark blue (at the base)
Pal2a: Grass: Light green, dark green, black, dark blue
Pal2b: Foliage: Light green, dark green, black, light blue (around the edges)
Pal3: Ocean: Dark blue, light blue, white, ? (black for BG)

There are only 4 available BG palette slots, so...

The conflict is because of attempted layering over both sky and ocean. Turning some of those to sprites (1b, 2b) lets you get away with that; as there are unlikely to be enemies here, you can probably afford to use the sprites. (You have to have the grass-against-sea be BG, though, because there are a good 14 tiles of it, far more than the 8 sprites-per-scanline allowed.)

The MMC5 does a lot, but the applicable part here is that it supplies additional PPU-RAM that can be used for either nametables or more-detailed attribute tables, allowing palette choice per 8x8 rather than per 16x16. Less applicable here are mapping ROM banks, multiplication, scanline interrupt, sound channels...

The actual colors in the palettes is the only part of PPU-RAM you can't outsource to the cartridge.

Smaller color areas in MMC5 ExGrafix work because the PPU rereads the attribute byte after fetching each nametable byte. The PPU reads the nametable for the left side of a 16-pixel-wide color area, reads the attribute byte, and applies that attribute value to that 8-pixel-wide cell. Then the PPU reads the nametable for the right side of the same 16-pixel-wide color area, reads the attribute byte again, and applies the value it read the second time to that second 8-pixel-wide cell. This means the MMC5 can change the attribute byte between the first and second reads of the same attribute byte.

The PPU also rereads the attribute byte every scanline. In theory, this allows the Game Pak to provide a separate attribute value for each 8x1 sliver of a background tile, not unlike how attributes work on the TMS9918 family VDP used in the ColecoVision, SG-1000, and MSX. In practice, MMC5 ExGrafix uses 8x8 pixel color areas, not 8x1, to save memory. But you still need the same attribute value for all 8 pixels in each 8x1 pixel sliver of the background plane, so you can't just do 4bpp like you're on a freaking Master System.

Espozo wrote:What do chips like the MMC5 even do?

It watches the memory accessess performed by the PPU, so it knows what the PPU is doing.

I know you can have a separate palette for every 8x8 tile instead of 16x16 and some other stuff, but I'm a bit surprised you can do something like this.

Fortunately, the PPU was designed to read the same attribute bits twice for each pair of tiles. Without any memory extensions, the same value is read twice, but since the MMC5 knows exactly which tile the PPU is rendering, it can provide different attribute bits for the second tile. The other expansions work similarly: you can access 16384 tiles in the same frame (instead of only 256) because the MMC5 knows which tile is being rendered, so it can look up extra banking bits in its own memory (ExRAM). Same thing for the 8KB of sprite tiles: the MMC5 knows if the PPU is rendering background tiles or sprite tiles, so it can temporarily hide the background tiles and make more sprite tiles available. It's all about knowing what memory the PPU is accessing and for what purpose, so the mapper can feed the appropriate extended data.

Probably not, but could you have something like 4bpp graphics on the NES, I doubt it, but it seems like the PPU inside the NES can be upgraded by expansion chips, unlike on the SNES where only the CPU can.

Unfortunately, the bit depth cannot be modified by manipulating memory accesses. The bit depth is internal to the PPU, and the resulting 4-bit pixels are always the result of combining 2 pattern bits with 2 attribute bits, and the attribute bits are only renewed every 8 pixels, so you can't get more than 4 colors in a 8x1-pixel area. You also can't expand the palettes, because the colors are stored inside the PPU itself, meaning the mapper can't feed it manipulated data.

The PPU can't really be upgraded, but a lot of its work is based on reading data from external memory (name tables, attribute tables, pattern tables), and NES cartridges can optionally disable the internal VRAM and route PPU memory accesses to the cartridge, where the mapper can have full control over this memory. As long as the mapper can keep track of what the PPU is doing at all times, it can manipulate that memory according to different parameters and make it seem like the PPU is able to access more memory than usual.

Don't forget being able to use raster effects like in Fighting Road (at least that's what it looks like to me, especially with the areas covered by each palette). Another trick if you can afford to have less colors is to use 1bpp graphics (to store two tiles in the space of one) and then different palettes to choose which of the two graphics in a tile to show.

Espozo wrote:I know this is an SNES game (ignore the background) but the lettering on R-type III looks nice and I don't think it is using that many tiles. (More than you are currently, though.)

That's eating up quite a lot actually. OK, you could probably reduce the tile count by simplifying the gradient, but still.

Sik wrote:Don't forget being able to use raster effects like in Fighting Road (at least that's what it looks like to me, especially with the areas covered by each palette).

The title screen doesn't use any raster effects (checked). It's just the four palettes and some dithering.

Oh well =/ The idea of using raster effects to give some small slant to the graphics still stands (since you could do that to save some tiles)

Sik wrote:Don't forget being able to use raster effects like in Fighting Road (at least that's what it looks like to me, especially with the areas covered by each palette). Another trick if you can afford to have less colors is to use 1bpp graphics (to store two tiles in the space of one) and then different palettes to choose which of the two graphics in a tile to show.

Espozo wrote:I know this is an SNES game (ignore the background) but the lettering on R-type III looks nice and I don't think it is using that many tiles. (More than you are currently, though.)

That's eating up quite a lot actually. OK, you could probably reduce the tile count by simplifying the gradient, but still.

I meant the letters, not the space background

I was talking about the letters, they still have some important gradienting and the gradients are unique to each letter.

OI! Had some computer troubles, couldn't post for a bit.

Oh, oops! I hadn't realized that I hadn't gone back to optimize that town shot. Heh.
How is this, for the two issues? I merged a few of the palettes.

For the title screen, I removed six redundant tiles, and used the free space to add a gradient strip. I also re-organized the colour palette to make it more interesting.