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

Background attribute: inside the metatile or not?

Background attribute: inside the metatile or not?
by on (#42345)
While making my map editor I ended up with this issue: where should I really put the background attribute?

If my metatile is 2x2, then this mean that if I put the attribute there, only 2 bits are set and I will need to build the rest of the background attributes from the surrounding tiles, creating overhead.

In the case of a 4x4 one it would not be an issue but still how much would I really save by putting it inside the metatile?

I guess other people had the same dilemma (or not). How did you approach it?

edit:

Once my editor will be in a usable state enough, I will show some screenshots and put a sample of the application. Maybe other people could find that application useful.

by on (#42346)
I haven't fully understood your question, but it's good to try to find a sheme where all bits are used. For example when only 2 bits are used for attribute in your metatile definition you might consider using 2 other bits for collision detection and the remaining 4 bits for something else. It would be a little stupid to have all your attribute definitions included between $0 and $3 and waste the other 6 bits.

In my current engine I use a format where I make 2x2 metatiles (but without any more information than what tiles they use) and use 4 of them them to make 4x4 big metatiles. Color numbers and collision flags goes into the 4x4 definitions, but I could probably have come up with another system where they are assiociated with 2x2 metatiles, it's just that in this case it simplified the code as I could direcly copy the attribute byte to the PPU without spliting it in 2-bit areas.

by on (#42348)
Maybe I will rephrase a little bit my question: do people always put the background attribute with their metatiles or they use just a simple array for that information?

You answered my question in a way. In your engine, attributes are always with the metatile. Does most people do this?

by on (#42352)
Super Mario Bros. has four tables to translate metatiles to hardware tile numbers: one for metatiles $00-$3F, one for $40-$7F, one for $80-$BF, and one for $C0-$FF. The upper 2 bits select both which table is used and which attribute is used.

by on (#42358)
Banshaku wrote:
Maybe I will rephrase a little bit my question: do people always put the background attribute with their metatiles or they use just a simple array for that information?

You answered my question in a way. In your engine, attributes are always with the metatile. Does most people do this?


I actually have a separate array in ROM for metatile attribute data. The first byte is the attribute for metatile 0, the next one is for metatile 1, etc. But I plan to use the other 6 bits to indicate metatile type, because like Bregalad said, it's a big waste to only use 2 bits and leave the other 6 untouched.

The reason I have them separated is so I can have as many unique 16x16 pixel metatiles as possible (in my case, 256 per room), so I don't have to sacrifice bits in metatile IDs to have attribute data. I have 32x32 pixel metatiles which are made of 4 16x16 pixel metatiles, and I don't want to dedicate 2 bits to attribute data for these 16x16 pixel metatiles which make up the 32x32 pixel ones. That would leave me with only 64 possible 16x16 pixel metatiles to choose from, which just isn't enough for me.

by on (#42367)
So it seems it could be a case per case thing. My goal for my editor is that it could be used for making more than one game so I try to be make it as generic as possible.

So I will have to rethink a few things regarding my data model, to be able to make metatile out of metatile and how to handle background attribute properly. It still in it's early stage (I can only put 1 hour once in a while on it) so I can still change what it will do and how.

If people have any comment about what they would like to have as a feature if they had their own editors, I'm all ears. Other people comment will make me see things that I may have missed and could need later myself .

by on (#42383)
Your editor sounds good. I currently do everything with .db statements because it would take me much more time to try to figure how to do a nice editor with a GUI than to just do it with .db statements.

If it would be the more flexible, the better it is. 32x32 metatiles are good for non-Mario action games, but 16x16 metatiles are good for RPGs so if we could chose among those sizes it would be great. Also I belive 32x16 meatiles exists too but are less common.

by on (#42385)
Bregalad wrote:
Your editor sounds good. I currently do everything with .db statements because it would take me much more time to try to figure how to do a nice editor with a GUI than to just do it with .db statements.

If it would be the more flexible, the better it is. 32x32 metatiles are good for non-Mario action games, but 16x16 metatiles are good for RPGs so if we could chose among those sizes it would be great. Also I belive 32x16 meatiles exists too but are less common.


Yes, it does take quite some time to make a good editor. But I really want one so I decided to shift my priorities to this only. If I'm successful, I will be able to make a few small game very fast so the return on investment will be worth it.

For now it support 2x2 (16), 4x4 (32) and 8x8 (64) metatile. I tried to keep it a power of 2. Since it seems common to make metatile out of metatile I will add this feature soon. I tought only 1 metatile deep was enough but it seems not.

I want to make it as flexible as possible since I want to make all kind of games with it. Here how it will work:

You define a map collection. This collection can have from 1 to N maps in it. All collection will refer to a Master metatile set, a CHR-DATA set and a palette set.

Depending on the mapper chosen, you will be able to select witch banks will be used for the pattern tables. You don't want to have a custom CHR-DATA just for editing your map: you want to use the real thing and select the same banks like when your program is running on the nes (of course this doesn't apply for CHR-RAM, so in that case you have no choice but to fake it). This could allow to simulate bank switching for animation too.

For every metatile, you will be able to give a name and description (which will be exported in your code) and define custom attributes. You will be able to see a list, select one and draw it on your map.

I could go on and on about it, there is so many things that I want to build in it that I don't know if I will ever find the time to do it. I hope to be able to add my sprite design/animation in it too.

Here's an image of my current WIP, it's a very very early alpha:
Image

As you can see, everything is tabbed so you can change the interface any way you want. I will try to make it as flexible as I can. Since this image is from an early alpha, it may change alot along the development cycle.

Edit:

Maybe an interesting option would be to be able to import existing data. This would be difficult but if done, that would reduce the re-creating the map inside the editor for people that already have hand made data.