A Question on Tileset Dimensions & NES Hardware Limitations

When playing around with my own tile-sets and the tile-sets of AdvenTutorial, the first thing I noticed was how inefficient AdvenTutorials tile-sets are with space. That's not a criticism of the assets, but merely an observation of their dimensions. For example, the regular brick floor that Joe uses in the underground can be reduced to just a 16x8 tile. This is not the only tile of that set that can be cut in half horizontally or vertically, or further reduced to just 8x8. Now, when selecting and defining tiles in the asset editor it gives me the option of a width of 1-15 and a corresponding number for a tile's height. 1 in this instance is 16 pixels.

So my question (and preemptive follow-up) is:

• Is it a hardware limitation of the NES that background tiles MUST be stored on the ROM symmetrically with how they are displayed on the screen in divisions of 16x16 tiles? If this is not the case and 16x16 on-screen tiles can be formed and stitched together with as little as a single 8x8 section on the ROM, then are there any performance issues and so forth in doing so?

If not, it would be a nice tile space optimization feature to have if we are able to reduce duplicates and partition our 16x16 tiles into 8x8 or 16x8 or 8x16 sections that are defined and stitched together in the asset editor as 16x16 tiles or whatever dimensions we may like for an asset.

I'm one of these hopeless cases who starts something with very minor alpha\pre-alpha optimization because my future self will be very grateful that I did.

Reason for Edit: Clarified the follow-up question.

Is it a hardware limitation of the NES that background tiles MUST be stored on the ROM symmetrically with how they are displayed on the screen in divisions of 16x16 tiles?

Click to expand...

The NES has a map of 8x8 tiles. On this map, 16x16 regions of it have defined regions of color. (That is to say that 2x2 groups of tiles must share the same group of color.)

In memory are 256 8x8 tiles the map can use to draw. So what this means in usual cases is that:
1. You can only have 256 unique 8x8 tiles on screen.
2. Each 16x16 pixel area on screen must share the same group of four colors.
3. There are four groups of four colors to choose from. One of the colors must be the same in all four groups. A way to think about this is you get four groups of three colors plus transparency. Transparent will end up as the same color in all groups, though, because nothing is drawn behind the background and it doesn't overlap itself.

Beyond color, NES doesn't care at all about what you're doing at 16x16 or any scale beyond 8x8. And you can break all three of the above rules, even.

You do have to store 8x8 tiles multiple times in the 256 tile tileset even if they are symmetrical, but that's it. For example, if you wanted to display this 16x16 image using the background:

You would need to use four unique tiles, even though the corners are symmetrical. If you wanted to display the same image using sprites, you would need just one tile because sprites CAN be flipped.

So "Is it a hardware limitation...?" No. The only thing that might be considered one is if you wanted to put two 8x16 "tiles" next to each other, but both required a different group of colors. You couldn't do this (usually), one would be colored wrong. And this is why things in NES games are often broken down into 16x16 tiles, but so long as colors aren't a concern it's not required.

are there any performance issues and so forth in doing so?

Click to expand...

This post may be interesting to you: http://nesmakers.com/viewtopic.php?f=2&t=94&start=20#p3686
It's less a performance concern and more of a space concern.

Kasumi said:

This post may be interesting to you: http://nesmakers.com/viewtopic.php?f=2&t=94&start=20#p3686
It's less a performance concern and more of a space concern.

Click to expand...

Kasumi, thank you very much (once again) for your in-depth explanation on this.

And I've had a look at your thread prior to this thread. Space is less a concern for me at the moment, but I'm sure It'll become one for me eventually. It's why I asked the question above, before hitting that wall.