iNCEPTIONAL wrote: ↑Tue Jun 28, 2022 2:33 am
And, just to check, does that single tilemap name/entry cover the entire tilemap then (2 bytes for a whole tilemap), or is that actually 2 bytes per tile in the tilemap to move its position vs 16-32 bytes per tile if I were to load in new tiles, so moving a tile's position is really only about 8-16 times more efficient than loading in a brand new tile?
Note: My game is running in Mode 0, so it's going to be those 2bpp tiles.
I think it's good to know, as an artist, roughly how the tilemap and tileset works together so I'm going to explain that.
The tilemap (AKA the "nametable") is basically just a list (although we imagine it as a 2D grid) of tile "names". Each tile pattern in the tileset (AKA the "pattern table") has a unique "name" (though it's really a number but it's called a "name") used to refer to it and this is what you write in the tilemap to determine what tile will appear where on the screen (that's why it's also called a "nametable"). The first entry in this list determines the top-left tile, the second is the tile to the right of that and so on until the last name entry which is the bottom-right tile on the screen. There are also some other attributes (which palette it uses and display priority) stored in each tilemap entry but it forms a single number value (2 byte in size).
Here is a simplified tilemap model:
Code: Select all
tileset (descriptions only):
grass (0), tree (1), bush (2), flower (3), rock (4), water (5)
tilemap:
0 3 0 0 0 5 0 0
0 0 1 0 0 5 0 4
0 3 0 0 5 0 1 0
0 2 0 0 5 1 0 0
0 0 5 5 0 0 3 0
0 0 5 0 2 2 2 0
In the above 8x6 tiles sized tilemap you can see that there are a lot of grass and a river that divides the map in two parts. There are also some rocks, trees, flowers and bushes. Note that I skipped the other attributes in this simplified model. This tilemap only contains names, no other attributes.
The tileset data is not represented here but I wrote out what the tiles in it are supposed to look like in this model. The numbers in parenthesis are the names of the tiles and the tilemap is just a grid with these names so it's easy to switch out a tile by overwriting a new name in an entry of the tilemap grid. If you want a flower in the top-right corner just write a "3" there and it will instantly change.
The tileset however contains the pixeldata for each tile. Each tileset entry is 16 bytes (for 2bpp) and to draw a new tile pattern in the tileset you have to write over all 16 bytes with your new pixel data. If you do that it will affect the tilemap as well though, say that you don't want the water tile so you overwrite it in the tileset so that it now looks like a brick tile. Now the river in the tilemap will instantly become a brickroad since there no longer is any pixel data for the water tile. Tile 5 now looks like a brick tile.
The SNES can have up to 4 screen-sized tilemaps in a 2x2 grid. This makes it very easy to scroll in any direction without any garbage showing up as tilemap entries are changed out since it's all done outside of the screen.
As for the "cost" of changing tilemap entries it is really trivial like everyone are saying so you don't normally have to worry about it. It was actually fully doable on the NES (which was created in an era when scrolling games was still not common) so it's definitely not something you have to worry about on the SNES. Scrolling games was standard in the 16-bit era and the SNES is both much faster and has more video RAM than the NES.