10-30-2022, 04:10 AM
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.
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.