Log In  



I am having weird issues with passing an array of numbers into pal to change the color palette. A rectfill that before was meant to fill with the color 0, the darkest blue, refuses to fill with that specific color anymore and uses the color 1. I have tried other colors and they work just fine. Does anybody know what is going on here?

Are you remembering to set the palette-persist bit? This code works for me for changing palette color #0 to -15:

 
poke(0x5f2e,1)
pal({1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,-15},1)
for x=0,15 do
    rectfill(x*8,64,x*8+7,72,x) -- horiz. line of color swatches
end


i do have it set in init, yes

make a new test cart that shows this same bug, then remove as much code as you can until you have a minimal cart that has the bug. then post that here so we can help! (or you might just solve it yourself during that minimizing process)

maybe you're resetting the screen palette later in the frame, but again it's really hard to help without some code. (the code screenshots you posted already look fine, so the problem is probably somewhere else)
1

here's the most minimal test cart i was able to make. it seems the issue only happens after a screen transition is called, but other than that i still do not know what is going on.

Cart #pimerizepe-0 | 2024-06-02 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA
1

nice! I added my logging/debugging library and figured out that the issue is that currentpal reaches 6, which is out of bounds. this results in pal(nil,1) eventually, which for some reason breaks things permanently (?? I don't understand why). A simple fix for your cart is to clamp currentpal like this: currentpal=mid(1,5,transitiontime\5+1)

here's minimal code for the remaining mystery:

 
function _init()
  -- why does uncommenting this next line break things?
-- pal(nil,1)
end

function _draw()
    cls()
    pal({14,13,12,11,10,9,8,7,6,5,4,3,2,1,0,15},1) --reverse palette
    for i=0,15 do
        x,y=i%4,i\4
        rectfill(x*8+32,y*8+32,x*8+39,y*8+39,i)
    end
end

edit: ahhhh the reason pal(nil,1) messes things up is because pico8 decides to convert nil into a number, and so it ends up running pal(0,1), remapping color 0 to color 1. that's a really nasty interaction here... I often wish pico8 didn't do this sort of nil-to-zero conversion. well, at least it makes sense now

thank you so much! very funny interaction indeed lol



[Please log in to post a comment]