Hey there,
according from the Wiki-Page about Memory, it is unclear what a Poke to address 0x5f5e does, right?
0x5f5e-0x5f7f / 24414-24447 The remaining registers up to 0x5f7f are undocumented. |
I was playing around a bit and found something out: It seems to "reduce" the Colors that can be used. For example, poking a "1" reduce the Palette to only 2 Colors, Black and Dark-Blue.
A simple Description: It seems that poking around 0x5f5e is some sort of "pal" all over the Color-Palette, but also prevents you to "pal" another Color. For Example: If you poke a "1", "pal" is limited to set a Color to blue or black only.
I just uploaded a Cartridge where you could play around with that:
I didn't found anything about that address in PICO-8, so I thought, it can be useful for others and like to share that^^. (I already imagine some sort of "Switch the Game from a NES-like-Palette to a GB-like-Palette", or something like that^^.)
Cheers.
Cool find!
This could actually be extremely useful for a method I've been thinking about to maximize storage, thanks!
I'm finding out that sometimes just fiddling around can lead to some of the best ideas.
This looks like a bitmask that's applied to all colors before being drawn, but only when the value is > 0.
Since black in binary is 0000, and dark blue is 0001, they stay the same when the bitmask is 0001. Basically, this tells you whether the color in binary is odd (blue) or even (black).
When the bitmask is 3 (e.g. 0b0011), the first four colors are the only ones that can be drawn. When it's 5 (e.g. 0101 in binary), the colors that work are black (0000), dark blue (0001), brown (0100), and gray (0101). Anywhere the bitmask has a zero in binary, the color loses its 1 before being drawn. It'll be hard to use that for palette swaps, but it's a neat feature none the less!
interesting (though not sure about practical use...) unless it can be coupled with some other flag
I agree it doesn't seem to do a lot on its own, but I was thinking of using it in conjunction with something else. I've been thinking about multiplying the effective sprite sheet space (or shrinking the sprite footprint) by encoding it with "layers" of lower bit-per-pixel sprites, and using palette swaps to make them look correct ingame. This would make the sprite sheet appear as a rainbow mess in its raw form, but with this trick, viewing the "layers" correctly would be very easy. This could of course be done in other ways, but it's a very nice feature.
@JadeLombax: That's a cool idea for using this bitmask! Though my concern would be that four 1-bit sprite layers would be stuck drawing the four colors at positions 1, 2, 4, and 8 only, possibly using a screen palette to make that raw data look like a cohesive set of colors on display.
A better option could be to use the "Draw palette look-up table" at 0x5f00. You can memcpy 16 bytes there to set all draw colors and transparencies for your low bit depth layer at once, then just draw any sprite from your graphics data normally. This method lets you set the color drawn by a layer per draw call, and saves the screen palette for fades and other global screen effects.
If you're looking for more graphics space, check out zep's px9 compression as well. Or multicarts, but from what I've heard that is forbidden technology that no one must use. :P
@shy: Thanks for pointing out the palette lookup table, sounds very useful.=)
I'm not really worried about the colors not being directly fit for viewing, though, so long as they have a proper brightness ramp so the images are decipherable before they've been recolored for in-game use, kind of like NES CHR graphics viewed in a tile utility. Recoloring sprites and tiles on the fly was a big part of memory savings in old games, so I'd definitely want to use that approach. I've also written a little function that draws horizontally symmetrical sprites using half a sprite on the sheet, and recolors each side for some basic lighting (see the little spaceship in my avatar picture).
I've looked a little at px9, and it looks promising, I'm just a bit concerned that it consumes time and a chunk of tokens for decompression, and requires either leaving a big chunk of memory space free for decompressed data during runtime, or creating and managing a buffer in memory. I guess I'll figure out my strategy as I go.
@JadeLambax much simpler option, just using palette: https://8bit-caaz.tumblr.com/post/171458093376/layering-sprite-data
Okay, I've tested this and I suspect that what people were saying above is slightly incorrect.
If you draw to a black screen, then yes it will appear that the colors are being masked with this value.
However, if you draw to a screen filled with another color, you won't get what you'd expect from that theory, because this mask actually applies to the write, where it's saying which bits in the destination actually get written.
Effectively, if this value is between 1 and 15, it's a destination write mask.
I documented it here:
https://pico-8.fandom.com/wiki/Memory#Hardware_state
That being said, a read mask would also be nice. I'll post a suggestion that the top 4 bits be used as a read mask, since they're currently unused.
Huh? It seems that my Cartridge (on my 1st Post) doesn't work anymore on 0.2.0h ^^ (I can't figure out why...^^)
Looks like zep engages both the write AND read masks if any bit is nonzero, so you need to set the read mask to all 1's to make it work like it did.
Do this in your _init():
value=0xf0 min_value=0xf0 max_value=0xff |
I'll tweak the wiki page to reflect this, since I was also under the assumption that you could do just one or the other.
Thank you. I just updated the Cartridge, just in case^^.
[Please log in to post a comment]
