Suggestion: implement support for extra palette (color palette).

[laetemn]

Implement support for extra palette... !?

• NES
• SNES
• Sega Genesis
• Etc????

[bjorn]

I'm sorry, but what does this mean? What are you trying to do and how do you expect Tiled to help you with it?

[0ion9]

I think this person is talking about palettes in the 'color palette' sense, and overall they are asking for the ability to select between multiple color palettes for any given tile (since this is indeed a technique that was used by NES, SNES, Genesis, GBC, GBA etc). So for example they might want to be able place a blue steel girder, a grey steel girder, or a green steel girder by using the same single tile and swapping tile palette.

This technique can be especially effective for small tiles (~8x8), as their design tends to be simple enough that they can be reused to represent different things (using palette swaps, V/Hflips or 90-degree rotations.)

[bjorn]

I think so too, but you can achieve the same thing by just having multiple versions of your tiles since Tiled does not have the hardware limitations of ancient consoles. It would likely even be easier to do it this way than when you'd actually need to somehow control which palette is used for each tile on a layer, not to mention the effort that would require on my side for the implementation of such a feature.

If somebody is actually still developing games for this type of hardware, then I think they will anyway need to write an exporter/converter that would produce some hardware-specific map format. Setting up the palette for each tile could be part of that process.

Anyway since these are assumptions, I'm still interested to hear from the original author what he is expecting Tiled to do for him. I'd like to make Tiled more flexible, and this may still be an interesting feature. For example for use with Tilengine.

[0ion9]

I think so too, but you can achieve the same thing by just having multiple versions of your tiles since Tiled does not have the hardware limitations of ancient consoles

Having tried to do this, I disagree. If there are more than a few variations -- for example, I had 16 color variations in my test -- then, while generating the variations is easy, finding the same tile in the alternate color you want can become pretty onerous, especially with small tiles.

IOW: I don't disagree with that approach in principle, but to make it usable requires some additional UI.

I had an idea for a simple implementation that generalizes to any kind of variation wanted : simply select the same tile(s), by xy coords, in the next / prev tileset, as are currently being used. In case that sentence is too lumbering, a few examples:

• You are currently drawing with tile that has tile coords 0,5 within tileset A. You hit the 'prev' shortcut. Nothing happens, because 'A' is the first tileset defined. You hit the 'next' shortcut, and are now drawing with tile 0,5 in tileset B
• You are currently drawing with the block of tiles in tileset A at coords (0,5),(1,5),(0,6),(1,6). You hit the 'next' shortcut, and are now drawing with the block of tiles in tileset B at coords (0,5),(1,5),(0,6),(1,6)

There are a few possible refinements on this idea, but I think the basic idea is very simple, easily understandable (put variants in the same location of the tileset image) and requires no engine changes or UI widgets.

I think tile properties on the 'base tiles' (tiles in tileset A, in my example) could, as you suggest, be used at export time to infer that the variation should, ingame, be done via palette swapping.

