Palette attribute per tile

[System64]

Hi
I want to implement a palette attribute per tile like most retro consoles such as NES, SNES, MegaDrive/Genesis did into my fork of Tilengine
Have you an idea about how I can implement this please?
I'm thinking of adding an attribute called pal or palette into the tile's struct and also the same attribute on the Tiled tilemaps, and also having something like 16 palette slots in Tilengine. I think the most difficult part is the rendering.

Thanks for your answer.

[megamarc]

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 

[System64]

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 

it shouldn't be difficult
What I'm thinking to is, effectively a global set of pre-allocated palettes with something like, everything is black, and a function that loads the palette into a specified slot. not hard for now
but now, how can I make the renderer knowing which palette should be applied to which tile? Because the current system applies one palette to an entire layer and I also never programmed the SDL before.

[megamarc]

Hi again,

The renderer should know which palette to use for each tile based on the palette index bits, in the same way it knows what graphic to draw based on its tile index bits. To keep backwards compatibility, an additional bit may be set to tell if the palette index bits are valid, or it should use the default layer palette instead (default behavior).

The SDL library is unrelated to the renderer and its palette management. It is used to create a window, process input and present the rendered framebuffer.

Regards,

[System64]

Hi again,

The renderer should know which palette to use for each tile based on the palette index bits, in the same way it knows what graphic to draw based on its tile index bits. To keep backwards compatibility, an additional bit may be set to tell if the palette index bits are valid, or it should use the default layer palette instead (default behavior).

The SDL library is unrelated to the renderer and its palette management. It is used to create a window, process input and present the rendered framebuffer.

Regards,

So if I understand well, I'll have to modify the DrawLayerScanline() function to make the engine using palette attribute per tile?
Edit : For backwards compatibility, I think I'll use a flag that allows to switch between the original Tilengine behavior (palette per layer) and the new one (palette per tile)

[megamarc]

To fully support per-tile palette, you should modify DrawLayerScanline(), DrawLayerScanlineScaling(), DrawLayerScanlineAffine() and DrawLayerScanlinePixelMapping(). Each one is responsible of the different "graphic modes": standard, scaling, affine transformations and pixel mapping.

I'd also implement the following functions:

Code:

// Get pointer to one of slotted palettes:
TLN_Palette TLN_GetSlottedPalette(int index);

// Set slotted palette to specific tile:
void TLN_SetTilePalette(TLN_Tilemap tilemap, int row, int column, int index);

// Remove tile palette (use default one)
void TLN_DisableTilePalette(TLN_Tilemap tilemap, int row, int column);

As you can see, tiles belong to tilemaps, not to layers.

[System64]

To fully support per-tile palette, you should modify DrawLayerScanline(), DrawLayerScanlineScaling(), DrawLayerScanlineAffine() and DrawLayerScanlinePixelMapping(). Each one is responsible of the different "graphic modes": standard, scaling, affine transformations and pixel mapping.

I'd also implement the following functions:

Code:

// Get pointer to one of slotted palettes:
TLN_Palette TLN_GetSlottedPalette(int index);

// Set slotted palette to specific tile:
void TLN_SetTilePalette(TLN_Tilemap tilemap, int row, int column, int index);

// Remove tile palette (use default one)
void TLN_DisableTilePalette(TLN_Tilemap tilemap, int row, int column);

As you can see, tiles belong to tilemaps, not to layers.

Alright, I'll try this. It shouldn't be that hard (except I'm pretty sure I'll have segfaults while devlopping this feature).
However, when you are talking about Pixel mapping, are you talking about bitmap mode? In this case, bitmaps normally doesn't use tiles, except if you are talking about this tiled mode where you can manipulate every pixel data?

[megamarc]

No doubt you'll have segfaults while developing features!   I often suffer them, too, so it's normal. Unmanaged languages with direct memory access like C are very prone to trigger them during development.

Pixel mapping is not bitmap layers. It's a rarely used feature that I implemented to "displace" individual pixels from their source locations. It can be used in both tiled and bitmap layers. With this feature you could create for example spherical projection (simulate a rotating 3D sphere), spinning vortices, etc:

http://www.tilengine.org/doc/md_layers.h...totoc_md44

[System64]

No doubt you'll have segfaults while developing features!   I often suffer them, too, so it's normal. Unmanaged languages with direct memory access like C are very prone to trigger them during development.

Pixel mapping is not bitmap layers. It's a rarely used feature that I implemented to "displace" individual pixels from their source locations. It can be used in both tiled and bitmap layers. With this feature you could create for example spherical projection (simulate a rotating 3D sphere), spinning vortices, etc:

http://www.tilengine.org/doc/md_layers.h...totoc_md44

Oh alright, so I'll create a new branch in my fork to avoid breaking my current Tilengine fork (the one with thoses small extra features and start developing this. I'll go back to this thread when I have some questions or problems.

[System64]

Okay so I now have a problem.
The problem I have is I want to store the palette index in each tile cell of the tilemap. Sadly, Tiled doesn't support that. However, I can make a second layer that contains palette index information. But I don't think Tilengine currently supports that. Is there something I can do? Should I modify the loader that will take this special layer into consideration?