Log In  

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:

Cart #poke0x5f5edemo-1 | 2020-05-08 | Code ▽ | Embed ▽ | No License
10

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.

P#75691 2020-05-01 12:30 ( Edited 2020-05-08 07:54)

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.

P#75693 2020-05-01 13:41 ( Edited 2020-05-01 16:05)
:: shy
2

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!

P#75709 2020-05-01 20:12

interesting (though not sure about practical use...) unless it can be coupled with some other flag

P#75710 2020-05-01 21:08
1

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.

P#75712 2020-05-01 23:17 ( Edited 2020-05-01 23:27)
:: Felice

Ooo. Must investimagate.

P#75713 2020-05-01 23:39
:: shy

@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

P#75722 2020-05-02 01:55

@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.

P#75725 2020-05-02 02:32 ( Edited 2020-05-02 02:44)

@JadeLambax much simpler option, just using palette: https://8bit-caaz.tumblr.com/post/171458093376/layering-sprite-data

P#75737 2020-05-02 06:15
:: Felice
1

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.

P#76044 2020-05-07 13:52 ( Edited 2020-05-07 13:53)

Huh? It seems that my Cartridge (on my 1st Post) doesn't work anymore on 0.2.0h ^^ (I can't figure out why...^^)

P#76089 2020-05-07 19:36 ( Edited 2020-05-07 19:37)
:: Felice
1

@Astorek86

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.

P#76110 2020-05-08 07:25 ( Edited 2020-05-08 07:25)

@Felice

Thank you. I just updated the Cartridge, just in case^^.

P#76115 2020-05-08 07:57

[Please log in to post a comment]

Follow Lexaloffle:        
Generated 2020-10-25 20:19 | 0.091s | 4194k | Q:57