The Dink Network

DinkC Reference's load_palette entry includes a warning that "In some situations this function can cause the colors to mess up and change in a way unintended by the specified palette. A better option is to apply your palette to a BMP file and use copy_bmp_to_screen() to change the palette."

Can somebody explain what the "some situations" are? I've done some brief testing but haven't got any messed up colors.

I think this refers to a problem in original 1.08, where IIRC, if you load a save game after doing load_palette, the tiles will revert back to the normal Dink palette, but the sprites will stay on the changed palette.

Not sure if this hapens on any other Dink Engine version.

Most likely it would be a leftover from <=1.07 due to something in old DirectX/Windows.

I think this refers to a problem in original 1.08, where IIRC, if you load a save game after doing load_palette, the tiles will revert back to the normal Dink palette, but the sprites will stay on the changed palette.

Yes, it looks like loading a saved game that uses a different palette causes problems.
I guess that the display palette is reset to default on load, but the graphics already loaded in memory stay on the old palette and the game(or DirectX) is trying to convert the graphics from one palette to the other? Or something like that.

Assuming this error can still occur in modern engines, it's also likely possible to have a functioning work-around added; e.g a Loaded.c script that triggers whenever a save-game is loaded. Just need to sort out detecting if a palette change took place or not.

I'll also add that the statement about palettes not being stored in save files is erroneous, and that 1.08 + its derivatives will store a path to the specified BMP which will be applied upon load.

I'll also add that the claim of "This will only work in 256 color mode" is somewhat erroneous as well. The palette will be loaded in 24-bit mode, but won't be applied to the screen for obvious reasons. Instead it may be used for filling the screen with a colour of your choosing, rather than being confined to stock. Apologies for double-posting.

> Most likely it would be a leftover from <=1.07 due to something in old DirectX/Windows.

I don't think so - I'm pretty sure I added load_palette for v1.08.

As for why copy_bmp_to_screen is better than load_palette - I don't recall any issues. That's not to say there aren't any (several of the features I added to 1.08 were buggy).

ackshually, it was in reDink beforehand!