I'm working on a cart for the FC jam, but got this really annoying bug, that doesn't allow me to use 128x64 map space without breaking the sprites. If I will try to mset(0,32), it will corrupt my sprites on page 2. I really need that sprite space, does anyone know a quick solution?

P#45438 2017-10-24 09:34 ( Edited 2017-10-24 19:32)

This is by design.
PICO-8 has a single bank of 128 8x8 sprites, plus another 128 that overlaps with the bottom half of the map data.
:: Base ram memory layout
0x0 gfx
0x1000 gfx2/map2 (shared)
0x2000 map

P#45440 2017-10-24 11:15 ( Edited 2017-10-24 15:15)

I know. But, as you can see, I can't have map bigger than 128x64. And drawing sprites in two last pages must affect the second half of the map, but not the second 1/4.

P#45443 2017-10-24 12:33 ( Edited 2017-10-24 16:33)
:: Felice

But 0,32 is second half, not second quarter.

You said if you mset(0,32) you corrupt sprites, and you show map space as being 64 tiles tall, which it is. That puts tile 0,32 just inside in the second half, so yes, you'd corrupt sprite memory.

You're doing an extra factor of 2 in your head somewhere. You only get map tiles with y=0..31 if you're using all of sprite memory.

If you want to use, say, a map with y=0..47, which means sharing 0x1000..0x1800 with sprites, then you can't use sprites 128..191. Rows 32..47 share space with sprites 128..191.

P#45445 2017-10-24 14:14 ( Edited 2017-10-24 18:14)

Oh no, I always thought, it was 128x64:
> Map 128x32 cels
Just why???
(btw, typo in stats: cels)

Ok, then a lil question: can I use own array to store bigger map (plus own map())? Or it will take to much mem?

P#45447 2017-10-24 14:32 ( Edited 2017-10-24 18:34)
:: enargy

@egordorichev: fwiw, I only use memory for tilemaps (versus the built-in map()). Storing them as tables or strings should be fine.

P#45448 2017-10-24 15:32 ( Edited 2017-10-24 19:32)