A refinement of the basic idea might use tileset properties to 'group' tilesets so that the next/prev commands only move through the tilesets you want (for example, moving into a tileset where the identified tiles are empty space probably isn't what you want.)

TLDR: I agree with you, Bjorn, on explicit palette-swapping support being unneeded, and think that we could support a generic 'variants' mechanic by simply adding a pair of shortcuts that select the currently used tiles by position from the next/prev tilesets.

[laetemn]

0ion9 ...

Exactly! You are exactly right!

The intention is to use different color palettes, 100% (if possible) identical to the original consoles.

For example, the game "Odallus: The Dark Call" (http://store.steampowered.com/app/319480) was developed using the color palette of the NES, according to the developers.

[MetaFight]

I know this issue hasn't been active in a while, but I just wanted to express an interest in this as well.

Here's my use case: I have just dumped the tiles and level data from a NES game. My goal is to write an unnoficial "remaster" of this game as game-dev practice.

I currently have everything rendering as expected in Tiled, but the palette I used when dumping the data is... drab.

I now find myself wanting to play around with my export palette but the best way to validate my new palette is by viewing it in a rendered map. Sure, I can re-export repeatedlu and switch to Tiled, but it would be nice to be able to update the palette directly in Tiled and watch the changes live.

I know this is probably a fairly ucommon use case, but I figured I'd just give my 2 cents.

[eishiya]

As bjorn mentioned earlier in this thread, the way to go is to use different tilesets for each palette version of the tileset. It should be very easy to recolour your base tileset into each palette you want, and to create tilesets out of them. Then, you have a couple of options for using these coloured tiles easily:

• If don't intend to do a lot of tweaking of which palette is used where: when reading/exporting the map, the tileset determines the palette, and the tile ID within that tileset is the tile. This is very easy to set up, but has the disadvantage of requiring you to find the right tile in the right tileset, so it can get a bit annoying to author. Another advantage of this approach is that if you're still adding tiles and palettes, you can just add the tile(s) to the tileset(s) and add more tilesets and start using them right away, there's no extra work required.
• If you want to have an easier way to work with palettes and iterate palette distributions, you can also use Automapping and Automap While Drawing. You would have your "base" layer(s) and "colour" layer(s) determine the tile and palette to use at each cell. You'd also have locked "preview" layer(s) to see the combination (locking would prevent you from accidentally editing the preview). You'd draw using your base tileset in the "base" layer(s) and using some tile representing the palette in the "colour" layer to apply palettes. Automapping would look at the combination of "base" and "colour" tiles and produce the correct preview tile in the "preview" layer. This does mean you would need numTiles*numPalettes rules, but they're actually pretty quick to set up: since the tilesets are just recolours of each other, they have the exact same tile arrangement, which means you can copy+paste them onto your input_base and output_preview layers. Then you'd fill that same area with one of your palette representation tiles in input_colour. After that you just need to space them out into separate rules. You can do this in as few as (width+height-2) copypastes :] That's your entire rule set for one colour done. You can make the rest by just replacing the preview tileset and changing the colour tiles in input_colour (if your colour tiles come from the preview tilesets, then replacing the tileset will also replace them). Once you have this done and Automap While Drawing enabled, you can paint on the base and colour layers with the appropriate tiles and Automapping will automatically generate the preview on the "preview" layer as you go. You can even sample the colour of a cell by right-clicking that cell with the "colour" layer active. You can also set up another set of rules to enforce the 2x2 palette cell rule dynamically, this rule set would need to run before all the others. When you load/export map made this way to NES, you'd just ignore the preview layer, and use the base layer to determine the tiles and the colour layer to determine the palette to use. A downside to this method is that if you add more tiles to the tileset, you need to add them to all the automapping rule sets. If you add a new palette, you need to make a copy of the recolour ruleset for it (but again, that's mostly a matter of replacing a tileset in an existing set, it's not a lot of work). It's possible to automate this somewhat with scripting, but that's only worth the trouble if you're adding a lot of tiles as you go.

[MetaFight]

Heya. Thanks for your suggestions. I'll be honest, they both seem overly complicated to me.

I'll just modify my tile/map dumper to dump a large bitmap with the full level map in indexed colors and tweak the palette in Gimp. Once I'm happy with a palette I'll re-dump my tiles with it applied.

That's more or less the experience I was looking for: A way to view a rendered map and tweak the global palette to taste.

[FitzRoyX]

I think so too, but you can achieve the same thing by just having multiple versions of your tiles since Tiled does not have the hardware limitations of ancient consoles.

It has very little to do with saving ramspace and more to do with reducing repetitious work. The problem is that with nes games that use tons of palette swapping (smb1), you're talking about expanding a tileset from 48 tiles to 480. Something that could be small and simple with a palette selection dropdown instead becomes a giant scrollfest.

The other problem is that any artistic change done to a tile must now be repeated 10 times to effectuate that change across 10 palette variations. It's the same concept behind why tile flipping makes sense to support. When you've got a house where one half is 12 tiles and the other half is just a mirror image of the other half, you wouldn't want to repeat artistic edits across both sides.

And since Tiled also lacks the ability to rearrange tilesets in a way that updates tmx files with the new index positions, inserting new palette variations into a tileset is guaranteed to break all of your maps. So there's all these mental gymnastics about how to even arrange a these giant variation-ridden tilesets from the beginning when it shouldn't even be a concern.

IMO the tiled map format should allow palettes to be defined at the top and then the csv should look like:

7(1h),1(1),14(1),13(1),13(1)
0(1),1(1),14(1hv),13(8v),13(1)
0(1),5(1h),8(1),13(8),1(1)
8(1),1(1),7(1),13(8),1(1)
0(1),5(1),6(1),13(8),1(1)

This is extremely clear and easy to read textually outside of the editor. I can immediately read that and say that the first tile of the map is 7, uses palette 1 and is horizontally flipped.

[eishiya]

I think your suggestion would be too much of a compatibility break. Instead, perhaps some bits could be taken away from tile IDs in the GID to encode the palette. The highest four bits encode the flip flags, perhaps the next four or five could be used for the palette ID, still leaving 20+ for the tile ID.

However, with actual native palette support being extremely rare in modern engines and APIs, I don't think this is a great feature for Tiled, especially since Tiled already provides a way to distinguish between multiple variants of a tile: tilesets. Some image editors, such as Aseprite, can be set up to generate all the palette versions of a base tileset automatically, and the Automapping method I described earlier in this thread can even allow you to set have tile+palette combinations in your production maps for use with e.g. palette shaders or palette-supporting consoles without having to ship all the recoloured tiles and without having to even worry about the fact that the recolours exist as separate tiles (i.e. no scrolling required!). The automapping rules for this can be set up via scripting as well.