Indexed 16 colour palette simulation?

[Domarius]

I would like to replicate Pico 8's 16 colour limitation, to the point where I could edit a colour index and have that affect something on screen, to create palette cycling effects.

I don't mind how this limitation is applied - it could affect the whole screen, it could affect individual images, or it could be changed during the draw function, like Pico 8 does, where you can edit the colour index, draw something, then reset the colour palette back to default before drawing anything else (thus it can affect individual sprites, and not affect the rest of the screen).

Is this possible and are there any tutorials or examples to get me started?

[Stifu]

We have color swaps in our game, and I think that's pretty much the same idea. We use shaders for that.
Our color swap definitions are here: https://github.com/thomasgoldstein/zabu ... haders.lua

Example (not the whole code, obviously):

Code: Select all

local rickColors_original = {
    { 196, 81, 15, 255 }, { 133, 55, 10, 255 }, { 60, 27, 28, 255 }, -- orange hoodie
    { 55, 55, 55, 255 }, { 31, 31, 31, 255 }, { 15, 15, 15, 255 }, -- black pants
    { 99, 132, 168, 255 }, { 52, 78, 108, 255 }, { 20, 27, 40, 255 }, -- blue shoes
    { 217, 217, 217, 255 }, { 155, 162, 170, 255 }, { 98, 102, 107, 255 } } -- white shoe stripes
local rickColors_2 = {
    { 196, 196, 196, 255 }, { 135, 135, 135, 255 }, { 76, 76, 76, 255 }, -- white hoodie
    { 56, 91, 149, 255 }, { 29, 53, 97, 255 }, { 16, 25, 56, 255 }, -- blue pants
    { 196, 196, 196, 255 }, { 135, 135, 135, 255 }, { 76, 76, 76, 255 }, -- white shoes
    { 56, 91, 149, 255 }, { 29, 53, 97, 255 }, { 16, 25, 56, 255 } } -- blue shoe stripes
local rickColors_3 = {
    { 51, 58, 76, 255 }, { 27, 31, 40, 255 }, { 11, 13, 17, 255 }, -- black hoodie
    { 174, 183, 188, 255 }, { 96, 101, 107, 255 }, { 48, 50, 53, 255 }, -- light gray pants
    { 193, 57, 50, 255 }, { 137, 21, 15, 255 }, { 53, 8, 5, 255 } } -- red shoes

[Domarius]

Hey, I've seen your Zabuyaki blog in my searches!

Yes swapping colours is essentially what's happening. If I can do that I can probably come up with a way to simulate a global palette.

Hmm... I don't suppose you know how to run an older version of Love2D on Linux? When I try to run your game I get a warning about my Love2D version being 11.1 and your game being 10.1, and then it exits with some code errors.

[Stifu]

Hmm... I don't suppose you know how to run an older version of Love2D on Linux? When I try to run your game I get a warning about my Love2D version being 11.1 and your game being 10.1, and then it exits with some code errors.

I don't really know, I guess it depends on whether you can find it already packaged or not. I saw someone here suggest usine Wine to run the Windows version on Linux, that might work too even though it may not be ideal... Anyway, we plan to migrate to 11.x soon enough.

[pgimeno]

Hmm... I don't suppose you know how to run an older version of Love2D on Linux? When I try to run your game I get a warning about my Love2D version being 11.1 and your game being 10.1, and then it exits with some code errors.

Compile it from sources. Configure with --disable-shared --enable-static to generate a static executable so the LÖVE library is integrated into it and you don't have problems with library paths (but don't distribute that version without reading the LGPL 2.1 carefully first).

I have all versions of LÖVE compiled from sources, from 0.1.1a to the latest. I had to make some adjustments for a few of them to compile, and some older ones can't be compiled static or have other quirks, but the more recent versions are all OK. I named the executables like love11, love10, love9 etc. so I could easily choose which one to run (of course e.g. love10 means 0.10.2; I have 0.10.1 and 0.10.0 too but not in my path).

[Domarius]

Compile it from sources. Configure with --disable-shared --enable-static to generate a static executable so the LÖVE library is integrated into it and you don't have problems with library paths (but don't distribute that version without reading the LGPL 2.1 carefully first).

I have all versions of LÖVE compiled from sources, from 0.1.1a to the latest. I had to make some adjustments for a few of them to compile, and some older ones can't be compiled static or have other quirks, but the more recent versions are all OK. I named the executables like love11, love10, love9 etc. so I could easily choose which one to run (of course e.g. love10 means 0.10.2; I have 0.10.1 and 0.10.0 too but not in my path).

Ah thank you. I'll look into how to do that.

Also I found an AppImage of 10.2, I thought that might be easier, but I couldn't run the game with it. If I gave the "zabuyaki-master" folder as a parameter (the way you normally load games with Love), it just opened up with the "Super Toast" no game screen.

[DarkShroom]

i'd be tempted not to use shaders for that but to edit the pixels of the images when i load, something i plan to do... my two cents

i recon i imagine why you'd rather use shaders though, best wishes with your code

[Stifu]

i'd be tempted not to use shaders for that but to edit the pixels of the images when i load, something i plan to do... my two cents

This might come in handy then: https://youtu.be/uQP6hsD5bEI
I haven't looked into it at all, but I doubt the performances would be as good as with shaders. Not sure the GPU will help in this case.

[Domarius]

i'd be tempted not to use shaders for that but to edit the pixels of the images when i load, something i plan to do... my two cents

i recon i imagine why you'd rather use shaders though, best wishes with your code

Definitely open to other approaches. Not that I've tried the shaders yet but it looks a bit involved.

Though editing the pixels to make a new image means you couldn't do real-time palette animations.

This might come in handy then: https://youtu.be/uQP6hsD5bEI
I haven't looked into it at all, but I doubt the performances would be as good as with shaders. Not sure the GPU will help in this case.

Thanks for the link!

[Stifu]

Though editing the pixels to make a new image means you couldn't do real-time palette animations.

Why not? If it's fast enough...