Log In  

At 0x5f10..0x5f1f you can remap the screen palette. You can't change it to something other than PICO-8's native colors, but if you wanted to flash anything yellow you could do this in your draw:

    poke(0x5f1a, flash and 7 or 10)
    flash = not flash

This is handy if you need to cycle colors on parts of your screen that you can't afford to redraw.

It also might be handy for avoiding a lookup table if you were writing a demo that drew a grayscale image, because you could do this:

    poke(0x5f10, 0)  --black
    poke(0x5f11, 5)  --dark gray
    poke(0x5f12, 13) --gunmetal gray
    poke(0x5f13, 6)  --light gray
    poke(0x5f14, 7)  --white
    :
    :
    pset(x, y, intensity0to4)

Or similarly for large rainbow ramps like you'd use for fractals. No lookup table needed.

I hope this is okay to use. Zep? :)

P#23900 2016-06-29 19:13 ( Edited 2016-06-30 03:01)

I'm confused, isn't this what pal() does?

P#23901 2016-06-29 19:39 ( Edited 2016-06-29 23:39)

Is animated color cycling usually done via pal() calls? Graphical effects somewhat elude me in Pico8

P#23904 2016-06-29 19:51 ( Edited 2016-06-29 23:51)

No, pal() only affects stuff you draw after it. It translates colors during draw calls.

This affects the actual screen. You can change screen colors just by sitting at the prompt and poking values into those registers. It's a bit like changing a gamma ramp on real hardware, except it's a palette instead of a ramp. It would be in the ramdac on real hardware, rather than the rasterizer, which is where pal() lives.

P#23905 2016-06-29 20:19 ( Edited 2016-06-30 00:23)

It's very useful if you want to change the editor's default colors.
It was discussed a while ago on https://www.lexaloffle.com/bbs/?tid=2275

It seems like Zep was okay with it since he removed the alternate colors but kept the addresses functional.

Great find nevertheless!

P#23908 2016-06-29 20:37 ( Edited 2016-06-30 00:37)
No, pal() only affects stuff you draw after it.  It translates colors during draw calls.

not true: pal() can operate on two different palettes, the draw palette and the screen palette.

pal c0 c1 [p]

        Draw all instances of colour c0 as c1 in subsequent draw calls

        pal() to reset to system defaults (including transparency values)
        Two types of palette (p; defaults to 0)
                0 draw palette   : colours are remapped on draw    // e.g. to re-colour sprites
                1 screen palette : colours are remapped on display // e.g. for fades
        c0 colour index 0..15
        c1 colour index to map to
P#23910 2016-06-29 20:44 ( Edited 2016-06-30 00:44)

Oops, that's what I get for not reading the entire blurb for the function. Well, darn.

Mind you, you could save a few cycles or tokens by doing a memcpy() into that block from a stored palette instead of doing a bunch of pokes. Maybe it'll be useful to someone.

P#23912 2016-06-29 21:02 ( Edited 2016-06-30 01:02)

So I'm guessing from that other thread that 5f0x is the current rasterizer palette. Hm, interesting.

I wonder why there are function calls for it. I guess it's more convenient than having to know c64-style hex addresses by heart.

LDA #$4F
JSR $FFD2
LDA #$4B
JSR $FFD2

P#23915 2016-06-29 21:12 ( Edited 2016-06-30 01:12)

The memcpy() trick does sound useful. Thanks!

P#23932 2016-06-29 23:01 ( Edited 2016-06-30 03:01)

[Please log in to post a comment]

Follow Lexaloffle:          
Generated 2024-03-29 09:15:14 | 0.009s | Q:18