Log In  

For literally-years now I've had this comment at the top of my Kid Radd cart, right under the label comments:

--__ext__
--pal[1]=0x243566
--pal[6]=0xc0c2e3
--pal[12]=0x576dff
--pal[14]=0xff5e98

Although more recently, Pico-8 has become able to properly handle standard Lua multi-line comments, so that could be changed to a cleaner block with a defined ending, like this:

--[[__ext__
pal[1]=0x243566
pal[6]=0xc0c2e3
pal[12]=0x576dff
pal[14]=0xff5e98
]]

These comments are entirely unused, waiting for some kind of extension format to come along and read metadata to make modifications to the machine before the cart runs as normal. With the theory being that the block of comments could be "cut out" of the script and run as their own, separate, "configuration script" with reasonable ease, using an extension API of some sort. In this case, the configuration script expects to be given an array named "pal" (no relation to the Pico-8 command of the same name) which is pre-populated with Pico-8's default palette, and then internally gets read back to set the screen palette before the game script even begins.

However, if such extensions were made widely available, perhaps in some third party pico-8 emulator (as there are a few floating around), it's more likely they'd take an active role in the game script (and therefore token count) such as this:

if __ext__ and __ext__.palette then
 local remap=__ext__.palette
 remap(1, 0x24, 0x35, 0x66)
 remap(6, 0xc0, 0xc2, 0xe3)
 remap(12, 0x57, 0x6d, 0xff)
 remap(14, 0xff, 0x5e, 0x98)
end

This would allow certain extension-enhanced Pico-8 games to potentially remap the colors of the Pico-8 palette in realtime between frames to subtly tune the color outputs for each scene, and would still be playable on a vanilla pico-8 without color modifications because "__ext__" would be nil and therefore evaluate as false, skipping the entire code block.

As far as I'm aware, various Pico-8 web player wrappers exist which manipulate input types and gpio pins, but none have gone so far as being capable of remapping the palette colors or added other noncanonical extensions to the api itself, to be run by each individual cart to apply their own mods and settings.

tl;dr? start here

So, if there were a third-party extension api which some games could use to improve their quality in some way, and those carts may or may not retain backwards compatibility with unmodded pico-8, how would you design the extension api and what kinds of neat features would it have?

Would you add new common optimization functions to try and reduce cpu usage of otherwise sluggish games? (Assuming your pico-8 emulator even respects cpu restrictions, of course!) Would you add completely new rendering modes? Would you make a new bank of memory available like an N64 expansion pack? Would you add a new widescreen aspect ratio mode, or even break the 127x127 screen resolution somehow?

Tell me what you'd do and how you'd do it! What kind of code would you put in the cartridge's script to "activate" and use your extension features?

P#41494 2017-06-09 15:49 ( Edited 2017-06-09 19:49)


[Please log in to post a comment]

Follow Lexaloffle:          
Generated 2024-04-18 04:07:33 | 0.005s | Q:9