Read Access Violation

[System64]

Hi, can one tileset uses multiple palettes? (Like Palette attribute per tile in old consoles) Thanks for your answer
By the way, this is a pretty exciting update! the CRT filter is also way better!

Hi!
Each tileset can have a single palette, there's no per-tile palette as in classic 2D chipsets. However, as you can now have several tilesets on the same layer, and each one have its palette, that's several palettes per layer.

Thanks for your feedback! I'm glad you like the new CRT effect :-) better looking and much more efficient in terms of CPU usage

Hi again
You can do that by simply making multiple copies of the TSX file, then load the tilemap and assigning a palette to each tileset. Want to change the color of a tile? No problem, just get the tile ID of the tileset, swap the tile to another tileset, boom, you changed the color, at least, it should be the idea. I will try that.
However, I have a nice quality of life suggestion : You can get the palette of tileset, but you cannot directly set it. Instead, you have to do something like this 

TLN_GetTilesetPalette (my_tileset) and then set the colors you want. It would be so nice to have something like this : TLN_SetTilesetPalette (TLN_Tileset tileset, TLN_Palette palette)

[megamarc]

Hi! Thanks for your suggestion.
However, it's not recommended to modify linked resources that have been loaded recursively. For example when you load a tileset or a bitmap, a palette is also loaded/created as a child reference, and the parent resource "owns" the palette, When you destroy the tileset or bitmap, its palette is also destroyed. If not, there would be a memory leak. If you change the palette of a bitmap or tileset, and then destroy the parent resource, the engine will destroy the wrong palette and leave the original palette "orphaned" and leaked. That's why is not a good idea to modify their palettes, instead, set the layer palette with TLN_SetLayerPalette()
This alwo happens with tilesets that are loaded and owned by a particular tilemap.

[System64]

Hi! Thanks for your suggestion.
However, it's not recommended to modify linked resources that have been loaded recursively. For example when you load a tileset or a bitmap, a palette is also loaded/created as a child reference, and the parent resource "owns" the palette, When you destroy the tileset or bitmap, its palette is also destroyed. If not, there would be a memory leak. If you change the palette of a bitmap or tileset, and then destroy the parent resource, the engine will destroy the wrong palette and leave the original palette "orphaned" and leaked. That's why is not a good idea to modify their palettes, instead, set the layer palette with TLN_SetLayerPalette()
This alwo happens with tilesets that are loaded and owned by a particular tilemap.

Effectively, I wrote this code :

Code:

bool TLN_SetTilesetPalette(TLN_Tileset tileset, TLN_Palette palette)
{
if (CheckBaseObject(tileset, OT_TILESET) && palette != NULL)
{
TLN_SetLastError(TLN_ERR_OK);
tileset->palette = palette;
return true;
}
else
return false;
}

and the old palette isn't cleaned up.
Can TLN_SetLayerPalette() deal with tilesets palettes? It wasn't a problem when you had only one tileset per layer to deal with, so only one palette. But now you can have up to 8 tilesets per layer, so up to 8 palettes to deal with.

[megamarc]

No it can't as they're two unrelated properties: Layer.palette is an optional property that can be NULL -and by default is-, whereas Tileset.palette is mandatory and belongs to the Tileset, not the Layer. Each one must be managed by its own accessor.
Tileset lacks accesor to set it in purpose, it can only be set during creation and then remains constant, it can't be changed. Your proposed setter function would work in the short term, but it would cause the leaking/orphaning problems of broken references I talked about in last post. That's by it doesn't exist.

[System64]

No it can't as they're two unrelated properties: Layer.palette is an optional property that can be NULL -and by default is-, whereas Tileset.palette is mandatory and belongs to the Tileset, not the Layer. Each one must be managed by its own accessor.
Tileset lacks accesor to set it in purpose, it can only be set during creation and then remains constant, it can't be changed. Your proposed setter function would work in the short term, but it would cause the leaking/orphaning problems of broken references I talked about in last post. That's by it doesn't exist.

Ah alright, now what I can do as a workaround, is I can get the palette with TLN_GetTilesetPalette and modify the palette with TLN_SetPaletteColor. It normally should work
It needs more setup and I have a bit of performances loss, but even old consoles does that : you overwrite the data in the Color RAM, you don't change the pointer to another place.

[megamarc]

Yes you're right: classic systems have a fixed numbers of hardware palettes, the Color RAM -or CRAM for short-, that are used globally by all tiles. Each tile has some palette select bits in its attributes to choose what palette to use. Doing color raster effects consists on effectively altering the colors in the CRAM table. There isn't concept of per-layer or per-tileset palette as in Tilengine.
Your approach of combining TLN_GetTilesetPalette() and TLN_SetPaletteColor() is the correct way to emulate similar behavior in Tilengine
For minimizing performance loss, there's a convenience function called TLN_GetPaletteData() (https://www.tilengine.org/doc/group__pal...e59efb8d4b) that returns a pointer to the internal color data of the palette. You need to be careful because you can cause memory corruption if writing past the allowed space. But with this, you can modify individual colors with a single memory write. You can fetch the color pointer at the beginning and later manipulate it with fast writes.
Each color component is a 32-value with alpha, blue, green and red 8-bit values.