@zep I've noticed that the pal() function returns values > 15 when the c0 parameter is 0
such as:
pal(0, 5)
I'm running 0.2.0I linux 64 bit, ubuntu 20.04
I've attached a simple cart that demonstrates the problem.
Thanks.
Maybe it’s by design? You’ll get c+16 instead of c if the color has the transparency bit set.
I though that at first, but sometimes I get the value + 32 and it only happens on palette index 0, so I'm not sure. It may be by design but I cant quite work out the logic to it.
ok after some more testing it does seem to be if the transparency bit is set, thanks for pointing that out. not sure why I saw the +32. cant seem to replicate that now, it was late last night when i was looking at it, so could have been anything.
doesnt seem like you can set the transparency by adding 16 to the colour in the pal function which is a shame.
I've noticed another issue with the pal function in the form that takes an array of colours.
it seems it starts setting the values from index 1 and not index 0.
see following screen shot for a demo:
if you supply 16 values in the array, that last value wraps and is set into index 0
It looks like pal() returns whatever was at address 0x5f00+c, so if you poke out-of-bounds values in there, it’ll happily return what was there. I think this is the best behaviour because it accounts for future extensions of that address space.
> poke(0x5f05,137) > ?pal(5,12) 137 |
yep, that's definitely what seems to be happening, thanks for the explanation. I didnt realise that the transparency bit was stored in the same byte as the palette mapping
looks like pal() uses the actual table indices:
> pal({[0]=11,7,8,9,10})
> ?@0x5f00
27 |
“Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration.” - Stan Kelly-Bootle
Yeah, the table indices dictate where the values go, and only the valid indices get written. This allows us to have ranges of the palette that we change independently without overwriting others:
-- draw palette (#0) layout
--
-- 0-7 = background colors
-- 8-10 = ui colors & fleshtone
-- 11-12 = lightsaber colors
-- 13-15 = clothing colors
saber_red = {[11]= 8,[12]=14}
saber_green = {[11]= 2,[12]=11}
saber_blue = {[11]=13,[12]=12}
cloth_brown = {[13]= 2,[14]= 4,[15]= 9}
cloth_white = {[13]=13,[14]= 6,[15]= 7}
cloth_black = {[13]= 0,[14]= 1,[15]= 5}
pal(saber_red)
pal(cloth_black)
spr(jedi_sprite, vader.x, vader.y)
pal(saber_blue)
pal(cloth_brown)
spr(jedi_sprite, ben.x, ben.y)
--pal(saber_blue) -- already set
pal(cloth_white)
spr(jedi_sprite, young_luke.x, young_luke.y)
pal(saber_green)
pal(cloth_black)
spr(jedi_sprite, older_luke.x, older_luke.y) |
Needing the indices is slightly annoying when you want to change 0, but honestly most of the time we leave 0 as black, so stuff like tweetcarts will usually work out without needing any [0]= shenanigans.
@Felice yeah I get what you are saying but the description in the change log contradicts this behaviour:
Added: pal({1,2,3..}) means: use the value for each key 0..15 in a table |
so from this it suggests the the first index int the table (1) will set the first colour (0)
however the examples given in the body of pico-8.txt:
For example, to re-map colour 12 and 14 to red:
PAL({[12]=9, [14]=8}) |
contradict this, and this one:
Or to re-colour the whole screen shades of gray (including everything that is already drawn):
PAL({1,1,5,5,5,6,7,13,6,7,7,6,13,6,7}, 1) |
is actually ambiguous and confusing (especially for novices.) as the last item in the list (element 16) will set palette entry 0 to 7
hopefully @zep can clarify.
I agree the manual seems unclear, but given that he said "key", I'm at least certain this is the intended behavior.
Probably the manual just needs to be clearer.
Interesting find about [16] setting [0]. He must mask the key with 0xf so invalid keys don't break anything. This should probably be called out as an alternate method, since it saves tokens over using [0]=n.
[Please log in to post a comment]
