This is sort of a request for three features, which are related.
A tile property inspector (perhaps this already exists)
This would allow you to select a tile in the tile map editor and be able to A) see the properties of the tile, and B) edit those properties. With the current implementation, those properties would probably be the tile ID, and the H/V flip attributes. Editing the tile ID may not be as useful in this case, but I think it would be useful to be able to toggle H/V flip, without copying the tile and flipping it via keyboard shortcuts.
It might also be helpful to generalize tile properties, which would allow users to add arbitrary properties to tiles (which may not be rendered or displayed but could be output even if doing so requires a custom plugin).
Tile palette selection. The ability to assign a specific palette or palette offset to a tile. The main use case here is for tiles that use fewer than 256 colors (e.g. 16 colors). While the tiles could use subsets of the 256-color palette, if you have two tiles which you want in two 16-color subsets, you would need two different tile definitions as per the current implementation. For a more concrete example, consider a flower tile which uses 16 colors, you may want several variations, which use different 16 color subsets to change the flower color. If you want 16 of those variations, you would need to define 16 different tiles!
A potential solution, could be to have a list of namable 256 color palettes (to help users located them), and just select which one you want to apply to each tile via the tile property inspector (where the default palette is the one assigned from the tile set when the tile is imported or created).
Tile set locking. I know that the current tile-set editor has optimization features, however, it would be nice to be able to lock tiles in specific locations. This could be useful for retro systems where you want to keep certain tiles in the tile set (such as for text) but want to bank in / out certain tiles. It could also be used for a system that allows for more than 256 colors, which are accessed by extending a palette ID with the tile ID. Another feature that would be nice here, would be the ability to replace tile 0 with any tile (not just an empty one). A use case would be for the SNES Mode 7, where tile 0 could be used to fill the area outside of the main tile map after transformation.
Just to be sure: the tile properties are then properties of the tile within the map position, right? Only with this the definition of H/V flip would make sense. At the moment you can only set up a special code for every tile in the library, so it’s bound to the tile, not the the map entry of the tile.
There is a layer effect called “Re-apply color palette”. Please be sure to have the latest version (7.2.2.2) and have a look at its documentation. There you will also find a sample project. Does this do the job already?
But it would of course require an individually coded handling of the tile map data.
Just as an example:
If tiles 16-32 are locked, what should happen with those and with the tiles before?
Would the tiles before be empty (in part) if unused. E.g. only first 4 tiles are used then there are some empty tiles and after that the locked ones appear?
Locked tiles would be ignored for any optimization? There contents are not touched, except you modify their contents or use manual deletion etc.?
To clarify, suggestions (1) and (2) apply to only the tile map (so what would be the level for a game), and (3) applies to the tile set (the preview window where you can select and place tiles from).
Right now, only the H/V flip would make sense. You could also display (but not allow editing, of the tile ID), which I know can be displayed elsewhere, but there is no reason to not have it be redundant. If you also allow the palette to be selectable for each tile, that would also make sense. If you allow for custom attributes, that could also be used there. An example of a custom attribute would be how SNES games had a priority bit for the tile map. I think it would be fair to not support custom attributes in the official output routines, and require anyone who wants to make sure of them to write their own output plugin – the request is more for GUI / internal support which can be accessed in a file IO plugin.
I’m not sure if I understand “Re-Apply color palette” correctly. It looks like it requires another layer to do so. If that’s the case, I could always just have 16 different layers, one for each palette entry, and implement a custom file writer which looks at the layer names and assigns a palette ID that way, correct? That was my original solution to this problem, but it would be annoying for artists to do.
To clarify, this is to allow Pro Motion to be used as a level editor for existing systems. Where for example, the SNES had a palette index (so in 4bpp mode, this would basically select a bank of 16 colors for the given tile to use) for every tile in a layer (I believe it was 3-bits for 8 different palettes). I am suggesting that Pro Motion have an easy way of implementing the palette index there.
If the tile map was restricted to 256 colors, for 16*16, and the tile definitions (glyph data) were unlimited, then the current system would work (with careful planning). However, if the glyph data is limited (like on the SNES), an artist would probably want to re-use tile glyphs as much as possible, especially if it can become something else by using a different palette (i.e. you can cleverly allocate colors so that you actually pack multiple 4-color glyphs into a single 16-color glyph, which change based on the palette applied).
A work around, which would reasonably implement such functionality, could be to have multiple palettes of 256 colors defined for a single layer. These palettes would have a string name attached to them (so they are easy to find), which is set by the user / artist. Then they could be selectively applied to a given tile in the tile map (not the tile set), via a drop-down list. Those palettes could also be shared among multiple layers as well. That would place more effort on the artist to make sure that the number of total palette entries are not exceeded, but that would be much easier to do, than to mentally segment an individual palette into several sub-pallets. Hopefully that makes sense.
That’s correct. Essentially the locked tiles would be ignored for any optimizations, and the contents could not be touched except if you modified their contents manually or manually deleted them. Presumably they could also be manually moved around too (possibly requiring unlocking and relocking). A simple use case would be creating a mode-7 tile map for the SNES. The 0 tile would be manually locked to a specific pattern (perhaps it’s a tiling cloud pattern for the edge of the map). Then you lock tiles 1-10 to either be empty or a number (say they are used by the HUD), and then let pro motion optimize the locations of the other tiles (since they are not locked). If it’s later determined that another 2 glyphs are needed for the HUD, the tiles glyphs in slot 11 and 12 (or 43 and 87 – the location doesn’t actually matter, as long as the game developer knows where they are) can be moved to the end of the tile set, and those locations locked as “empty”.
+1 on the generic property inspector. Basically, you can add a new entry into a name/value pair table associated with the object (an object might be a tile, a tile-set entry, a palette index). If a new “name/value” entry was added then every object of the same type gets that same named entry (with a blank value). Thus if you added “collision” name to a red palette index entry and set the value to “1” then going into the blue palette index entry would have a the name “collision” too but a value of “” (which you could change to a new value). This is great way to be able to add meta data tags that a programmer could use for various purposes. If your system had pixel perfect collision based on palette index then this would be convenient (as a programmatic way to create a mask without the mask). Likewise if it each color had a “depth” name/value pair, that would also work (e.g. if the image was split via a program to different layers based on the depth field). Obviously it would need a custom writer to store it (or a generic/common JSON-style meta data output).