PX9 Data Compression
lexaloffle.com
PX9 Data Compression
1–8 of 8 posts
Re: PX9 Data Compression
#2 px9_comp(x,y,w,h, dest_addr, vget)
returns the number of bytes written
reload(0x0, 0x0, 0x2000, "mycart.p8")
clen = px9_comp(0, 0, 128, 128, 0x2000, sget)
cstore(0x0, 0x2000, clen, "mycart_c.p8")
Is there an implicit constant buffer size in the framework, language or device, like a single page or something?
To a C programmer, this looks extremely unsafe.
The blog post is tagged "pico-8", which I guess is [1].
Re: PX9 Data Compression
#3px9_comp(x,y,w,h, dest_addr, vget) returns the number of bytes written Then reload(0x0, 0x0, 0x2000, "mycart.p8") clen = px9_comp(0, 0, 128, 128, 0x2000, sget) cstore(0x0, 0x2000, clen, "mycart_c.p8") This function does not accept the output buffer size as an argument. Is there an implicit constant buffer size in the framework, language or device, like a single page or something? To a C programmer, this looks extreme…
PICO-8 is a "fantasy console" with an arbitrary limitation to imitate the real world console in the past century. While it uses Lua as a scripting language, it comes with very severe memory (To elaborate what happens when the buffer overflows... The official README explains that map (normally sprites) starts at 0x2000 and some other data starts at 0x3000. Therefore it will start overflowing other data, and depending on what you expect in those area, it may or may not break the game. The entirety of PICO-8 is intentionally constructed in this way to give its look and feel.
Re: PX9 Data Compression
#4px9_comp(x,y,w,h, dest_addr, vget) returns the number of bytes written Then reload(0x0, 0x0, 0x2000, "mycart.p8") clen = px9_comp(0, 0, 128, 128, 0x2000, sget) cstore(0x0, 0x2000, clen, "mycart_c.p8") This function does not accept the output buffer size as an argument. Is there an implicit constant buffer size in the framework, language or device, like a single page or something? To a C programmer, this looks extreme…
Yeah, very unsafe-looking API. Maybe the assumption is that output buffer is at least w*h bytes in size (I think this is for indexed-color images, so each pixel is presumably a byte).
Re: PX9 Data Compression
#5px9_comp(x,y,w,h, dest_addr, vget) returns the number of bytes written Then reload(0x0, 0x0, 0x2000, "mycart.p8") clen = px9_comp(0, 0, 128, 128, 0x2000, sget) cstore(0x0, 0x2000, clen, "mycart_c.p8") This function does not accept the output buffer size as an argument. Is there an implicit constant buffer size in the framework, language or device, like a single page or something? To a C programmer, this looks extreme…
PICO-8 uses lua and has strictly specified resource constraints (fix sized palette maps).
This is a clever little hack to save space which is already artificially constrained. Part of the fantasy console concept is to pick constraints like token counts in code being limited and sprite memory limits. These limits make finding ways around them fun and sometimes requires creativity like this compression scheme which needs to fit within the limited code space.
Re: PX9 Data Compression
#6px9_comp(x,y,w,h, dest_addr, vget) returns the number of bytes written Then reload(0x0, 0x0, 0x2000, "mycart.p8") clen = px9_comp(0, 0, 128, 128, 0x2000, sget) cstore(0x0, 0x2000, clen, "mycart_c.p8") This function does not accept the output buffer size as an argument. Is there an implicit constant buffer size in the framework, language or device, like a single page or something? To a C programmer, this looks extreme…
PICO-8 is a "fantasy console" with an arbitrary limitation to imitate the real world console in the past century. While it uses Lua as a scripting language, it comes with very severe memory ( To elaborate what happens when the buffer overflows... The official README explains that map (normally sprites) starts at 0x2000 and some other data starts at 0x3000. Therefore it will start overflowing other data, and depending…
One of the example games distributed with PICO-8 has a "glitch mode" that POKEs at a random spot in memory every few seconds. The game becomes progressively more corrupted as you play, creating an effect similar to a NES cartridge that needs cleaning.
Re: PX9 Data Compression
#7px9_comp(x,y,w,h, dest_addr, vget) returns the number of bytes written Then reload(0x0, 0x0, 0x2000, "mycart.p8") clen = px9_comp(0, 0, 128, 128, 0x2000, sget) cstore(0x0, 0x2000, clen, "mycart_c.p8") This function does not accept the output buffer size as an argument. Is there an implicit constant buffer size in the framework, language or device, like a single page or something? To a C programmer, this looks extreme…
Yeah, very unsafe-looking API. Maybe the assumption is that output buffer is at least w*h bytes in size (I think this is for indexed-color images, so each pixel is presumably a byte).
It's a toy virtual machine with (iirc) fixed memory and fixed address space, running in a sandbox. so an overflow isn't really a big concern.
Re: PX9 Data Compression
#8px9_comp(x,y,w,h, dest_addr, vget) returns the number of bytes written Then reload(0x0, 0x0, 0x2000, "mycart.p8") clen = px9_comp(0, 0, 128, 128, 0x2000, sget) cstore(0x0, 0x2000, clen, "mycart_c.p8") This function does not accept the output buffer size as an argument. Is there an implicit constant buffer size in the framework, language or device, like a single page or something? To a C programmer, this looks extreme…
A couple more clarifications: the addressable 32k memory space is mapped out like an old 8-bit micro (here's a diagram I drew: https://twitter.com/weeble/status/1112527587014787082?s=19 ) and is isolated from real RAM. Code, the lua VM and heap, none of that is accessible via this address space. There's also no allocator. It's up to you to arrange data by hand in the user data region. Pretty much the worst possible consequence of a buffer overflow is stomping the graphics attributes and turning the screen into a kaleidoscope.
Given the other constraints of the system, the main place this code is likely to be used is in a script dedicated to assembling a "cartridge" file, and if the output overflows the target space (likely map or gfx ram) then it's just going to bail out with an error anyway, it's unlikely to care about the stomped-over RAM, given that it can't affect Lua variables or code.