Hi guys, I've been thinking about the reasoning behind different systems of organizing your backgrounds/level data and I'm looking for a simple method I can use for a platformer. As such I have a lot of random questions so please forgive the length.
I'm kind of going off of this topic which has excellent info but I thought the subject was different enough to start a new one.
The basic 2x2 metatiles have obvious memory-saving advantages. There aren't many NES games that don't have 16x16 pixel blocks repeated all over the place. It would be easy to stuff a lot of those together, RLE it and call it a day, though that wouldn't be efficient at all. (Or would that be sufficient for a 4 to 8 level demo/game?)
Anyway I'm having a hard time figuring out how I'd put larger metatiles to good use without sacrificing a lot graphically. 32x32 blocks would probably still have a lot of repetitions, but the larger you get the less I see the point. Isn't the main point of metatiles to use repeatable data more than once? How often am I going to repeat 64x64 or 128x128? I understand reused screens the way Mario does it for each flagpole for example, but simply using big blocks while also trying to keep the level layout unique seems needlessly difficult for only mediocre savings.
When people say they have metatiles of metatiles of metatiles, what do they mean? I guess the first thing I picture is this:
Which is clearly wrong and not the way most games appear to do it. We need the flexibility to place graphics wherever we need them and in a typically complex screen there is no repeated data on the largest metatile size. On closer inspection I see this:
But this introduces even more complexity. Now we have 64x64 blocks mixing with 32x32 blocks, so we have to keep track of additional size/coordinate data rather than letting the sequential data be enough, much like an object based system. Again, are the savings worth the effort?
I understand that this example is probably flawed since CV3 is a complicated game made late in the NES's life, but it's representative of what I'm trying to understand: the memory savings vs. map decoding complexity.
What about priority systems for background graphics - was it ever common to overlay metatiles on top of each other? For example, writing in a metatile of a statue and overwriting the bottom of it with plant growth a few lines later. The thought occured to me seeing the two small windows near Trevor with one mostly covered.
I have seen from a lot of topics here that you don't usually store every tile of every screen; it makes sense for a level to have a default screen that is then modified. You can seen this when you jump over the flagpole in Mario and you can keep walking forever. Or like this screen of Kirby:
repeats
That doesn't seem too hard to implement.
Do games use "vector" methods to store backgrounds? For example in that Kirby screen, does the code detect the top of one of those thin poles and extrapolate it to the ground? Or in this Mario screen,
Is the slant defined by its height, and the top becomes the new "ground level" with a grass fill below it?
Finally, would it be worthwhile to keep a copy of the current screen decoded into RAM on a 16x16 level? (Meaning, with status bar taken into account, probably 192 bytes.) It would essentially be for checking collisions or recording changes that need to be made during VBLANK.
I'm kind of going off of this topic which has excellent info but I thought the subject was different enough to start a new one.
The basic 2x2 metatiles have obvious memory-saving advantages. There aren't many NES games that don't have 16x16 pixel blocks repeated all over the place. It would be easy to stuff a lot of those together, RLE it and call it a day, though that wouldn't be efficient at all. (Or would that be sufficient for a 4 to 8 level demo/game?)
Anyway I'm having a hard time figuring out how I'd put larger metatiles to good use without sacrificing a lot graphically. 32x32 blocks would probably still have a lot of repetitions, but the larger you get the less I see the point. Isn't the main point of metatiles to use repeatable data more than once? How often am I going to repeat 64x64 or 128x128? I understand reused screens the way Mario does it for each flagpole for example, but simply using big blocks while also trying to keep the level layout unique seems needlessly difficult for only mediocre savings.
When people say they have metatiles of metatiles of metatiles, what do they mean? I guess the first thing I picture is this:
Which is clearly wrong and not the way most games appear to do it. We need the flexibility to place graphics wherever we need them and in a typically complex screen there is no repeated data on the largest metatile size. On closer inspection I see this:
But this introduces even more complexity. Now we have 64x64 blocks mixing with 32x32 blocks, so we have to keep track of additional size/coordinate data rather than letting the sequential data be enough, much like an object based system. Again, are the savings worth the effort?
I understand that this example is probably flawed since CV3 is a complicated game made late in the NES's life, but it's representative of what I'm trying to understand: the memory savings vs. map decoding complexity.
What about priority systems for background graphics - was it ever common to overlay metatiles on top of each other? For example, writing in a metatile of a statue and overwriting the bottom of it with plant growth a few lines later. The thought occured to me seeing the two small windows near Trevor with one mostly covered.
I have seen from a lot of topics here that you don't usually store every tile of every screen; it makes sense for a level to have a default screen that is then modified. You can seen this when you jump over the flagpole in Mario and you can keep walking forever. Or like this screen of Kirby:
repeats
That doesn't seem too hard to implement.
Do games use "vector" methods to store backgrounds? For example in that Kirby screen, does the code detect the top of one of those thin poles and extrapolate it to the ground? Or in this Mario screen,
Is the slant defined by its height, and the top becomes the new "ground level" with a grass fill below it?
Finally, would it be worthwhile to keep a copy of the current screen decoded into RAM on a 16x16 level? (Meaning, with status bar taken into account, probably 192 bytes.) It would essentially be for checking collisions or recording changes that need to be made during VBLANK.