This applies to pretty much all palette swapping methods, but I keep forgetting to mention it so: this doesn't work at all texture interpolation, so make sure you turn texture interpolation off on both the main image and the palette samplers before doing this. It also isn't going to work with sprites that contain premultiplied alpha, since that affects the color of the sprites as they're stored in the game files.
Interestingly, you can easily increase the available colors from 256 (because indexes 0-255) up to 65536 if you make the palettes be 256x256 square images and then use the red AND green channels in the sprite to select it. Of course, this assumes you have a palette of more than 256 colors, and if that's the case... why XD? Although, that does give me another even better idea. If one created a custom file format that was sort of like a 3D texture (kinda like a voxel png, it stores the RGBA channels at every XYZ coordinate set), you could generate one copy of this "image" that has the original colors, where every red green and blue value is set to equal the x, y, and z coordinate that voxel is located at. This will store the entire RGB color spectrum in this 3D texture. If you wanted to perform a palette swap then, all you'd need to do is regenerate the 3D texture but for every color you want to replace with another, you just manually set it. So, if you want to change the color pure red (255,0,0) to pure cyan (0,255,255), then you only need to change that SINGLE voxel in the 3D texture to have the new color. Then, if you create the sprite, it doesn't matter if you draw it in a specific color palette or greyscale or anything, because when you take the RGB values individually, you can use them to check the coordinates of that 3D texture in the shader. And, if the sprite has pure red on it, drawing it using the modified 3D color palette will instead draw it as pure cyan, because the coordinate (255,0,0) actually returns the RGB value (0,255,255). Lastly all you need is some kind of program that can generate 3D textures like this for palette swapping, where you input the set of original colors, the colors it should swap to, and it outputs the 3D texture, and you've got a pretty fast lookup table for swapping between any two palettes at any time. I'm curious if this is a known approach to solving this problem, actually.
someone asked me to do that in Lorikeet and i said no on the grounds that if you need that many colors you probably don't want to be/shouldn't be palette swapping
@@DragoniteSpam Hmmm.. interesting! I could imagine how you could easily go from my method that would function like a palette swap to something more like a full color spectrum curve, since if you create some sort of function that modifies the value of EVERY color in the hypothetical file I’m referring to based on what its original values are. Like, say we define a function that sets the green and blue channels to the red channel only if they are 0, and then sets all red channels to 0. This would do the same thing I mentioned about converting (255,0,0) to (0,255,255), but would ALSO convert other colors, like (193,0,17) to (0,193,17), which would then act like a shift function across the entire spectrum of colors instead of only hot-swapping a few out for whatever new palette you want to use.
technically there's nothing stopping you from creating a LUT table with all 16 million colors and modifying them individually like a palette swap, except for the bit where you'd then have to store all of your palettes with 16 million colors
@@DragoniteSpam It should be the same file size as a 4096x4096 pixel image (without transparency), so yeah, definitely not something you want to load into memory from the file system frequently, but not completely unreasonable either. The worst part is all the wasted space, and technically you could get rid of all the unchanged voxels from the file because the XYZ and RGB values of a voxel are equal if they’re not changed, but at that point you’re essentially just making a lookup table that it needs to check every value for again, just like in the slow method you showed in the last video and at the start of this one.
it can, though you'd have to make sure the shader is set at the time of drawing tiles so if you wanted to do that it would probably help if you drew all of the tile layers manually
This applies to pretty much all palette swapping methods, but I keep forgetting to mention it so: this doesn't work at all texture interpolation, so make sure you turn texture interpolation off on both the main image and the palette samplers before doing this. It also isn't going to work with sprites that contain premultiplied alpha, since that affects the color of the sprites as they're stored in the game files.
This gives me a ton of ideas. Thanks for the great video.
Love all these vids. Super useful. Thank you!
Super useful, thanks!
Interestingly, you can easily increase the available colors from 256 (because indexes 0-255) up to 65536 if you make the palettes be 256x256 square images and then use the red AND green channels in the sprite to select it. Of course, this assumes you have a palette of more than 256 colors, and if that's the case... why XD?
Although, that does give me another even better idea. If one created a custom file format that was sort of like a 3D texture (kinda like a voxel png, it stores the RGBA channels at every XYZ coordinate set), you could generate one copy of this "image" that has the original colors, where every red green and blue value is set to equal the x, y, and z coordinate that voxel is located at. This will store the entire RGB color spectrum in this 3D texture.
If you wanted to perform a palette swap then, all you'd need to do is regenerate the 3D texture but for every color you want to replace with another, you just manually set it. So, if you want to change the color pure red (255,0,0) to pure cyan (0,255,255), then you only need to change that SINGLE voxel in the 3D texture to have the new color. Then, if you create the sprite, it doesn't matter if you draw it in a specific color palette or greyscale or anything, because when you take the RGB values individually, you can use them to check the coordinates of that 3D texture in the shader. And, if the sprite has pure red on it, drawing it using the modified 3D color palette will instead draw it as pure cyan, because the coordinate (255,0,0) actually returns the RGB value (0,255,255).
Lastly all you need is some kind of program that can generate 3D textures like this for palette swapping, where you input the set of original colors, the colors it should swap to, and it outputs the 3D texture, and you've got a pretty fast lookup table for swapping between any two palettes at any time.
I'm curious if this is a known approach to solving this problem, actually.
someone asked me to do that in Lorikeet and i said no on the grounds that if you need that many colors you probably don't want to be/shouldn't be palette swapping
as for the second part, LUTs are a thing i'm thinking about tying into this but they're more like photoshop color curves than palette swapping
@@DragoniteSpam Hmmm.. interesting! I could imagine how you could easily go from my method that would function like a palette swap to something more like a full color spectrum curve, since if you create some sort of function that modifies the value of EVERY color in the hypothetical file I’m referring to based on what its original values are.
Like, say we define a function that sets the green and blue channels to the red channel only if they are 0, and then sets all red channels to 0. This would do the same thing I mentioned about converting (255,0,0) to (0,255,255), but would ALSO convert other colors, like (193,0,17) to (0,193,17), which would then act like a shift function across the entire spectrum of colors instead of only hot-swapping a few out for whatever new palette you want to use.
technically there's nothing stopping you from creating a LUT table with all 16 million colors and modifying them individually like a palette swap, except for the bit where you'd then have to store all of your palettes with 16 million colors
@@DragoniteSpam It should be the same file size as a 4096x4096 pixel image (without transparency), so yeah, definitely not something you want to load into memory from the file system frequently, but not completely unreasonable either. The worst part is all the wasted space, and technically you could get rid of all the unchanged voxels from the file because the XYZ and RGB values of a voxel are equal if they’re not changed, but at that point you’re essentially just making a lookup table that it needs to check every value for again, just like in the slow method you showed in the last video and at the start of this one.
Can this be done for tiles?
it can, though you'd have to make sure the shader is set at the time of drawing tiles so if you wanted to do that it would probably help if you drew all of the tile layers manually