My issue is that the index doesn't tell you a lot
- If you resize the
background sprite, indexes may change
- the manual doesn't even mention whether the index counts left-to-right-top-to-down or some other arcane ordering
- the manual doesn't clarify whether the index correlates to the background or the tile palette
- it's not clear whether index 0 is the special "eraser" tile or not
I suppose it's possible to reverse-engineer the "tile left" and "tile top" values by mod:ing (tile width * tile index) with the graphics resource's width, but not being able to slap metadata indices directly onto tiles like in RPG maker feels like a missed opportunity when all the infrastructure is in the engine already. If I'm gonna have to do it programmatically, I might as well just use the index, rendering the blob pointless.
The top one is high on my list, and I've "half" a fix for it sitting in a branch just now, just no time to finish it yet....
All tilesets that are "proper" grid based tilesets are based from top left to bottom right. I'm sure we can get that added to the manual if it's not clear though.
I assume you mean the "tile number" here. Why would the "index" be a background (or rather sprite)? a tile index is the index into the grid. Just like normal grids, it's 0 at the top left then (w*h)-1 at the bottom right.
From the manual.....
"
When creating your tilesets, keep in mind that the top left grid cell must always be empty as this is the tile thatGameMaker Studio 2 will use for "empty" tiles in a room and for erasing existing tiles (and even if you have pixels in that part of the image they will be ignored)."
That seems pretty clear to me....? Basically when building up a tilemap to display, it builds up a grid of quads (2 triangles). If tile(or index) 0 is there, it doesn't even add these to the grid, allowing rendering to be much faster. The tile is "empty" so you don't need to render anything.
As to "metadata"..... look at the Dungeon demo. Meta data can easily be added using another tilemap - or MANY other tilemaps. We did have designs for meta data, but compared to just adding a custom (design only) tilemap, and then new layers for collisions/meta data, it didn't stack up. Having a whole layer for meta data, using your own graphics to display is increadibly powerful, and fast. You can "paint" your meta data using all the normal tilemap features in the editor...file...line...rect, all of them. Want to put a pickup or "trigger" somewhere, then on a hidden layer - which the code can still read, pain in a custom tile for it.
These tilemaps don't even have to be the same resolution. Look here...
You can see I use much smaller tiles for collision, but this could just as easily be "pickup" or "door" triggers. Tile maps aren't "just" for display, they are a way to edit user data that is queried in-game. The Dungeon demo does this for collision - have a look at that. It has a custom tileset that I can then paint over the top over ever thing in the room editor.
Lastly.... code manipulation of tilemaps. This is monumentally faster than adding old tiles. "all" you need to add is a single number. No setting up UVs for everything, just "poke" a number into the grid cell and the tile appears. I just can't see how that isn't better. I've done procedural stuff with 1.x and 2, and this is much, much quicker and simpler. You also have the added advantage that you "could" use the graphic itself as a collision if you need to.
okay.... really lastly. The new tilemaps are such an improvement that you can now have many layers of them without performance impacts, and this means you can overlay many of them to get the effects you want. On top of this if you need "unaligned" graphics, the asset layer does let you dump sprites down anywhere you like. This is ideal for things like grass, vines, misc "details" that help break up the grid nature of some tileset.
