Do you mean to keep what palette to use for every tile like NES do?
Also you may want to add flip-x/flip-y/rotate feature too, isn’t it?
All this could be done now via custom exporter (detect another sub-palette, detect flips and rotation).
But you’ll have to ask programmer or scripter to code this custom exporter for you.
A custom exporter completely misses the point of the color layer: allowing tiles using different palettes, in real-time, to be made without duplicating said tiles with every single possible palette combination, and allow all of those tiles to change at the same time. It could be a tool used alongside it, yes, but it doesn’t address the request at hand. An exporter just doesn’t allow tile-specific palettes. The problem lies in the tilemap itself: it requires duplicated tiles for color swaps, giving no flexibility to change just a few tiles, instead having the user create another tile for making a green and orange tile blue and red, or something similar. Top one is how I’d like it to work, and the bottom is how it currently works. Imagine the bottom one on a much larger scale as well, the amount of unnecessary tiles that creates is just insane if you need palette swaps of every single tile, whereas the top one adds an extra layer, yeah, but it declutters the tileset SO MUCH because palette swaps are on another layer. Another advantage is it could take less time to go through the tile color palette and the tile palette over having many different tiles with alternate palettes in the singular palette. With the second GIF though, having that on a much larger scale would be a nightmare, especially with not knowing how many color swaps there are, how many tiles you have that aren’t duplicated in other palettes, and more. That one has 24 tiles over the 256 tile limit (I’m imposing this limit because old hardware) just for three extra colors, while the first one has… none, just three or four palettes for tile palettes. Another advantage is with animations that just need color-swapped tiles, the tilemap itself can be static while the color layer is animated.
these types of color schenanigans are somawhat planed for future updates, one example is the color cyc,ing feature that is on work right now, maybe its better to wait a little and focus on the main thing such as being able to rotate tiles them we can think about these types of shenanigans
I have mentioned palette changing as a helping hand for this. Although it’s not the perfect feature for this as it does increase per-frame tile count with duplicate colors, it would help a ton over an entire project that uses a single tile that changes its colors, helping cut down on tile cost, which I am happy about. And rotating/flipping tiles does also help on cutting down the amount of tiles, which is also good. However, I didn’t see color-related things other than palette changing on the roadmap. It’s not something immediately urgent though, however I think it’s a nice QoL feature that could be implemented as the tilemap features get fleshed out more and more, and it might fit in well (and feel natural being introduced) alongside the rest of 1.3’s new feature set.
you know you can code that yourself with some reseach various games use it, id ont know if its possible iva aseprite script but im certain there must be some way to do it in whatever engine you are using it
Using it engine-side has the same issues as using an exporter. I also believe it may be difficult to do it script-side. I am aware that there are color-swapping scripts, but those affect the whole sprite if I am correct. A native tile-map end feature would make it easy to do so in the editor itself, using a tilemap as the way to change a palette for everything, though. I don’t want to completely discount a script though, it’s just I’m not honestly sure there is a good way to implement it really easily and in the specific use-case for it.
First there should be implemented:
A lot of features and testing. It’s quite huge amount of work.
P.S. With custom exporter you can detect similar tiles (including flipped/rotated) by exporter itself and export only minimum amount of tiles with extra information. It would be much faster than to wait for all above to be implemented. The only drawback will be inability to easily edit them in editor.
i mean the point of thisp ost ist make easy to swith color inside a engine without having to redraw, and i mean if that was in the aseprite wouldn you need to export each different verision of the tileset anyway?, i think the only way is to do it inside the engine so you can make a tileset with the values and just add the color palettes later
maybe via a shader? if our engine supports thaqt kind of thing
I know those are planned features. I know the devs want those to be set in the current update. Those can come first. I honestly don’t mind if the whole “tile palette” thing comes in a subupdate, like 1.3.1 or 1.3.2, sometime within the next few months or so, I just think it’s really nice to have without someone being committed to using tons of tiles in a single art piece, whether it be an export or a mock-up or even a simple art piece. I honestly really appreciate the team giving early access to the update too. And, yes, a custom exporter might help with that, it’s not able to be used for simple art pieces or mockups.
You are too optimistic about 1.3.1 or 1.3.2.
I’m not saying those will come soon. I just want to forget about this whole thing though. I feel like I’ve honestly made a mistake with the post, I just feel stupid for asking about it.
Hi there 
We have plans to add a “palette shifting” feature in the original tilemap issue which might solve this. The general idea would be that each tile could include an index to shift the palette indexes by an exact amount.
Other idea which might solve this, is using a special new blend mode to OR bits (which would act like palette shifting).
I think both ideas could solve the same problem, but I’m not sure if the general public would want something like this (it’s not a high priority issue).
Pro Motion can do this with a layer effect.
The base image:
Using a layer effect has the benefit of also working with non-tile layers, so for example, you could paint a base layer in greyscale and then paint on a separate layer to select “material” kind of like non-destructive shading. (General appeal?)
Pro Motion is unfortunately limited to a single tileset per image so have to pollute the tileset with tiles for the subpalette offsets. Aseprite could do this better with a separate tileset for the subpalette offset layer.
That’s honestly okay. It doesn’t have to be a super high priority thing, it’s just something that would at the very least make things easier for me, since the whole “hey duplicated tiles in different palettes not matching up” or whatever just feels kinda weird for me. The planned features should always come first n … n
Though, I want to say that the palette shifting is what I’m actually thinking of, it’s just the way I thought of it might be a kinda front-end to it or something.
This is not exactly what I was thinking of, but it’s actually really close, I think. The main thing I see between the tiles with that method is the usually follow a specific hue I think, like the yellow and black tiles in the first one or the trees/grass in the second. It’s still really close though.
I think you could also achieve this method in Aseprite?
It’s nothing to do with colourising. It’s index offsets.
The palette is set up like so:
With the colour offset layer containing a colour from the subpalettes arranged below.
Oh, okay! Idunno how to respond too well but [I think that’s what I was thinking of when I made the request] that’s exactly what I was thinking with this. You can’t do that in the current beta but I think that’s a planned feature. Ty for correcting me though
Now that Aseprite’s got scripting, a script layer type which runs a script per-pixel with access to other layers pixel values could do the job well enough too.
aseprite had scripting for ages
