PX9 Data Compression(lexaloffle.com)
lexaloffle.com
PX9 Data Compression
https://www.lexaloffle.com/bbs/?tid=34058
1 comments
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 (<2MB) and code size (<8K tokens) limitation so that it is actually akin to programming in slightly more powerful BASIC and PEEK and POKE (yes they are actual names).
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.
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.
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.
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.
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.
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.
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.
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.
Then
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 extremely unsafe.
The blog post is tagged "pico-8", which I guess is [1].
1 - https://en.wikipedia.org/wiki/Pico-8