08-09-2022, 01:18 AM
Hi!
I've thougth about this feature some time ago. To implement this, there should be a global store of slotted palettes -layers and sprites are slotted, but palettes are dinamically managed-. So you'll have for example a global set of pre-allocated palettes, from 0 to 15 for example. Classic systems like SNES or arcade hardware had this scheme of globally slotted palettes. Then a couple of bits in each 32-bit tile descriptor selects the palette index. This value could be established by a custom tiled property.
The tricky part wouldn't be the renderer, but making both models coexist without loosing performance: current dynamic palettes and slotted, preallocated palettes.
At the end I dropped the idea, because it wouldn't add real value. Per-tile palette was used because each tile was 4bpp (16 colors max), so having different palettes of 16 colors in the same layer makes sense. Tilengine has bpp (256 colors) per layer, so having slotted palettes doesn't solve any limitation.
However if you want to implement it in your fork, now you have an idea on how to do it
I've thougth about this feature some time ago. To implement this, there should be a global store of slotted palettes -layers and sprites are slotted, but palettes are dinamically managed-. So you'll have for example a global set of pre-allocated palettes, from 0 to 15 for example. Classic systems like SNES or arcade hardware had this scheme of globally slotted palettes. Then a couple of bits in each 32-bit tile descriptor selects the palette index. This value could be established by a custom tiled property.
The tricky part wouldn't be the renderer, but making both models coexist without loosing performance: current dynamic palettes and slotted, preallocated palettes.
At the end I dropped the idea, because it wouldn't add real value. Per-tile palette was used because each tile was 4bpp (16 colors max), so having different palettes of 16 colors in the same layer makes sense. Tilengine has bpp (256 colors) per layer, so having slotted palettes doesn't solve any limitation.
However if you want to implement it in your fork, now you have an idea on how to do it
