Standardize on "block" or "metatile" terminology?

[Rangi42]

Right now we use both of these terms inconsistently for the 4x4-tile 32x32-px units that make up maps' .blk data.

• "Block" was the binary hacking term before the disassemblies. It's most visibly used in the changeblock script command, the data/maps/blocks.asm file, and referenced by the ".blk" extension. Also pokered still refers to "blocksets" and ".bst" files.
• "Metatile" is the more general term for units of NxN tiles that are themselves tileable (e.g. on the NES and other retro platforms). It's most visibly used in the "metatiles.bin" files.

Of course both terms also appear in routine names (GetBlockLocation vs LoadMetatiles), WRAM labels (wOverworldMapBlocks vs wPlayerMetatileX), data labels (CutTreeBlockPointers), constants (METATILE_WIDTH), and some wiki tutorials. So there would be a lot to update in any case.

Furthermore, Polished Map would need updating to be compatible with a change in either direction (e.g. if pokecrystal renamed metatiles.bin to blocks.bin or .bst, or renamed wOverworldMapBlocks to wOverworldMapMetatiles). It currently refers to "blocks" as the squares making up the map, and "metatiles" as the squares making up the metatileset. This distinction is even less clear in the context of the whole game instead of a map editor, but maybe we could also use it here.

Note that we've changed terms from the binary hacking days before, and macros/legacy.asm exists to make that easier. However, both terms have now settled in as familiar to disassembly hackers, so staying inconsistent is also an option.

[SatoMew]

I believe our GBA decompilation and associated tool projects have gone with "metatile" (example from the porymap docs).

[JustRegularLuna]

I prefer "blocks". I (along with the rest of the community) was calling them that for a solid decade before pokecrystal named them metatiles, and I have continued to call them that in spite of the current naming convention. The commit that dumped them referred to them as "blocks" in the description as well, despite naming them "metatiles".

[Rangi42]

(The commit that dumped them: bcf9ead)

[Rangi42]

Note that NPCs use 2x2 arrangements of OAM tiles, and more generally sprite anims use predefined groups of tiles. Those are generally called "metasprites", but we don't (yet) use that term, instead calling them "OAM sets" or "OAM data".

[melthelesbian]

I, personally, prefer the block/blockset/map blocks set of terminology, but gen 3 has gone all-in on metatile, so short of convincing them to also switch, metatile might be better for overall consistency across projects.

That said, I support "blocks" in spite of that though, I don't think the language of metatiles are widely used anywhere else, I only see occasional reference to them in a subset of the NES dev community, and no other retro game dev or hacking community uses that language as far as I'm aware.

[PiaCarrot]

+1 to blocks simply due to what its been referred to by people in the scene for 20+ years.

[Rangi42]

I don't think the language of metatiles are widely used anywhere else, I only see occasional reference to them in a subset of the NES dev community, and no other retro game dev or hacking community uses that language as far as I'm aware.

The map-editing programs Tiled (as of 1.4) and GBTD/GBMB (still maintained alongside GBDK) also refer to "metatiles", and that's the term GB Studio users have mentioned when requesting them (1, 2). More generally, "metatile" is used in non-retro applications (particularly for working with geographic maps like OpenStreetMap, GeoWebCache, or TileMill). It's a general technical term in computer graphics, like "sprite"¹.

That said, the Pokémon scene is free to use our own terminology, and "block" has the advantage of being shorter (plus changing the .blk extensions would be too disruptive -- even if we stuck with "metatiles" I'd leave those alone).

Footnotes

1. People also colloquially use "sprite" to refer to the large images of Pokémon in battle, but technically those are just regular GB background graphics, which is why the disasemblies call them "pics" instead. ↩

[SatoMew]

That said, the Pokémon scene is free to use our own terminology, and "block" has the advantage of being shorter (plus changing the .blk extensions would be too disruptive -- even if we stuck with "metatiles" I'd leave those alone).

The description here could be changed to "Game Boy map metatile (block) file" or similar, too.

[vulcandth]

I think we do need to standardize this, but I don't mind still mentioning the other one as an "alternate" name.

If it were up to me:

• Use "Blocks" as the preferred named for 4x4 tiles, with a mention that they may also be called metatiles
• Use "Collision cells" to refer to the 2x2 (16x16px) cells that represent collision data. (which NPC's/object typically occupy) [related to Define COLL_CELL constants #1170
• I wouldn't worry about defining anything like a "metasprite" or anything like that right now.

[Rangi42]

It sounds like everyone, or at least the vocal majority, prefer "blocks". That means it's fine to rename data/tilesets/*_metatiles.bin to data/tilesets/*_blocks.bin? (I would suggest *.bst like pokered, but this is more of a pair with *_collision.asm, as well as *_attributes.bin if people follow that wiki tutorial.)

[vulcandth]

I'd almost recommend that pokered use *.bin instead of *.bst... mainly because when I see .bin I know its a binary based INCBIN... but that's a conversation to have on the pokered repo.

[SatoMew]

It would honestly be better to switch to "metatile" and keep occasional references to "block" as a legacy term.

[Rangi42]

I'd almost recommend that pokered use *.bin instead of *.bst... mainly because when I see .bin I know its a binary based INCBIN... but that's a conversation to have on the pokered repo.

Sure, opened discussion in pret/pokered#498