This is a little tool for viewing all possible 4x4 fill patterns, after removing duplicates which are the same pattern inverted, translated, rotated, or flipped in x/y/diagonally. There are 65536 possible raw fill patterns (1 << 16), but only 433 unique patterns once "equivalent" ones have been discarded.
To use a fill pattern that you like, prefix it with "0x" (it is a hexadecimal number) and pass it fillp():
fillp(0x95a6) circfill(64,64,40,0xacd) fillp() -- reset |
Press UP and DOWN to browse the catalogue, [X] to invert and [O] (z/c) to hide the info bar.
I don't know if there is a more efficient way to calculate groups (or the number of groups) for these equivalence relations, but PICO-8 is more than fast enough to brute force it, so that's what this cartridge does! For each 16-bit fill pattern, its group id (the "orbit") is calculated by applying every combination of transformation and returning the lowest result. If that value not already found in the list of patterns, it is added.
I was able to take a few shortcuts though -- for example, calculating 90 degree rotations is not necessary, because for every orientation there is a combinations of flipping in x, y and through the diagonal (transpose) that is equivalent to that rotation.
6 comments
Hey All! I've been trucking on some Picotron stuff a bit lately, and I've added a lot of it to the current build of Picotron Playground which you can play around with in your browser here:
https://www.lexaloffle.com/picotron.php?page=playground
A quick recap for some context: Picotron is a fantasy workstation that aims to be extremely hackable and flexible. It is not quite in production yet, but an experimental web version is available ~ that's what "Picotron Playground" is. The desktop version of Picotron, with built-in dev tools + HTML exporter are planned for later this year.
For more background, see also: Part I: The release thread
Code Editor
The code editor is now implemented as a GUI component that anyone can embed in their own programs. This will make it easier to create things like bespoke programming toys and scriptable level editing tools. Have a look at /demos/proggy.p64 to see how this works (although, that api might change a little later). It is still janky, but now janky in a more powerful way!
cd /demos load proggy.p64 --> CTRL-R |
Click a button to load each snippet, and type for live changes. For example try copying and pasting the 'paint' snippet into the bottom of 'decay' or 'sand'.
Side note: proggy.p64 has multiple tabs open when you load it-- each of these is a running a separate process (edit /system/tools/code.lua). This way, tools can focus on having a single file open, and let the WM handle having multiple files open in a unified way.
Palette
The palette has changed a little since v7, and I think possibly this will be the finished Picotron system palette. 16 is a smidgen duller, 23~26 are slightly brighter, and 30 is now a much brighter magenta. I don't know if anyone has gone very deep into the palette yet, but here's the new version for reference:
It is possible to set RGB values for the palette in Picotron, but windowed applications will need to lean heavily on the default 32 colour palette, and I think it will often be used as a starting point for building other palettes.
Graphics API
The graphics pipeline design document now including a step-by-step summary of how a pixel is drawn (near the end): https://www.lexaloffle.com/dl/docs/picotron_gfx_pipeline.html
Indexed Display Palette
v.8 now includes an indexed display palette (64 bytes starting from 0x5480) similar to PICO-8's one. It defaults to an identity palette (0, 1, 2..) and so has no effect. The display palette provides an easier way to do palette swaps & cycles etc at the end of each frame without having to mess around with the RGB display palette.
Separate Target Mask for Shapes
Shape drawing functions (circfill etc) now get their own separate target_mask at 0x550b that defaults to 0. The target mask is applied to whatever value is already in pixel to be drawn over, so 0 means "don't care about what is already there". There are two reasons for this:
The first is that the default behaviour when drawing colour 0 is now for it to be drawn solid, while sprites can at the same time be drawn with transparency for colour 0. This is much more intuitive and also matches PICO-8's behaviour.
The second reason is that drawing horizontal spans can be optimized when not caring about what colour values are being drawn over: when target_mask is 0, each output value is only a function of the draw colour(s) and fill pattern. I've reduced the (fantasy) cpu cost in this case by 50% and can likely reduce it further later after optimising that code path.
Default Colour Table Stencil Bit Values
The behaviour of pal() and palt() have been changed to make it easier to set (and ignore) stencil bits:
https://www.lexaloffle.com/dl/docs/picotron_gfx_pipeline.html#Colour_Tables
(near the end of that section)
Setting palette entries
Instead of poking, you can use pal(1, 0xrrggbb, 2) to set rgb palette entries.
pal(1,0xff0000,2) -- too red circfill(200,100,50,1) |
It can also take a table of entries like PICO-8:
pal({0xff0000,0x00ff00,0x0000ff},2)
for i=1,3 do circfill(200 + i*50,100,20,i) end |
PODs
PODs (Picotron Object Data) are strings that store the contents of Lua values, sort of like JSON. They're used for many things internally, but none of them are very relevant to Picotron Playground (yet?). v.8 includes some improvements to the POD format, and the result is that it will eventually possible to store images, maps and other data very quickly, with reasonable compression built in -- straight from the Lua object to disk and back again. If you're curious, you can find some details here:
https://www.lexaloffle.com/dl/docs/picotron_pod.html
Trivia: since the start of Lexaloffle I've been working with .pod files, generated by my in-house editing multitool called Poido (from "Pointy Dough" because it includes a low-poly modeller, but I use it mostly for bitmap editing and palette design). I thought that with Picotron I'd finally be free of pod files, but it turned out to be the most fitting name once again!
One thing you can try: paste this POD into the code editor and hit enter a couple of times to get an embedded image (that as legal lua source code returns the scrawled star sprite that is being shown in the editor).
--[[pod_type="image"]]unpod("b64:bHo0AO4AAAD8AAAAcXB4dQBAAAAEANABAAAAAwTw0B8d8C0uAwCwLD7wK17wKW7wKH4DAPEBJ57wJa7wJL7wI87wI97wIgMA_UEh7vAg-gHwCn6w-gLwCr5w-gPwCf4AMP4VcP4ogP4lsP4kwP4i4P4g8AH_HvAC-h3wBP4b8Ab_GPAJ-hbwCv4V8Az_FPAN-hPwDv4S8A-_EQQAABQAAAQA8CMN-gIwzvAN-gBgvvAN7oCu8AzuoJ7wC97QjvALvvACbvALjvAGXvAKfvAIXvAJfvAKXgkA8BEMXvAIPvAPTvAHPvARPvAHLvATLvAHHvAVDvAvDvD-gw==") |
It is a userdata object compressed (first with RLE encoding and then with lz4) and then re-encoded back into a text-friendly form as base-64. Whenever you copy an object in Picotron (like a sprite or section of map), it will be encoded like this for easy sharing between programs and other users.
You might also notice some .info.pod files lying around -- these are used to store per-folder metadata but will eventually be hidden. Per-file metadata is stored within the pod format itself.
Other Stuff
-
Proper CPU model -- infinite loops won't bring the system down, and each frame, the available CPU is shared around each process.
-
64-bit pokes: you can use poke8 / peek8 and the new peek operator *
-
aliasing can be implemented by mounting files -- "ls" is now aliased as "dir"
-
see /demos/stencil.p64 for an example of using stencil bits
- try out rnd_blend and/or stretch at the start of /demos/chonky.p64
Here's an orange and some sandwiches for The Wizard. Use the dpad (or cursors) to control the owl, and watch out for castle creatures. Also, take care of the basket ~~ if it hits a wall too hard, it might smash. Good luck!
This is a short game made for Ludum Dare vol.53
It's Lovebyte this weekend, and I made a couple of size-coded intros for it. First up is an invite to another demoscene party: SESSIONS in C4 LAN 2023 SPRING, taking place in Shizuoka / Japan end of April. This one is 512 bytes, around 100 of which are for the music (don't wait for the drop!):
I also tried a bunch of 64 byte intros based on poking semi-structured patterns into ram that could double as audio and visual data. This is the one that I submitted to the 64 byte compo:
t=9::_::i=t^4 poke(i,51&(t*(i>>9)*(i%64)/♥)) t+=1/♥ sfx(i)goto _ |
Here's a variation that has more of a horror feeling:
t=19::_::i=t^4 poke(i, 0xdb&(t*(i>>7)*(i%64)/♥)) t+=1/♥ sfx(i)goto _ |
If you want to try these in a browser, you can copy and paste them into PICO-8 Education Edition.
I didn't have time to make 128 byte & 256 byte entries, which happen to be the two compos that have their own dedicated fantasy console sections! But I'll definitely be back next year -- it's great to have a whole party focused on size-limited prods, and that is inspiring so many great pieces of work. There are more events happening tonight (Sunday, UTC) and you can catch them live on twitch or archived on youtube. You can find a schedule on the lovebyte website. Good luck to those taking part tonight! <3
27 
|
More bugfixin'
PICO-8 0.2.5f 0.2.5g is up now up on lexaloffle, Humble, itch.io, and for PocketCHIP and web (Education Edition).
v0.2.5g Changelog:
Fixed: tonum("123abc") returns 123 (should return nothing) // also breaks split(). regression in 0.2.5f
Fixed: draw_tabs not listed by CONFIG command
v0.2.5f Changelog:
Added: CONFIG DRAW_TABS 1 to show tab characters in code editor (previously required editing config.txt)
Changed: tokenizer recognises long comments / string using [=[ ]=] e.g. [==[ long string ]==]
Changed: Nested long comments and strings no longer allowed
Changed: x % 0 gives 0 (was x)
Optimised: software blitter now faster when using PocketCHIP, windowed raspi or blit_method 1
Fixed: infinite tokens exploit introduced in 0.2.5d (due to pre-processor changes)
Fixed: >>>= operator is a NOP (bug introduced in 0.2.5d)
Fixed: (raspi 32-bit) window not visible under Gameforce Chi / EmuELEC -- bug introduced in 0.2.5e
Fixed: s="x".."=" counts as 4 tokens instead of 5
Fixed: Running a cartridge containing meta data prints a memory allocation warning to stdout
Fixed: Code compressing to >= 32k reports size as (compressed_size & 0x7fff) resulting in corruped exports
Fixed: stat(54) loops when left-most channel is looping (should return total played ticks on current pattern)
Fixed: extcmd("audio_rec") maximum length is 2 minutes (meant to be 8 -- and now only applies to web)
Fixed: Frog Home crashes because of (now unsupported) "local x+=.." form. // INSTALL_GAMES for fixed version
Fixed: Starting P8SCII font height affects total line height even when no characters are printed in that font
UPDATE: Part II Thread https://www.lexaloffle.com/bbs/?tid=52692
A new year, a new fantasy machine! Picotron Playground is an experimental web version of Picotron's WIP runtime and API, bundled with a terminal and code editor in order to make some toy programs. You can read more about the goals of Picotron and its specifications in the FAQ:
https://www.lexaloffle.com/picotron.php?page=faq
Although I'm still mostly occupied with PICO-8 and Voxatron, I hope this will be a good way to chip away at the project and let future users try out the API in a low-stakes way before it is ready to go into production.
Launch Picotron Playground here:
https://www.lexaloffle.com/picotron.php?page=playground
Note: you'll need a US layout keyboard and there is no permanent storage, although the clipboard does work if you want to store some snippets. Please work on anything larger than toy programs at your own risk!
Running Demos
Demo programs will appear (and probably disappear!) over time to try out various API functionality. At the moment they are mostly simple graphics demos that can be loaded via the terminal:
/$ cd /demos /demos$ ls /demos$ load dots |
CTRL-R to run it.
ESC ESC to get back into the editor
CTRL-L clears the screen (important!)
The "reset" command can be used to get the default palette back.
Using the API
The most interesting feature of Picotron's runtime is probably the gfx pipeline, which is documented here: https://www.lexaloffle.com/dl/docs/picotron_gfx_pipeline.html
If you'd like a quick way to load sprites, try copying and pasting from PICO-8 gfx editor and pass that as a string to userdata():
my_sprite = userdata"[gfx ... /gfx]" spr(my_sprite, 100, 100) |
There are some more examples of how to manipulate userdata in the FAQ.
Limitations
- There's no audio yet.
- There is provisional cpu cycle counting, but it is incomplete and infinite loops will still crash your browser. You can get the cpu with stat(1), but it currently also includes cycles used by system processes.
- Some of PICO-8's more forgiving behaviors do not not exist [yet?], including being able to divide by zero, and automatically converting floats to ints.
- The code editor is still a bit janky. Sorry!
- btn() works but just for a placeholder P1 6-button layout.
I think that's enough to poke around for now. If you have any questions please post them in this thread or ask me on mastodon as there isn't a Picotron sub-forum yet. I hope you enjoy it!
Use the dpad to move head pieces around, join them to tiles (only some tiles join, and only on certain sides), and move your creation to the target area to complete each puzzle.
A wee game for Twelve Days of PICO-8 Christmas 2022. To get the full experience, play it from @TheTomster's menu cart!
Some scenes from other games in the collection:
Wooden Toy Joinery was a 3 day collaboration with my 9 year-old while visiting my folk's place in the south of New Zealand. Yesterday out of nowhere my Dad produced what looks to be one of the first BASIC programs I ever wrote (maybe.. 1985?). I didn't have access to a computer at the time, and this was before understanding what variables are. I suspect I was imitating a pick-a-path adventure code listing I'd seen, but applied to an action game.
|
39
|
Hey all! Time for some more bugfixes and esoteric features / QOL improvements to finish off 0.2.5*. And thanks to some snippets from @samhocevar's excellent z8lua, some cleaner code parsing. PICO-8 0.2.5d is now up on lexaloffle, Humble, itch.io, and for PocketCHIP and web (Education Edition).
0.2.5e
0.2.5e fixes a bug in the loader that causes uppercase characters to not be loaded as punyfont (e.g. breaking _ENV).
0.2.5d
Added: tline(bits) to set number of bits used for fractional part of mx,my,mdx,mdy (13 by default)
Added: ctrl+mousewheel to scroll code horizontally
Added: current bbs cartridge id shown in window title (config.txt show_cart_id_in_title to disable)
Added: poke(0x5f36, (@0x5f36)|0x80) to enable character wrap by default when printing
Added: blit_method in config.txt // Can use a software blitter by default (slower but more reliable)
Added: reminder when re-locating sprites that only the top half of map is altered by default
Added: draw boot sound as note glyphs on startup when sound is off
Changed: print() returns both max(cur_x), max(cur_y) and includes non-printed characters (e.g. tabs)
Changed: extcmd("folder") and extcmd("set_title", "foo") can now be used from bbs carts
Changed: Indexing a string out of range returns nil (was "")
Changed: Replaced most of pre-processor with Lua parser modifications based on z8lua (fixes various edge cases)
Changed: "a[foo()] += 1" only evaluates foo() once
Changed: out-of-bound tile values can be drawn using map(), tline()
Changed: extcmd("audio_rec") can record a maximum of 8 minutes (was no limit previously)
Changed: Rate limits are now per-minute: 10MB of log writes, 64 different files, 10 extcmd("folder")'s)
Fixed: Infinite tokens hack (was caused by now-replaced pre-processor)
Fixed: Only 4 controllers mapped to 0x5f00+76
Fixed: h toggles hexadecimal mode in gfx editor (should be ctrl-h -- h is to flip sprite horizontally)
Fixed: out-of-bounds value doesn't respect custom map size
Fixed: cutting or clearing a selection of sprites does not also clear the sprite flags
Fixed: P8SCII repeat-character command fails on zero repetions; ?"a*0bc" should print "ac", not "abc"
Fixed: pxa code compression inefficient when >= 32k matching triplets (typically "000")
Fixed: print() return value max(cur_x) returns 0 when max(cur_x < 0)
Fixed: holding menu button to force pause menu to open broken in binary exports
Fixed: copying / pasting in commandline doesn't respect punyfont character encoding
Fixed: (Manual) Steps 1 & 2 on how to move sprites in the map are in the wrong order
Fixed: Unhelpful / no error messages when the wrong format for HELP is used
EDIT: Note for Raspberry Pi Users
0.2.5d/e seem to have a serious issue with the blitter that causes PICO-8 to run, but with a hidden display (i.e. you can hear the boot sound, but not see anything). Unfortunately I won't be able to debug this for another couple of weeks as I'm out of my office -- but in the meantime you can get 0.2.5c from the downloads page under "older versions". Run it with pico8 -accept_future 1 if you want to load splore cartridges authored in 0.2.5d/e (and it will probably still work). Sorry about this!
Turn on your subwoofer!
This is a 512 byte intro I made for inercia 2022, a demoparty that took place in Lisbon over the weekend. It's the first time that I put the no longer secret 0x808 audio channel to use, with around 200 bytes of the (compressed) code spent on generating the music.
I was pleased to find that techniques used for golfing down visual effects' code size transfer quite well to audio. There are a lot of expressions in there that change meaning over time in a way that produces some kind of structured progression -- some planned, some not so planned. The whole thing is really a single effect, with a lot of janky math to roll out different audio and gfx layers at different times. I can't completely explain how it works in places, but feel free to ask about anything if you like!
This version has commented code in tab 0, but it is probably not a good example to get started with audio synthesis. For anyone game to try using 0x808, here is a simpler example that generates a sine wave at middle C (256Hz)
x=0
function _update()
-- write one more byte while there
-- is still space in the audio buffer
while(stat(108) < stat(109)) do
v = sin(x)*32 -- max vol:128
x += 256 / 5512 -- middle c
poke(0,mid(0,v+128,255))
serial(0x808,0,1)
end
end |
|
43
|
Hey All!
PICO-8 0.2.5 is now up on lexaloffle, Humble, itch.io, and for PocketCHIP and web (Education Edition).
Edit: 0.2.5b is now up for Linux users who had trouble connecting to the BBS: https://www.lexaloffle.com/bbs/?pid=116441#p
Built-in Help
PICO-8 0.2.5 has built-in documentation on API functions and other topics. Type "HELP" at the prompt to see a list of topics in blue, and then e.g. "HELP GFX" to get more information about that thing.
While in the code editor, you can also press CTRL-U to get help on whatever is under the cursor, including operators and Lua keywords.
> HELP FILLP |
String Indexing
Single characters can now be grabbed from strings using a familiar str[i] style syntax that means something similar to sub(str, i, i). The index is rounded down to the closest integer, and can be negative to index from the end of the string.
S="ABCDE" S[2.6] -- "B" S[-2] -- "D" S[99] -- "" |
Strings in Lua are immutable, so this can only be used in an expression (on the right hand side of an assignment). e.g. s[2] = "z" is not allowed.
rnd(str) is now also accepted and returns a random character from string str.
// update: this might not be true from 0.2.5c: https://www.lexaloffle.com/bbs/?pid=116415#p
I've reverted sub() to pre-0.2.4 behaviour, which means that sub("abcde",2,_) returns "bcde". 0.2.4 was returning single characters when the 3rd parameter is non-numeric, which is now much better handled by str[i] style indexing. (Apologies if you were already using this behaviour!)
Editor Features
gfx_grid_lines in config.txt now takes a colour if you'd like super-visible grid lines in the sprite editor:
Map selections are now on a separate floating layer:
Pressing cursor keys in the map when nothing is selected now moves the camera, as I noticed some new users struggling to find/understand the pan tool and instead instinctively reaching for the cursor keys.
PICO1K Tools
Some changes intended to be useful for PICO1K Jam starting in September:
-
ctrl-click on the compressed code capacity to get a realtime compressed size counter in bytes. This is the same size given with the INFO command, and when storing the cartridge as a tiny (code-only) binary rom with "EXPORT -T FOO.P8.ROM"
-
"EXPORT -T @CLIP" can be used to get a hexdump of that same data written to clipboard. This is not very useful -- just a way to visualise exactly how much data is stored.
- SAVE @URL saves 3 characters when there is no sprite data included by omitting the redundant "&g=".
Web-Exportable Audio
extcmd("audio_rec"), extcmd("audio_end") can be used in web exports. The output file shows up as a downloadable .wav file. I'm hoping this will open the door for some cute sound generation tools.
Variable Width P8SCII Fonts
PICO-8 0.2.5 custom fonts can now specify how wide each character is when printed. This previously handled by doing things like injecting extra P8SCII commands into the output string, but this was cumbersome and meant that such fonts could not be shared as plain data. There were already pixel-wise cursor positioning commands in P8SCII, so I felt it makes sense to make this simpler. Also, I needed it for Picotron 8)
To specify a 3-bit width adjustment and 1-bit y offset for character 16..255, the data at 0x5608..0x567f is used. These would otherwise be the bitmap data for characters 1..15 which are all control characters and thus never printed.
Each 4-bit nibble in 0x5608..0x567f (low nibbles first) encodes the adjustments for one character:
bits 0x7: adjust character width by 0,1,2,3,-4,-3,-2,-1 bit 0x8: when set, draw the character one pixel higher (useful for latin accents) |
An addition bit must be set at 0x5605 to enable size adjustments: poke(0x5605, 1). Otherwise the data at 0x5608..0x567f is ignored.
To test this out, try loading the font snippet generation tool:
> LOAD #FONT_SNIPPET |
And then paste the following after the comment starting with "font attributes"
POKE(0x5605,1) -- turn on adjustments POKE(0x5634,0x70) -- set nibble for i to 0x7 |
You can now observe that the big "i" in "quick" near the top of the screen only has 1px of space to the right instead of 2px.
Here's a helper function for setting the 4-bit nibble (val) for a given character (c):
FUNCTION ADJUST_CHAR(C, VAL) LOCAL ADDR = 0X5600 + ORD(C)\2 LOCAL SHFT = (ORD(C) & 1) * 4 LOCAL MASK = 0XF << SHFT POKE(ADDR, (PEEK(ADDR) & ~MASK) | (VAL << SHFT)) END |
File Listings (for Dev Tool Carts)
Locally running programs can now use ls(path) to get a listing of any local directory. Entries that end with a "/" are directories. Use stat(124) to get the current path.
PATH = STAT(124) -- E.G. /FOO/ FILES = LS(PATH) FOR F IN ALL(FILES) DO COLOR(F[-1] == "/" AND 14 OR 6) PRINT(F) END |
BBS cartridges are not able to access local file listings -- this is intended for developing tools to use locally. For example: a utility that makes it easier to browser cartridge data and copy between cartridges using reload() / cstore() which are able to read and write any local cartridge file using the 4th parameter.
Keyboard Scancode Remapper
If you're having trouble getting PICO-8 to detect some keys (especially numeric keypad keys / unusual laptop layouts), there is now a built-in tool for mapping those keypresses to something SDL2 understand. Run PICO-8 from commandline with -scancodes:
pico8 -scancodes
Or use some other tool to find out which scancodes the keys in question are producing, and then map them to something else in config.txt (look for map_scancodes)
Dynamic Libcurl Support (Linux)
The 32-bit and 64-bit linux builds now try to dynamically load libcurl by default in order to make bbs requests (e.g. download carts from splore). This will hopefully make installing on some platforms easier, including Steam Decks. When libcurl.so is not available, it drops down to the old wget behaviour (requires wget to be installed). If this works well, I'll also see about moving to the same scheme for raspi and mac builds.
More Doodlemud
Doodlemud is a toy multiplayer game designed to test the backend services that PICO-8's high score table (and future projects) will be based on. Try it here: https://www.doodlemud.com/#skatepark
This version is running on a completely new backend, custom written from scratch as a self-contained program using libwebsockets. My first attempt was built out of opensource components (nchan, redis, openresty, nginx), but because of PICO-8's unusual requirements, this was making customisation, debugging and devops more complex that it needed to be. Sometimes just reinventing the wheel with a bespoke C program is still the right approach even in the world of web services. There are currently 5 nodes running which are selected based on the user's location when making a new room:
Next Steps
It looks like PICO-8's 0.2.5 API is unlikely to change now (really, this time!), and the next task is to port the new additions to Voxatron for Voxatron 0.3.7. After that I'll continue working on the BBS functionality needed to log in from PICO-8 and submit high scores. If you're curious, you can see the current plan for the SCORESUB() function by typing HELP SCORESUB.
That's all for now -- I hope you enjoy the update and as usual let me know here or in bugs/ if you find anything spooky going on.
Full Changelog:
|
32
|
PICO-8 0.2.4c is now up on lexaloffle, Humble, itch.io, and for PocketCHIP.
This is mostly a bug-fixing update; you can see the main 0.2.4 change notes in the 0.2.4 thread.
URL Cartridges
With the release of PICO-8 Education Edition, it is now possible to encode cartridges into a 2040-character URL that runs it in a web version of PICO-8's editing tools. Only the code and graphics sections are stored.
> SAVE @URL COPIED URL TO CLIPBOARD 265 / 2040 CHARS |
Tiny Cartridges
When exporting cartridges to .p8.rom format (the raw 32k block of data that is encoded inside .p8.png argb data), 0.2.4c allows only the code section to be stored using the -t (for tiny) switch:
> EXPORT -T TINY.P8.ROM WRITING 154 BYTES (CODE ONLY) |
You should get a file that is exactly as large as the compressed code size reported by INFO. When using LOAD, that file will be loaded into the code section, and the other sections reset to their default states.
There isn't much practical use for tiny .P8.ROM files, but I think it is nice to be able to store a tiny program in its true tiny form on disk.
On the subject of tiny cartridges, for those making tweetcarts, you can now ctrl-click on the character count to get a twitter-character count which counts most (but not all!) glyphs as 2 characters.
Metadata
This is another technical one. 0.2.4c introduces a new metadata section to the .p8 file format suggested by @SquidLight that can be used by external tool authors. Sections with a heading of \n__meta:somestring__\n are preserved by PICO-8, but not (yet?) utilised by PICO-8 itself. So tool authors can add data to .p8 files by choosing their own meta:label without needing to stuff it into comments, or risk losing data the next time the file is saved by PICO-8 or another tool.
More details: https://www.lexaloffle.com/bbs/?tid=47063
Full Changelog
v0.2.4c
Added: save @url -- stores code + gfx as a URL if it can be encoded in 2040 characters
Added: html exports store volume/mute and other settings
Added: ctrl-g in sprite editor to toggle grid lines when zoomed in
Added: IMPORT -L FOO.PNG to import a 128x128 png to the cartridge label
Added: EXPORT -L FOO.PNG to export a 128x128 png of the cartridge label
Added: EXPORT -T FOO.P8.ROM to export only code section (t for tiny)
Added: ctrl-click on character count (bottom right) to see the twitter count (glyphs count as 2)
Added: __meta:*__ section to .p8 format -- can be used by external tools to store custom data
Added: extcmd("audio_rec") works from exported binaries, and with custom exported filenames
Added: read_controllers_in_background in config.txt (0 by default)
Changed: .p8.rom files that are 0x3d00 bytes or less are loaded into code section
Changed: saved filenames can not include gylphs, or any of !"#$%&'()*+,-:;<=>?[\]^`{|}~
Fixed: can't drag and drop png into sprite editor
Fixed: binary exports: ctrl-r causes crash when there is no whitespace at end of source code
Fixed: Using -run switch to launch a cart that fails to run -> get stuck in boot screen.
Fixed: selection after ctrl-a reports length chars+1
Fixed: draw palette is not observed after changing colours using p8scii control characters
Fixed: music playback does not follow cursor after first pattern change (regression in 0.2.4b)
Fixed: transform_screen (config.txt) not observed by pause menus and other overlayed elements
Fixed: Double-clicking sfx thumbnail (in sfx overview screen) only works after playing music
Fixed: Pressing [a] to release looping sfx in sfx editor is broken
Fixed: sfx(46)..sfx(56) return -1 immediately after playing music but before host OS has called audio mixer
Fixed: Tokens counted as 2 instead of 1: ..= ^= >><= <<>=
Fixed: Negative number counted as 2 tokens instead of one when preceeded by: \ & | ^^ << >> >>> >>< <<>
Fixed: tostr(tbl) / print(tbl) acts like tostr(tbl, 1) when tbl has a metatable
Fixed: ?"\tx" does not advance to next tab stop
Fixed: ?"a\*5\nb" does not repeat newline 5 times
Fixed: exported label alpha is 0 for colour 0 |
\o/
Say hi to the newest member of the PICO-8 family! A free, web-based, account-less version of the console making it a more accessible way to learn how to program, push pixels and write chip tunes. It comes with a fully functional set of cartridge editing tools, and can load and save .p8 and .p8.png files to and from your local drive (as well as storing them to a temporary filesystem in the browser's cache).
Just run it from any browser that has a keyboard + mouse attached:
If you are new to PICO-8 you can find a manual and tutorials on the main site, or click on the blue bunny for some tips. Here's a 2-minute GIF showing the creaton of a simple PICO-8 cartridge from scatch:
In addition to the standard 32k .p8.png cartridges, PICO-8 Education Edition also comes with a new cartridge format: the URL CARTRIDGE. GFX and CODE can be encoded as a URL string, as long as it fits within 2040 characters. Here's one I prepared earlier:
// EDIT: changed to a bit.ly url so that the BBS doesn't munge it!
To generate a url cartridge, use SAVE @URL and you should see the address bar change. I'm hoping this will make it easier to pass snippets around, and will add a new dimension to code size golfing and tweetcart'ing. And of course, it is still possible to capture screenshots (ctrl-6) and gifs (ctrl-8, ctrl-9).
Although exporters and SPLORE (the built-in cartridge browser) are not included, larger cartridges can also be shared either as .p8.png files or by first uploading to the BBS as usual (publicly listed or semi-private) and then giving students the cartridge id to load directly from their machine:
LOAD #MY_TUTORIAL_ID |
I hope you enjoy it, and I'll be back soon with some 0.2.4c binaries to match the web version!
-- zep
|
17
|
Hi All
PICO-8 0.2.4b is now up on lexaloffle, Humble, itch.io, and for PocketCHIP.
This is mostly a bug-fixing update; you can see the main 0.2.4 change notes in the 0.2.4 thread.
There are a few handy editor features though; here's a demo of setting animation loops: press l to start and end, and then -,+ or q,w or a,z (for azerty keyboards) to switch frames. This also works at different sprite selection sizes (shift-click and drag a selection from the spritesheet). This gif also shows using ctrl-b to "paste big" multiple times.
Full 0.2.4b changelog:
Added: l in sprite sheet navigator to set loop start / end points (then q,w or a,z to navigate)
Added: ctrl-b in gfx editor to paste 2x2 original size ("paste big")
Added: DEL / backspace to clear selected region in gfx / map editors, and ctrl-x to cut
Added: aggressive_backups option in config.txt (off by default)
Added: transform_screen in config.txt to globally rotate / flip the video output
Added: stat(57) (boolean) true when music triggered by music() is playing or about to start
Changed: memset() faster than using peek4/poke4; now 2 cycles per byte at 8MHz (was 4)
Changed: "running at < 30fps" warning on boot now only for raspi builds, and w/ higher tolerance
Changed: Controller inputs are accepted even when PICO-8 is not the foreground application
Changed: Map can be located at 0x1000 .. 0x2f00 using poke(0x5f56, 0x10) .. poke(0x5f56,0x2f)
Changed: Dotty text mode is now "\^=" ("Stripey") instead of "\^." // #gunayawuho #klax #impossible
Fixed: (not confirmed) crash causing 0-byte .p8 when audio mixer is called during save / run
Fixed: preprocessor not counting comments as white space; should allow: ".. end--[[]]if .."
Fixed: pal(nil) behaving the same way as pal(0); should be same as pal() // broke #rtype-2
Fixed: note entry in sfx tracker is silent after running cartridge until pressing space to playback
Fixed: sub("abc", 4, 4) returns "c" (regression in 0.2.4)
Fixed: SPLORE cart update prompt does not appear when server replies too quickly (race condition)
Fixed: SPLORE cart update prompt only checks version once per session (can't refresh until it shows up)
Fixed: EXPORT command does not flatten includes when exporting to .p8.png / .p8.rom format
Fixed: EXPORT command discards source code changes since last run or load
Fixed: printing a one-off glyph using "\^." terminates the whole string when last byte is a zero
Fixed: Crash when loading a cart with fewer tabs, then creating a new tab and pasting.
Fixed: . command runs at 30fps even for a 60fps cart (-> _update60 is called twice, _draw once)
Fixed: Custom menu items become broken after suspending a cart, entering a lua command, and then resuming
Fixed: memset() with a non-zero value in shared memory region (0x1000..0x1fff) causes garbage corresponding mget() values
Fixed: web player/exports: ctrl-r causes erroneous "external changes reloaded" message and code corruption
Happy Holidays, everyone! This cartridge is my addition to the 2021 PICO-8 Advent Calendar, which you should also check out if you haven't already!
Controls
- LEFT/RIGHT: Slow down or speed up. It is vital to get the right speed for some jumps
- O (Z/C): Jump. You can get more height by going fast and/or holding the button longer.
- X: To restart after crashing.
This game gets reasonably tricky; especially from level 3. But if you can reach the end, you'll get a simple ending along with your total time and number of restarts. The randomish elements in the game (you'll see what I mean) are actually deterministic, so it's possible to form strategies and optimise your time, if that's your cup of tea.
Anyway, I hope you enjoy it even if only as a crashing-into-trees simulator.
This cartridge was heavily inspired by Skyroads and @jackson_allen's most excellent Christmas Sweater Generator
|
50
|
PICO-8 0.2.4 is now up on lexaloffle, Humble, itch.io, and for PocketCHIP.
This update is another attempt at freezing the API before the last feature update (0.3 -- high scores), but let's see how it goes! 0.2.4 also includes an important security update (see below for details), so please do consider updating. Cartridges posted after this release post will only be visible from SPLORE when running 0.2.4 or later.
64k RAM
64K of Base RAM is now enabled by default. In 0.2.4 it is safe to PEEK/POKE/MEMCPY memory 0x8000 and above (i.e. -0x8000 .. -1) without setting the hardware extension bit at 0x5f36.
Because PICO-8's numbers only cover 0xFFFF, this means it is impossible to poke or memcpy out of range. The original motivation for having 32k by default was to give new programmers some concept of illegal memory operations, and as an extra form of feedback when code isn't working as expected. But over time, these reasons haven't proved as useful as the benefits of allowing 64k by default. Additionally, 0.2.4 introduces the first feature that explicitly uses the upper 32k section (see Big Maps).
Video Remapping
The video memory sections can now be mapped to each other, allowing the screen to be used as if it were the spritesheet, and/or to draw to the spritesheet as if it were the screen.
The mapped address for the spritesheet is stored at 0x5f54, and the mapped address for the screen is stored at 0x5f55. There are only 2 legal values that should be poked to each address: 0x00 (which means map to 0x0000), and 0x60 (map to 0x6000). This gives 4 combinations:
0x00, 0x60: default settings 0x60, 0x60: gfx functions (spr, circ..) use the screen as sprite data 0x00, 0x00: gfx functions all draw directly into the spritesheet 0x60, 0x00: swap spritesheet and screen |
Here's an example of re-colouring and zooming a section of the screen, pasted in at the end of jelpi.p8's _draw() function. This was possible in earlier versions, but required a lot of memcpy()'ing to backup, use and then restore contents of the spritesheet:
-- lighter colours; no transparency
pal({[0]=1,5,13,13, 9,13,7,7, 14,10,15,11, 6,6,15,15})
palt(0)
-- set the screen memory as the spritesheet
-- and stretch screen->screen
poke(0x5f54, 0x60)
sspr(48,80,32,32, 32,32,64,64)
poke(0x5f54, 0x00) pal() -- return to defaults |
Big Maps
Similar to gfx memory mapping, the map can now be placed at address 0x8000 and above (in increments of 0x100). This gives 4 times as much runtime space as the default map, and an additional POKE is provided to allow customisable map sizes.
Legal values are 0x20 (the default) and 0x80 and above. There are two pokes you need:
poke(0x5f56, 0x80) -- set the map to 0x80. Default is 0x20 poke(0x5f57, 0) -- set the width of the map (0 means 256). Defaults to 128 |
The height of the map is determined by how much data is available in the memory section. So in this case, there is is 32k available divided by 256, which gives a map height of 128 cels -> 256x128.
Note that the map editor still always writes and loads at 0x2000. This feature doesn't come with extra cartridge space to match! So to use 0x8000 and above, you'll need to manually mset() or memcpy() some map data. This feature will be most useful for carts that procedurally generate their maps or have some custom data storage scheme.
The map address is observed by all map functions: mget(), mset(), map(), tline()
One-off Characters
P8SCII character data can be specified and printed in-line using "\^." followed by 8 bytes of raw binary data, or "\^:" followed by 8 2-digit hexadecimal values. The data format is the same as custom fonts; each byte specifies a row of 1-bit pixel values, with the low bit on the left.
?"\^.$|へ|>○¹⁶" ?"\^:247cb67c3e7f0106" |
Audio Sync
STAT(46)..STAT(56) can be used instead of STAT(16)..STAT(26) to query the state of the sound system with more precision. Although there are many carts that managed fine with the old STAT() calls, it required a bit of fiddling and data smoothing to get right, derived from whatever state the mixer is in at the start of each frame (which only changes ~20 times a second, depending on the host platform and phase of the moon).
The new version (STAT 46..56) works by storing a history of sound mixer states at each tick, along with timestamps for sound driver mix requests, to estimate which state snapshot is currently audible at any moment in time. It's still not perfect, but requires less to work to get pretty good sync going.
Test cart: LOAD #AUDIO_SYNC_TEST
API Changes
Some small conveniences:
CHR() can now take multiple arguments to build a string:
> ?chr(104,101,108,108,111) hello |
SUB() can take nil or _ as the last argument to return a single character (instead of the rest of the string). This is useful when the second parameter (the index) is some long expression that you don't really want to repeat in the last parameter, or go to the trouble of assigning a temporary variable to.
PAL(N) can be used to reset one of the three palettes to their default state (0 draw palette, 1 display palette, 2 secondary palette).
> sub("hello", 3, _)
l
> sub("hello", 3)
llo |
Cartridge Formats
The .rom.p8 format (a raw 32k block of cart data) can now be used by CSTORE(), RELOAD() and in multicarts. This should make it easier to generate cartridge data using external tools without needing to jump through the hoops of writing to .p8 / .p8.png format.
On a related note, the EXPORT command can now also be used with any cartridge format. So, to convert between cartridge formats from commandline, the -export switch can be used (pico8 foo.p8.png -export foo2.p8.png). From inside PICO-8, it is also a handy way to save a copy of the current working cartridge without altering the current working filename:
> EXPORT COPY_TO_UPLOAD_TO_BBS.P8.PNG |
64-bit Raspberry Pi Builds
The file archive ending _raspi.zip now includes a build for the 64-bit version of Raspberry Pi OS called pico8_64. Exported binaries also have a matching file (e.g. mygame_64).
Security Patch
PICO-8 0.2.3 had quite a serious security flaw affecting Mac OS and Linux machines, that allow arbitrary commands to be injected into LOAD("#...") calls and executed on the host machine with the same privileges as PICO-8. PICO-8 0.2.4 fixes this in two places: the illegal cartridge ID is not allowed to be processed in the first place, and the URL used to fetch cartridges / listings is only allowed to contain a limited subset of characters. Earlier versions only had the second check, which was faulty.
As far as I can tell, there are no BBS cartridges that have used this exploit, and as a precaution SPLORE will no longer allow cartridges newer than this post to be listed to older versions of PICO-8.
So please do update to 0.2.4 to ensure you are not affected by this vulnerability, including for cartridges obtained from somewhere outside of SPLORE.
Server Test: Doodlemud
The last remaining part of PICO-8's api is SCORESUB() -- a simple api function for submitting highscores, but with some internal complexity. I've set up some new infrastructure for this to be reasonably future-proof and scalable, and a simple game for battle-testing it. You can try it here:
https://www.doodlemud.com/#p8024
Doodlemud is a multiplayer world-building / exploration game where each player can switch between drawing each room and being a player in it. This test requires a keyboard and mouse (no touch / tablet support); press cursors to move around, and G to toggle gravity for everyone in that room. Feel free to change the url to start new empty worlds (any alphanumeric name after the hash is ok), but keep in mind that it is experimental, and all of the data will be erased when it gets updated!
ASCII Manual
The .txt version of the manual is back! It is included in the archives, and you can find it on the Resources Page. The text and html versions of the manual are now both generated from the same source file, so should always be in sync.
Changelog
You can find the full changelog here:
(click to expand)
Heeey, it's Squiddy! This is a game made in 1017 bytes for PICO-1k Jam, co-designed and pixelled by @castpixel (twitter). This is our second production as pod; you can find the first one here. Squiddy is also up on itch.
Technical Details
1024 bytes is an interesting size limit for a game; it's large enough to try for some relatively detailed game logic or visuals, but small enough that you need to execute some weird programming tricks and design pivots to get everything to fit. If you found this post because you heard that PICO-8 is a nice introduction to game programming, I apologize for the following code snippets! First up, here is the full source code for the game that includes the graphics and map data. It can be pasted into PICO-8 0.2.3 or later:
➡️=0t=8⬇️=7for x=0,3800do
➡️-=1if(➡️<1)➡️=2r=3⬇️=7-⬇️ while r>2do r=ord("○ュ?\0゜ョヤャ◝◝⁷ツん¹ュ=◝に◝+ンョャヤ○る³ユ\n <◝エ𝘤ムもにュよ◝トラ⁙⁴よ░²リムリᵇ³ト■𝘨○ワ;◝エらョ0\0pクシチ◜◝=ュoれ/ウワ◝モャいユ𝘪ゆ?=0◝cりdオトは⁷ト?⁵\0𝘴リ◆○☉6サ¹6ア?ュ◝❎。。ユユ◝ャヤ2v\0q○¹\0ワw3v\0001よ¹\0◝?𝘰v⁴ャ゜⁴ら█pタp⁵ュ?オ; <○○ヨ◝oに◝𝘰ュ?1░ろヲア◝ᵇp○\0s³ヲュひ\0|れツ◝リツ𝘰゜6ト⁴ュ?p◜◝モpᶜオん▶○◜ャ\r○𝘣◝▶トリに1◝⁷ョ_ンん゜ョょ737⬇️○ョ¹ュのら◜-エs○ユト⁴らメ\0³•~◝エろヨ/゜3\0な?𝘯ュ◝よ▮ラヨsクろ?リトンミエセろ⁵ᵇムり3オ◝𝘮rユ⁷ワ>pンᶠ゜シてン>ナレ◝𝘰⁙ュuワ◝シ◝1゛ュ4チ◝?◝◝𝘰\0゜ᵇユ◝エ◝4◀0○ ◝◝◝◝◝\0ら𝘬\0",t\8)>>t%8&3t+=2➡️+=r end
sset(x%95,x\95,⬇️)end
o=128w=256f=0r=4128🐱=cos ➡️=0
❎=64🅾️=r*2s=spr::_::t+=.03camera(❎,🅾️)map()v=0for i=0,t/2do
x=i\32y=i%32v/=2v+=sget(r%o+x/4,r\o+y/4-🐱(i/870)/2)&4mset(x,y,v)p=i%4y=i\4*5%31
if(mget(x,y+1)==4)s(0,x*8+🐱(p/4-t),y*8-p*4)
if(r%5==2and i<o)s(i&2,-t*i%w,i*i%w+🐱(i/9+t)*3)➡️-=1>>12
end
if(r==4136)s(8,92,112,5,5)
s(20,o+🐱(t/2)*9,90+r+🐱(t)*5,1.5,2)b=btn()n=b&32f=f/2+n/20k=b%4\2-b%2if(f>n)➡️+=f*k ⬇️-=f f=0
❎+=➡️ 🅾️+=⬇️ ➡️=-➡️ ⬇️=-⬇️?"ᶜe\^wfin ♥",108,60+r
if(mget(❎/4,🅾️/4)<1)➡️*=-.95⬇️=.05-⬇️*.9
r+=(❎\o+🅾️\o*o)*8❎%=o 🅾️%=o
s(16+(f&2)+k%2*32,❎*2-8,🅾️*2-8,2,2,k<0)?"⁶1⁶c"
goto _ |
Sprite Storage
Here's the 95x40 spritesheet (hidden for spoilers).
The sprites and map data is stored in the long string passed to the ord() function. The challenge was to compress the data in a way that the decoder + compressed data would be smaller than the raw uncompressed sprite data. This is hard to do with a small amount of 1-bit graphics!
The format we settled on quite early is a variant of RLE (Runtime Length Encoding -- storing the lengths of spans of the same colour) with an interesting constraint: the smallest span length must be 2 pixels. This means that it is impossible to have a single-pixel vertical line, but thin horizontal lines are ok. It is also quite different from using double-width pixels, as spans can stop and start anywhere.
Each span length is stored as a sequence of 2-bit values. Each value is added to the span length, and the sequence is finished when the value is not 0b11 (3). This means that that 2-pixel spans take 2 bits to store (the worst case -- same as raw), 4-pixel spans also take 2 bits (the best case -- half the data needed), and for very long spans the data compresses to around 2/3 of the original size. The number of bits needs to store a span length jumps up every 3 values:
2 pixel span: 00 3 pixel span: 01 4 pixel span: 10 5 pixel span: 11 00 <- 2 more bits because the first value is 0b11 6 pixel span: 11 01 7 pixel span: 11 10 8 pixel span: 11 11 00 ... |
The code for the decoder is 106 characters after re-using some game state variables, and the sprite data compresses to 340 bytes, which becomes 358 characters with the required escape codes to store it in the source code (e.g. value 0 becomes "\0"). This gives a total of 464 characters -- around 50 less than using raw data + some code to transfer it to the sprite sheet. Worth it!
-- decode sprite data v=0 -- last read 2-bit value l=0 -- length of span i=8 -- input data position in bits c=7 -- current span colour for x=0,3800 do -- for each spritesheet pixel l-=1 -- one less pixel left to draw of the current span -- read the next span length (l) if ran out of pixels to write -- ord() grabs an 8-bit value from the data string if(l<1) l=2 r=3 c=7-c while r>2 do r=ord(data_string,i\8)>>i%8&3 i+=2 l+=r end pset(x%95,x\95,c) -- set a single pixel end |
Map Data
The map is generated from sprite pixels: each pixel in the spritesheet corresponds to a 4x4 block of map tiles. This allows for a 2x2 screen room to be described by an 8x8 pixel sprite. This produces a very blocky world however, so the sampling position in the spritesheet is also distorted by a sine wave that is chosen to line up between neighboring rooms, so that it is not possible to enter the next room and already be inside a wall. Here is an example of a room without and with distortion:
Apart from obscuring the coarse resolution of the source data, using this distortion had some other nice side-effects. It produces local organic details like a single protruding tile at the edge of some 4x4 clusters, and larger features like the raised 'platform' that the statue is sitting on. As the seaweed placement is based on both x and y position, having varying y positions for the ground blocks also means that the seaweed placement test could leverage that to look scattered without using an additional pseudo-random number expression.
It is also possible to reuse the structure of regular sprites (that are used as visible graphics) as map shapes. This only ended up happening once: the left side of the last tunnel is shared by the sprite data of the seahorse. But if you're really keen, you can also glitch through a wall to get out of bounds, and then freely explore the spritesheet.
Superloop
When making code-golfed games and tweetcarts, I normally end up having a single large loop that is used by anything that needs to be looped, to avoid the "FOR .. DO .. END" 16-character overhead. Unfortunately (or fortunately) I was unable to merge the sprite unpacking in this way, but the rest of the game uses a single superloop. The map data is fetched from the spritesheet, bubbles are drawn, and segments of seaweed are drawn at random top-of-ground locations, all using the same loop counter.
-- time starts around 2722, and t/2 is cheaper than writing a 4-digit number for i=0,t/2 do -- unpack map from the spritesheet in 4x4 map tiles -- Using v = (sget() + v)/2 gives tile values that differ -- based on their vertical neighbour so that viable seaweed -- locations can be identified (top is always 4) x=i\32y=i%32 v/=2 v+=sget(r%o+x/4,r\o+y/4-sin(i/870)/2)&4 mset(x,y,v) -- seaweed p=i%4 -- which segment of seaweed y=i\4*5%31 -- y position of seaweed to test (unevenly scattered) if(mget(x,y+1)==4)spr(0,x*8+sin(p/4-t),y*8-p*4) -- draw bubbes and apply water current to player -- only for 1/5 rooms, and for the first 128 iterations if(r%5==2and i<128)spr(i&2,-t*i%w,i*i%w+cos(i/9+t)*3)player_dx-=1>>12 end |
Janky Physics
The player uses a coordinate system (0..128 in each room) that is rigged so that the world position of the player is the same as the screen position after adjusting for camera position and scrolling. It also gives nice ranges of values that can be manipulated with expressions containing only small integer values.
-- control player -- accumulate force (f) while button X is held, and apply when released b=btn() n=b&32 -- buttons states f=f/2 + n/20 -- f approaches but does not exceed 3 k=b%4\2-b%2 -- -1,1 when LEFT or RIGHT is pressed if(f>n) then -- apply force and reset player_dx += f*k player_dy-=f f=0 end -- add velocity to the player's position player_x += player_dx player_y += player_dy -- invert the velocity before map collision test so that -- bouncing, friction and gravity can all be applied when -- there is /not/ a collision. works out slightly shorter player_dx = -player_dx player_dy = -player_dy if (mget(player_x / 4, player_y / 4) < 1) then -- no collision: invert the velocity to prevent bouncing, -- and apply friction and gravity in the same expression player_dx *= -.95 player_dy = .05-player_dy*.9 end |
Squiddy Racer
Because there is only a single loop used to generate the map and to do things every frame, it means that map data is generated every frame. This is what it looks like if the map distortion accidentally has a time component given to the sine wave:
|
38
|
PICO-8 0.2.3 is now up on lexaloffle, Humble, itch.io, and for PocketCHIP.
This update is focused on resolving runtime issues, with a couple of small but handy features thrown in for good measure:
Lucky Draw
To grab 32 random cartridges from the BBS, there is now a 'Lucky Draw' list in SPLORE. It is more likely to select cartridges that have more stars, but even unrated carts have a decent chance of appearing. Perhaps this will be a way to unearth some undiscovered gems, or just to find something new to play without scrolling back through several years of carts.
The list is cached, so it only changes every 2 minutes or so. But you can keep paging through the list to get new items forever.
Live Token / Character Count
Select some text in the code editor to view how many characters or tokens are contained within.
Shorthand Print Statements
The shorthand version of print (?"hello") used to require no preceding statement be on the same line, but you can now mix it with things like the shorthand IF statement, as long as it is the last thing on the line:
-- PLAY A SOUND EFFECT WHEN HIT IF (PGET(X,Y)>0) HIT=1 ?"\ADAF" |
Thanks to @Liquidream for suggesting this. It should be handy for things like tweetcarts and PICO-1K Jam (which coincidentally is also organized by Liquidream!)
New Manual
The PICO-8 Manual is still a work in progress, but it went through a large update last month, with new formatting, dark mode, linkable headers, and more printer-friendly. You can find it on the resources page:
https://www.lexaloffle.com/pico-8.php?page=resources
The changelog has been separated into a text file here:
https://www.lexaloffle.com/dl/docs/pico-8_changelog.txt
The pico-8.txt included in the distributables has changed to a short version that links to the online manual, but later on I'll bring back the full ascii version and keep it in sync with the html version.
.P8.ROM Format
This isn't a very useful feature unless you are manipulating PICO-8 cartridges with external tools, but it has always irked me that it is not possible to write 32k of PICO-8 cartridge to a file that is 32k!
> SAVE FOO32K.P8.ROM SAVED FOO32K.P8.ROM > LOAD FOO32K.P8.ROM LOADED FOO32K.P8.ROM (0 CHARS) |
Majestic.
Large Numbers
tostr() and tonum() now take format flags that make it easier to deal with large numbers.
https://www.lexaloffle.com/dl/docs/pico-8_manual.html#TOSTR
PICO-8's numbers are all 16:16 fixed point, which basically means that every number is internally stored as a large 32-bit integer that is divided by 65536 to get the value in Lua. So for example, if you want to use that large integer for something like scores that need to go above the usual maximum of 32767, bit 0x2 can be used to display it in the raw integer form:
?TOSTR(3, 0x2)
196608
?TONUM("196608", 0x2)
3 |
To add 10 points to a score stored in this way, you'd need to shift it right 16 bits:
SCORE += 10>>16 |
CPU Counting
0.2.3 contains two changed to cpu costs which does not effect many cartridges:
-
In 0.2.2c, it was cheaper to write "local a=0+b" than "local a=b" and also "local a=0-b" than "local a=-b". This is because the Lua vm instruction for addition was cheaper than local assignment (OP_MOVE), and for unary minus (OP_UNM). The best solution I could find was simply to reduce the cost of those two instructions to 1 cycle instead of 2, resulting in a slight speed increase in some cases.
- peeking or poking multiple values in 0.2.2c did not cost any additional cpu, so doing something like: poke4(0,peek4(0x1000,0x1000)) was completely free! The same line in 0.2.3 now costs the same as doing an equivalent memcpy.
Future Plans
Next up for PICO-8 is a 64-bit Raspberry Pi Build, and also a preview of a web version that is also handy for running PICO-8 on Chromebooks. I'm also still working on online scores, which required developing some bespoke infrastructure that is optimised for PICO-8's usage patterns, and can handle traffic from exported carts without needing to start charging for PICONET subscriptions or anything like that. I'll test it next month with the release of https://www.doodlemud.com, which is a multiplayer drawing game designed to battletest PICO-8's backend before exposing it to precious cartridge data!
Changelog
|
18
|
My entry for TweetTweetJam #6: a game in 2 tweets (at 558 characters)
Roll right without crashing for a high score (or left for a low score)
CTRL-R to restart
Hold X when landing to jump.
o=128x,y,u,v,h,p,s,d=o,0,0,0,0,32,sin,circfill::_:: ?"\^1\^c" for i=-o,384do j,l,b=x\1+i,h,btn()h,a=s(j/o)+s(j/93),p+i/4 line(a,0,a,h*2.1+p)h=p+h*5*max(s(j/3^7)) if(i==0and y>h)then if v>0then u+=v*(h-l)v*=-.7else v+=u*(h-l)end y=h if(b>9)v=-4 end for z=0,2,.2do pset(p+i/z,67+h/z,12+(h-l)*4)end end for i=-o+x&-p,x+o,p do a=-t()/(4+i^2%29)m,n=o+i+cos(a)*p-x,s(i/999)*80+s(a)*p d(m,n,8,7)end v+=.2u*=.7x+=u y+=v if pget(p,64+y)==7then::w::circ(p,64+y,v,v)v+=1 for i=24576,32767do poke(i,@i/1.2)end ?"\^1\^jef"..x\1 goto w end d(p,64+y,2,7)u-=b&1u+=b&2goto _ |
Dig to collect gems, and don't get squashed! A wee game made in a weekend for Ludum Dare #48. You can find the compo entry here: https://ldjam.com/events/ludum-dare/48/diggleoid
|
15
|
PICO-8 0.2.2b 0.2.2c is now up on lexaloffle, Humble, itch.io, and for PocketCHIP.
This is a bug-fixing patch for 0.2.2 -- see that thread for a summary of recent features.
0.2.2b does have a few small features though. You can now use a .lua.png extension with the EXPORT command to get the source code (all tabs) of your cartridge printed out to an image with roughly A4 dimensions. This is intended mostly for visualisation purposes, and lines are cropped to 188 pixels (47 characters) wide. The jelpi demo source code is bigger than I imagined!
EXPORT JELPI.LUA.PNG |
dots3d.p8 is much cuter
There are also some new extcmd() commands for setting screenshot output filenames, and the window title (intended for exported binaries).
I've also added a way to force the pause menu to come up, even if the cartridge is blocking it with poke() trickery. Simply hold the pause button for half a second, and the menu should come up no matter what (it's implemented at a low level). This might be useful when using SPLORE from a sofa, and a keyboard isn't available to terminate stubborn cartridges.
Full list of changes:
View Older Posts
