Log In  


Hi, I was trying to cache an entire frame in ram to be able to blit it later on on screen.

However the user defined memory is not big enough to hold an entire frame (lacks 1kB)

Fair enough, as I was not using sfx at all, i tried to overlap on that memory but for some reasons some bytes in that area seem to be masked and cannot take value greater than 0x7F

So my question is: Is there a place in RAM where i can safely read/write the extra 1024 bytes i need to cache an entire screen frame ?



This is more of a workaround, but you could try compressing your frame with some basic method, like RLE (https://en.wikipedia.org/wiki/Run-length_encoding). This could work if the frame you want to save contains lots of repeated data (like black pixels as the main background, for example).

This way a full screen of black pixels could be saved as:
"163840", where 0 stands for the black color and 16384 for the number of pixels in sequence that share that same color.

TLDR;
I don't know, you could try compressing it.


Hi MaikelOrtega,

thanks for your answer, yes I could compress quite easily but what I want is very fast blitting using memcpy.

Else I could have simply stored my 8kB cached frame in the lua ram but then indirection and pset would have ruined performance.

Anyway I have seperated my frame in two: first 4kB in map data (which im not using either) and the other 4kB in user defined memory and it works.

I'm still wondering why I was not able to store raw data to sfx memory. This is only data right, there s no state so why is there what seems to be a check on sfx data integrity.


in the cart "shodo" (https://www.lexaloffle.com/bbs/?tid=2033) it's the ram
from 0x1000 to 0x2fff (gfx2 + map) that is used to store the frame, you can read the explainations in the picozine 2 (http://sectordub.itch.io/pico-8-fanzine-2)


@Hatscat you're right, but shodo faces the same problem as @J-Fry, and uses the same solution: user defined + map data.


> for some reasons some bytes in that area seem to be masked and cannot take value greater than 0x7F

That looks like a bug -- I've listed it to be fixed for 0.1.3



[Please log in to post a comment]