This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Meta tiles in screen-by-screen-scrolling games

Meta tiles in screen-by-screen-scrolling games
by on (#241136)
Out of curiosity, what's the way games that only scroll screen by screen (or don't scroll at all and simply switch to the next screen) usually store their level data/meta tiles?

I know in "The Legend of Zelda", each screen is made up of 16 "stripes"/columns of graphics data. Each stripe has a one-byte ID, so there are up to 256 possible stripes and therefore, each screen occupies exactly 16 bytes as far as the pure background graphics are concerned.
Hence, the way tiles can be placed vertically is severely limited.

I've also heard of level data that is made up of meta tiles that are 16 x 16 or 32 x 32 pixels.

So, my question: Are all of these screen-by-screen games made up like puzzles, where the meta tiles all have a global size and you simply list all meta tiles one after another?


Because in my game, I'm using a slightly different approach:

My meta tiles can have an arbitrary tile size (as long as the width and height each is a multiple of 2 because the NES can only assign colors to 2 x 2 tiles).
Each meta tile is assigned to only one palette.
And when putting the meta tiles on screen, you have to set the x and y position (0-15 for x, 0-14 for y, both stored in the same byte) and the meta tile ID.


So, games who always use, for example, 32 x 32 pixel meta tiles are like a puzzle: They know their screen consists of 8 x 8 puzzle pieces and they simply list all pieces one after another, without the need for an x and y coordinate.

My version works like stamps: The screen is first filled with the background pattern. And then I can put objects (like a house or a tree or a stone) at any location I want.
I can put stones in any formation I want. I'm not limited to a bunch of meta tiles that have stones in certain formations in them and for every new formation, you would need to waste another meta tile.
So, I don't need to store meta tiles for:
Three sand floor tiles and one stone tile.
Two sand floor tiles and two stone tiles.
Three rocky floor tiles and one stone tile.
Two rocky floor tiles and two stone tiles.
I simply place the stones (which is one meta tile) wherever I feel like on a screen.
Also, if my stone is 32 x 32 pixels, it doesn't need to be aligned to 32 x 32 pixels, it can still be placed on any 16 x 16 pixel position.

Are there any other games that use my approach? Or what other alternatives are there?

Also, how do games like "Link's Awakening" and "Final Fantasy Adventure" store their screens?
Re: Meta tiles in screen-by-screen-scrolling games
by on (#241139)
Some games, besides a basic metatile system, also have a list of objects that it has a recipe for drawing... let's say a tree object, and you need 2 bytes per tree on screen*... 1 to say "tree" and one for XY coordinates for the starting point.

*where the actual tree is irregularly shaped and could be 6 tiles wide by 8 tiles high (for example)
Re: Meta tiles in screen-by-screen-scrolling games
by on (#241150)
Which games do this?
Re: Meta tiles in screen-by-screen-scrolling games
by on (#241151)
Each game has it's own functioning and you can't generalize. Your system seems similar to the "object" system used in many Nintendo games, where metatiles are replaced with objects of variable size. Other games will simply use fixed size metatiles, or meta-metatiles. There's no such thing as a "rule" that can be made from many games.

Also whether the game is scrolling or is screen-by-screen is completely independant/orthogonal to wether it uses object system or metatiles system.
Re: Meta tiles in screen-by-screen-scrolling games
by on (#241154)
Bregalad wrote:
Each game has it's own functioning and you can't generalize.

In my case, I'm mostly talking about those top-down games. Because a game like "Super Mario Bros." with a fixed ground has other necessities to buildup a screen than a "Zelda"-like.

Since you cannot generalize, I wanted to talk about some best practices from actual games.

Bregalad wrote:
Also whether the game is scrolling or is screen-by-screen is completely independant/orthogonal to wether it uses object system or metatiles system.

Not necessarily. If you have an object-based approach with x and y coordinates, it might be problematic to load the graphics gradually as you move along. In this case, a column- or row- or fixed rectangle-based meta tile system is probably better. I mean, if I have my data stored like this:
5, 3, House
1, 1, Stone
12, 3, Bush
how would one load this during fine scrolling? It's surely doable, but more complicated.
(For example, the meta tile size isn't even in there. So, if you scroll left, you have to read through all meta tiles every frame and lookup their definition to decide whether the x position + the width is in your new drawing area.)
However, it's not a problem at all if you only scroll screen by screen since you update the whole screen before scrolling.
If my game had "live scrolling", I would probably have stored the graphics in a linear way, so that I can read them out of an array with offset coordinates.
Re: Meta tiles in screen-by-screen-scrolling games
by on (#241156)
Indeed, but Super Mario Bros still have an object-based system with scrolling. However if I'm not mistaken the object are sorted in appearing order (by X coordinate) and converted to metatiles on the fly as the player progress. This only works because the scrolling is unidirectional and with no backtracking. (This must be proofreader - I'm not familiar with how SMB works internally, despite having analyzed the disassembly)

Doing an object-based system with more complicated scrolling and/or with arbitrary object storage order would basically involve decompressing an entiere level to RAM into metatiles as a first step.

EDIT: All I can say is that my own game engine for an screen-by-screen action-RPG uses 32x32 meta-metatiles, made each of 4 16x16 metatiles. The screen is made up of 8x6 meta-metatiles, and the rest (4 lines) are dedicated to the status bar (but only 2 lines are actually used, the other 2 lines being blank). There's also 2 lines of overscan which is also blank. The maps are then RLE compressed with meta-metatiles to take even less space. I don't use object or variable-size metatiles at all. For games I really can't say but I'd recommend to look-up on the romhacking wiki, if people made the effort there is information about the inner working of many games. But this is of course largely incomplete.
Re: Meta tiles in screen-by-screen-scrolling games
by on (#241162)
Quote:
I'm not familiar with how SMB works internally, despite having analyzed the disassembly


The disassembly isn't very good for understanding the object system.

Basically, at the start of the level it gets a pointer to level data (and a separate pointer for Sprite objects). One of the bits (I can't remember) means something like "this goes on the next room over". So it fills a room buffer (with 16x16 metatiles) until it sees the "next room" bit set.

And another system converts metatiles into screen tiles on the fly.
Re: Meta tiles in screen-by-screen-scrolling games
by on (#241713)
Personally, I use a grid of say 16x12 2x2 patterns metatiles, but I use RLE compression and a limited tile count, say 16 or 32 metatiles. That way I can use a single byte to represent a run of tiles, using 4 or 3 bits for the run length. Besides, my renderer first decompress the RLE stream to a buffer, and then it iterates through the buffer to alter the decompressed tiles so I can add decorations. For example, I can make a block of rock tiles but the renderer inserts random variations using tiles which are not in the tileset. Using a proper seed the output is always the same. I also make the renderer "auto-complete" stuff like vertical stripes: if I need a column I just add the top of the column to the map data, and the renderer takes care of completing the column. That way I can get much better compression.

I'm coding a game for my kid right now. It's a nice platformer which I intend to make fit in a NROM cartridge. I have 10 levels right now (around 180 screens) and I still have space for more, so this approach kinds of work and is not very restrictive.