Tile-specific palette idea (tldr near bottom)

[Lunathir]

We have a layer with all tiles following a specific color set of x amount of colors, but “oh look I don’t want to have to clone tiles with another palette if I can help it!”, or you have a strict necessity to keep to a specific amount of colors but you also want to see colorswapped versions of those tiles, like some sort of binary exporter or something.

This is where I think that TILE-specific color swapping may come in handy. You have a set palette on a tilemap layer set in the create/edit layer screen, maybe as an advanced feature alongside the base index with a note saying “hey, you will probably want to create a color swap layer somewhere above this one” (it could be separate from the palette embedded in the sprite, and it could use grayscale colors/user specified colors or something, Idunno) and that color layer could alter the colors on the tile graphics layer without creating additional tiles.

The “tilemap color index swap” layer could have individual tiles of its own, where three buttons could reside: add, remove and edit. This tilemap could be animated if the user wanted as well (if users wanted specific tiles to change color palettes without adding colors to the next), and/or it could tie into the planned built-in per-frame palette cycling feature to create animated tiles without using up too many additional tiles.

The color swap layer wouldn’t need to do math specifically, it would be more of a simple “hey, these colors are actually these, so let’s display my tile’s colors over the child layer’s graphics”, though it might not be able to change the colors of every other layer. I can understand if it might be a bit too clunky for others, but I think it might be able to work very nicely this way. The color swap layer could have a layer select dropdown for selecting a specific layer to colorize too.

Sorry if this might be too long and too clunky to implement, but it’s something I think could prove useful in some fashion or another, especially for artists who’d like to limit themselves without worrying of going past those limitations. For example, it could be used as a tool to let one see GB Studio color/tile combinations easily then export to a compatible type, or create mockups of Master System or Mega Drive/Genesis games.

tl;dr: graphics tilemap (what we currently have) with user-specified colors which is child of color swap tilemap, so no need for color-swap tiles on graphics tilemap layer

Also, sorry if this sounds like a really dumb idea, I think it could make things easier for the artist though

[BraidAcer]

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.

[Lunathir]

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.

[Ethan_Buttazzi]

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

[Lunathir]

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.

[Ethan_Buttazzi]

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

[Lunathir]

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.

[BraidAcer]

First there should be implemented:

• Multiple editable palettes per Ase file ~ a heap of GUI changes and script API additions
• Way to switch palette for individual cels and show what palette selected for current cel
• Tilemap layer cells palette selector byte with non-zero values overriding selected cel palette
• Tilemap layers cells flags byte with bits for x-flip / y-flip / rotate 90deg & GUI/API changes
• Export to save palette selectors and cells flags information when writing json/etc output

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.

[Ethan_Buttazzi]

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

[Ethan_Buttazzi]

maybe via a shader? if our engine supports thaqt kind of thing

[Lunathir]

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.

[BraidAcer]

You are too optimistic about 1.3.1 or 1.3.2.

[Lunathir]

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.

[dacap]

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).

[surt]

Pro Motion can do this with a layer effect.

The base image:

The colour offset layer:

The result:

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.

[Lunathir]

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.

[Lunathir]

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?

[surt]

@Lunathir

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 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.

[Lunathir]

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

[surt]

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.