There's been quite a bit of chat on the discord about bitplanes. So:
Unmangled source:
frame=0 function _init() poke(0x5f5f,0x10) pal(1,8,1) pal(2,11,1) pal(3,10,1) pal(4,12,1) pal(5,128+8,1) pal(6,128+11,1) pal(7,7,1) end function radfunc(off) --added 0.1 to avoid an unsightly blip at 1.0 return cos((off&0xff)/256+0.3)*10+20 end function xfunc(off) return 64+(30+10*sin(frame/600))*cos((off&0xff)/256+0.1) end function yfunc(off) return 64+(20+5*sin(frame/600))*cos((off&0xff)/256+0.2) end function _draw() cls() local off=frame for c=0,2 do poke(0x5f5e,0x11 << c) circfill(xfunc(off),yfunc(off),radfunc(off),15) off+=85 end end function _update() frame+=4 end |
It took me a bit to figure it out, but I like the bitwise AND trick used with 255 (0xff) to ensure that the value of 'off' divided by 256 would never exceed 1.
I'm still perplexed as to how the color magic works. I couldn't find much about PICO-8's 0x5f5f memory location. What does that do? It also seems to be that you're painting each circle the same color (15), but the palette is only messed with in _init().
Care to share your design process?
@zlg, I was reading about it here. Should be possible to invoke to create interesting shadow and transparency effects.
See the explanation for 5f5e here:
https://pico-8.fandom.com/wiki/Memory
dst_color = (dst_color & ~write_mask) | (src_color & write_mask & read_mask)
because I write 0x11<<c to the register, this means write_mask = read mask = 1<<c
as src_colour = 15 = 0xf this all boils down to
dst_color = (dst_color & ~(1<<c)) | (1<<c)
ie, any draw operation will set only bit c of the screen.
[Please log in to post a comment]