
As I am writing this, the changelog for v0.1.1c gives the command to enable the icons to snap to a grid as this:
store("/appdata/system/filenav", {desktop_snap=true})
However, that command does not work. The ACTUAL command needed is this:
store("/appdata/system/filenav.pod", {snap_to_grid=true})
EDIT
The changelog has now been updated with the proper command!

A custom theme for Picotron that tries to recreate the iconic colors of PICO-8's editors.

There are two ways to get this theme into your copy of Picotron. The first one is the more complicated manual process that I originally posted, and the second is just copy-pasting a command or two into the terminal:
Method 1: The manual way





On the latest episode of his advanced shmup tutorial, @Krystman showed off a function for splitting a string into a 2D array, and then said there could be more ways to make it more compact and token-efficient. Guess what I... didn't do?
Well, I didn't make it more token-efficient - my new version is close to double that of the original 28-token function at 55 tokens - but I DID make it more versatile; It can now handle:
- 3,4,5 and onwards dimensional arrays (the original could only do 2-dimensional arrays)
- Any character for use as a separator (the original could only use "|" and ",")
- Optional tonum() conversion (the original had that forced on)
In fact, you could use this function exclusively instead of the built-in split() and you might not even notice. In order to get multi-dimensional arrays, the sep
parameter should be given a string that is more than a single character long, with the most significant separator characters coming first. Oh, uh, after you paste the function into your code, that is. Speaking of which...

Here's a gif of me copying GFX data to code:

Here's a gif of me copying SFX data to code:

And here's a gif of me Copying music data to code:

So far, so good. Every bit of data copied also edits the clipboard, allowing these to be copy-pasted between instances of PICO-8.
But not so for map data! So here's a gif of me attempting to copy map data...

No edit to the clipboard was made. (Prior to each of these I had copied the -- TEST STRING TO COPY
line to make it clearer.) Admittedly, you're not likely to ever need to copy map data between carts, but if you do (such as when working on a multicast game, or if you're transferring ideas from a prototype cart to the cart you plan to use for the full game) then it's gonna be real tricky to do so.
This issue was brought to my attention by the (as of now) latest episode from @Krystman on his advanced Shmup tutorial. Look around the 5:30 mark; he can easily copy the sprite sheet, but map data requires him to edit the P8 files directly, which works... but if you want to make the copied map data appear somewhere else rather than exactly where it was or only copy a small portion of the map, then that still presents a problem.


Yes! If you remember, back in January I had posted a code snippet that would let you play Minesweeper in the Picotron Playground. I later updated that snippet to have some comments describing the settings needed to recreate the three difficulty levels, but otherwise nothing changed. Well now, after months of (not that) hard (but still a little tricky) work, the third version of my Minesweeper game on Picotron is OUT! New features include:
- Easy windowed mode: Running the program will instantly switch to the desktop. No more faffing about with
run_program_inside_terminal
! Who wants to type that out every single time? - A help screen: Just click the handy little blue question mark (?) and you can reference the rules anytime. Also shows up the first time the program is run.
- In-game minefield customization: Nobody wants to edit the code every time just to change the difficulty. Nobody.

One nice thing about objects is that objects set with the =
operator or as arguments are all 'linked' meaning, among other things, you can provide them as arguments for a function call and that function will be able to edit the local copy of that object and have it affect the original one too. But sometimes, you don't want that. Sometimes you want to copy an object, make changes to it, and then discard the new copy without affecting the old one. That's why I've created a little helper function for this circumstance. Actually, I've created several. Here's the fully-featured 'default' function:
function cpy_obj(obj,recursion) if type(obj)=="table" then local return_value={} for k,v in pairs(obj) do if recursion then v=cpy_obj(v,true) end return_value[k]=v end return return_value else return obj end end |
Usage: copy= cpy_obj(𝘰𝘣𝘫𝘦𝘤𝘵)
or function_call( cpy_obj(𝘰𝘣𝘫𝘦𝘤𝘵) )
