Harvard University's CS50 Games course has a free online version on edX. It's a great class for beginners with some coding experience, and uses Love2D and Lua. Nearly all of the concepts apply to PICO-8 development.
It's not too difficult to translate in-class code to PICO-8 equivalent code, but it might be easier to stick with Love2D for the course, then figure out PICO-8 equivalents later. In-class code uses Lua standard library features, all with PICO-8 equivalents. Spreading code across multiple files could be done with code tabs or "#include" instead of "require". They also use a simple third-party object-oriented class package to teach OO concepts. This could be ported to PICO-8 but hasn't been yet.
If there's interest, I'm sure we could pull together a set of support materials for bridging CS50 and PICO-8. For now I'm just recommending the course.
I'm noticing crackling or popping noises during music playback in the 0.2.0i web player, either on the BBS or standalone web. I cannot reproduce the noise for the same carts in PICO-8 native. For me this is noticeable and unpleasant, discovered in both the recent Pico Driller and Star Anise Chronicles.
Anyone else hearing this? I can try to record it if that helps.
Chrome 81.0.4044.138, macOS 10.15.4.
Please add volume controls.
This is actually two requests: volume controls for the PICO-8 native apps, and volume controls for the web player (exported and BBS). BBS games in particular are always at full volume, and I rely on web media players to give me a volume setting I can adjust on a per-player basis.
I'm seeing some new people picking up PICO-8 with the 0.2 release announcements (welcome!) and some discussion of the new visible tabs feature is giving the config.txt workflow some attention. People are tripping on the fact that PICO-8 overwrites config.txt on exit without testing for changes.
I'd like a smarter merge of in-memory and on-disk properties. The app should remember last loaded properties so it can calculate "dirty in memory" and "dirty on disk." DiM only? Update disk. DiD only? Update memory. Both DiM and DiD? Tricky, but maybe this is avoidable if PICO-8 always merges on every in-memory change.
I assume PICO-8 already has logic for preserving comments and resolving weird cases like a property appearing more than once, or not at all, in the file. :)
I like how I can indent/dedent a block selection with tab/shift-tab, and I like the behavior where it operates on every line with at least one character selected. I notice an edge case that should be addressed: if the first line is indented and I have the intend spaces selected, when I dedent the space goes away but my selection start moves up to the previous line. If I dedent further now the previous line is getting included in the dedent.
I like the new feature where shift-enter auto-indents. It also adds an "end" statement which is useful for closing blocks.
I'm wondering if it should always do this, or if it could do something more context sensitive. A full IDE would be running a full parser in the background which is probably overkill. A simpler behavior would just scan the current line for block starter keywords and only indent+end if it finds one.
I'd prefer this because I'm likely to get into the habit of shift+enter, enough to do it by accident, and if it always does what I want that'd be better than having to undo and try again.
Snowy has skates and wants to help his friend Bunny decorate his tree! Skate the lake to find five ornaments for the tree.
- Hold X and a direction to accelerate.
- Press Z ("O") while moving to jump.
Tip: Hold Z ("O") for longer before letting go to jump longer.
Tip: If you get stuck in water, try jumping your way out. Snowy isn't a strong swimmer, but he's a great jumper!
This is my and TimSwast's contribution to PICO-8 Advent 2019. Thanks to everyone who participated, and everyone who played!
I've thrown all my 32-bit games overboard and upgraded to macOS Catalina. I notice that the current PICO-8 binary (0.1.12c) asks for broad keyboard permissions (read keystrokes in all applications). I assume this permission isn't actually needed (I can deny it and everything seems to work) and this is a side effect of an older SDL macOS interaction. It'd be nice if the app can be configured to not ask for the permission.
If it is used for something I'd enjoy knowing what it is.
This is a bit obscure and possibly a limitation of SDL, but I notice as of 0.1.12c that if my default audio output device changes while PICO-8 is running, PICO-8 will continue to use whatever output device was the default when PICO-8 started for output, instead of switching to the new device.
For example, if I start PICO-8, then connect headphones, PICO-8 will continue to use the speakers. The rest of the system (at least for apps that don't have this issue) will use the headphones. To get PICO-8 to use the headphones in this case, I have to restart PICO-8.
The PICO-8 built-in editor supports up to 8 tabs. These are represented in the .p8 file as a single Lua code block delimited with -->8 comments. If I am editing the .p8 file with an external editor but still want to establish tabs for the internal editor, I add -->8 comments manually. If I add more tabs than the internal editor can handle (8 or more delimiters), code beyond the 8th tab is ignored.
It's a pretty edgy edge case to want both external editing and tabs for the internal editor, but I found this behavior surprising enough that I humbly request a tad more thought to it. I would agree that evaluating code that isn't displayed in the internal editor is not the right fix, nor is adding UI to support unlimited tabs. My preference would be to fail to load the file as if it didn't parse, with an explicit error message, or just consider everything beyond the 8th tab as part of the 8th tab.
The inline code syntax matcher is too greedy. A single instance runs past the closing backtick to the end of the paragraph:
One `two three` four five
One two three four five
Multiple instances in a paragraph help to illuminate what's happening: the styled span starts at the opening backtick but closes at the end of the paragraph, so multiple instances produces nested spans:
One `two` three `four` five
One two three four five
Chrome 76.0.3809.132, macOS 10.14.6. Cannot repro in Safari. Not sure when this started, but all of the web players on the BBS are blurry. Anyone else seeing this?
Web export from 0.1.12c still works fine, so I assume the BBS web player has an upgraded player with this regression.
Chrome 71 (December 2018) implements the new autoplay audio policy for the Web Audio API, which affects the Pico-8 web player. The BBS is OK because it implements a "curtain" that the user clicks on to start the player, which does the Web Audio enable interaction. But this breaks the exported web player as of Pico-8 0.1.11g: If I export a game to its own page then load the page, Pico-8 starts immediately and is disallowed sound. No interaction enables sound after this point.
One fix is for the exported web player to implement a curtain similar to the BBS. I don't know if that meets everyone's needs but would resolve the issue for the exported page. I assume we can work around this by implementing our own player curtain.
Interesting side note: This appears to affect stat() calls regarding sound as well. I have a cart that paused on stat(24) != 0, to wait for music to finish playing. The web export with sound disabled never gets past this point. I added a timeout for the pause to get around this, though I still don't have sound in this case.
I notice that the YouTube field of the BBS profile only accepts alphanumeric characters, and whatever is entered becomes a link of the form www.youtube.com/<alphanumericfield>. I'm mostly ignorant of how this part of YouTube works, but my understanding is that not everyone can reserve a youtube.com/<alphanumericfield> URL. You need a certain number of followers, have qualifying channel art, etc. Everyone gets a www.youtube.com/channel/<randomlyassignedalphanumeric> channel URL, but I can't enter that into my BBS profile and get a working link.
There's some history with G+ URLs that I've forgotten the details of. It looks like anyone can reserve a www.youtube.com/c/<alphanumericfield> URL. At least I have one, not sure how. But I can't enter that in either.
I think the YouTube profile field needs to accept more values and/or provide hints in the profile form on how to link a profile to a channel.
The BBS fails silently when I attempt to attach an image whose filename contains spaces. The upload appears to be successful, but it doesn't appear in the list of available images.
I remember this bug from the previous version of the BBS, so it's not new.
It appears that I have to sign in to the BBS on a daily basis. This does not appear to be intentional, and it's certainly annoying. I believe in the previous version of the BBS we had a one month sign-in expiration.
My cookies seem to be in reasonable shape for expiration dates:
PHPSESSID: when browsing session ends
pass: one month
user: one month
lexaloffle.com without the www also sets a cookie, __cfduid, but this doesn't seem related. I have tried clearing and recreating all of these cookies, with no change of behavior.
When playing a game in the web player, if I hold the z key ("o" button), I get the macOS diacritic editor. This interrupts play. I don't recall seeing this prior to the BBS/player update.
Santa Panic! A gift wrapping arcade game for 1 or 2 players, by dddaaannn and TimSwast. This is game 9 of the PICO-8 Advent calendar 2018.
Get those presents wrapped and in the right spots, and get yourself back up the chimney, before you're found out!
- Directional pad to move.
- "O" button to pick up, then "O" again while not moving to drop, or while moving to throw.
- Wrap a present by walking it to a wrapping station.
- Pick up your sack and walk into the chimney to leave.
Two player co-op available! You could use the help, but make sure both of you get to the chimney in time!
ClockworkPi is having a "Black Friday" sale on GameShells, only $119 (40% off) today only!
This is the new version of the GameShell with more memory and microHDMI out. It runs Pico-8 and is my favorite Pico-8-capable handheld to date.
I am not affiliated with ClockworkPi, I'm just passing along the info. Enjoy!
This is Pico-8 running on the Clockwork Pi GameShell, a new hackable handheld game machine. GameShell has an ARM architecture, runs Linux, and works with the Raspberry Pi version of Pico-8.
Featuring a "modular" design, GameShell comes as a easy-to-assemble kit. You need side cutters or a hobby knife to separate the plastic pieces from their sprues and clean up the ends. Beyond that, the parts go together without tools. There are five modules: the main board, the screen, the battery, the keypad, and the speakers. Each module is enclosed in a plastic case with an easy-to-open lid. The modules are connected with little cables, and they all fit snugly in a Gameboy-sized case. There's a headphone jack and a microUSB port for charging, as well as on-board Wifi. The keypad includes D-pad, ABXY buttons, select, start, menu, and shift. You can also get a separate expansion module for shoulder buttons on the back.
I posted some unboxing photos to Twitter: https://twitter.com/dan_sanderson/status/1022265067142696961
The build quality is excellent, and the kit is designed to be foolproof. Unlike the RaspiBoy, everything fits together easily, with no fiddly bits to get wrong. Everything is injection molded and has a comfortable, traditional Gameboy feel in a thinner lighter form factor. Game play with the membrane-style buttons is fast and fluid. The 320x240 color screen is sharp, and while a little small for games expecting a desktop display, GBA and Pico-8 games are just the right size.
The microSD card comes preloaded with a Debian Linux derivative, known as "clockwork OS." It's just Debian with kernel patches applied for the hardware. The OS boots to a simple Launcher interface that you can use from the gamepad. The Launcher has big icons, and it's easy to add more simply by adding new files in certain places. All OS customizations are open source and on Github, and the Launcher is just a Python app based on Pygame that runs in user space.
GameShell also comes with RetroArch preinstalled, along with full versions of Cave Story and freeDM (a Doom clone) to get started. These aren't actually the best examples because they expect a bigger screen, but they'll get you playing right away. Though it's a little under-documented for beginners (and the user community is starting to fill the gaps), it's easy enough to copy over MAME, GBA, and NES ROMs, install new RetroArch cores, and even load up music files for the built-in music player.
The wifi reception is surprisingly weak. I have to be a few feet from the wireless router to stay connected, and character throughput over an ssh connection is too laggy for anything more than simple administrative commands or light edits. (I recommend a clever network-aware text editor running on another computer, such as Emacs Tramp, for extensive on-device file editing.) You can replace the kernel to get ethernet over USB, and you can disable wifi power-save mode to get better wifi throughput. I haven't tried these yet, nor have I tried connecting a keyboard to the microUSB port (not sure if that'd even work).
Setting up Pico-8
Update, June 2019: ClockworkPi has recently added a built-in PICO-8 installer for the GameShell! A while ago, I wrote a tutorial for adding it manually. They have since automated the tutorial and made it a default menu option! See the updated tutorial for the new installation procedure:
The best so far
Like many, I've wanted a hackable homebrew game machine for so long that I've backed pretty much every Kickstarter on the subject, and have built a few of my own with 3D printed cases and soldering kits. RaspiBoy came really close to the ideal feature set with injection molded plastic, membrane buttons, and a stock RaspPi with all ports exposed, but fell down on a few design details in the keypad. I'm looking forward to 8b Craft's RetroStone, with a larger screen, HDMI out, all the USB and ethernet ports, and full pre-assembly. Shipping soon.
Until then, the Clockwork Pi GameShell holds the crown as the best hackable handheld. I could play on this hardware for days, everything is well designed for ease of use, and underneath it's a very familiar Linux/X11 set-up. You could probably do the whole RetroPie/EmulationStation thing here, but the simple Launcher with RetroArch is so much cleaner, and feels just right on the hardware. Cave Story is already on there, and it took me mere minutes to find some GBA ROMs and start playing. While the screen is a little small for on-device hacking without a second computer, I'm tempted to wish for an upgraded mainboard with Bluetooth keyboard/mouse capability, and maybe a little kickstand.
As an aside, it's also one of the better "modular" designs I've seen. I've been skeptical about modular educational kits for a while, mostly because I was dissatisfied with choices other kits make in where to apply abstraction and proprietary interfaces. Clockwork Pi is just getting started so there's not a lot else you can do with these modules yet, but I can already tell they're making smart simple design choices for the module interfaces and hardware designs. I'm looking forward to seeing where this goes.
View Older Posts