Log In  


It's great that binary exports are finally there!

however they are not yet ready for distribution:

  • config.txt & sdl_controllers.txt should be fetched locally **almost done!
    so you can pack your default options with your game (like start fullscreen) and an up-to-date sdl controller file. right now they're using the pico8-devkit home dir.

  • function keys should be disabled
    F5 & F7 especially **done!
    F1 should open either the pause menu or a separate help screen
    F11 should toggle fullscreen
    maybe keep png/gif capture keys

  • still no dpad support :(

further suggestions:

  • a help screen, either customizable (maybe call _help() instead of _draw()) or showing input options.
  • sound options (volumes) and (a revamped) keyconfig in pause menu
  • menuitem(1,"check my site","www.mysite.com")
  • mouse lock, useful for first person shooters (or anything else than point&click actually)
  • time(), day(), month(), year() (you could set daily challenges for instance or something special for halloween,xmas etc) **done!
  • background png around the pico screen (centered, tiled etc) and/or transparent overlay on the pico screen for bells & whistles

(full disclosure: pointerlock & date would allow my html-only pico8 game (pits of d'oh) to go binary)

...
**done!:
also the icon only shows up on macos. on windows it's the pico8 icon, on linux mint the default exe icon.
note on macos color 0 is transparent when the icon is grabbed from the spritesheet. that was a nice touch in my case, but not so much if you want black in there. might need a "-c" option on export?

7


In my opinion a pico-8 binary export should be considered a standalone product. I have no use for it myself, I just want to give it to people who don't know or don't care about pico-8. we're getting there, there's just a few biggies left:

  • config.txt
    "Changed: If config.txt is not found, the same directory as the executable is searched"
    which means the devkit and EVERY pico-8 binary still share the same config.txt. worse, the binaries also overwrite that config.txt. so the first binary to run on your system will write settings in stone (especially inputs), and older binaries will boldly remove/reset the newer options they know nothing about. (the binaries you're making now will do that to your future devkit versions). each binary needs its own "roaming" config.txt, with the one in the exe directory taking precedence if it's more recent (was modified in a portable way).

  • keys
    special keys should be in config.txt. I'd put the pause menu on F1, capture keys on F5-F7 (or boldly disable them), fullscreen on F11. right now a player pressing F1 for help gets a screenshot on his desktop. and more and more as he tries F2 to F12.
    note: you can set the menu on F1 with keyconfig, but then you get both the menu AND a screenshot!
    also the input scancodes in config.txt are not enough, each button needs its own entry with a list of (readable) values. I'd use it to put alternative one-player keys all over the keyboard. plus the player could edit the config file to his liking (until a proper keyconfig)

  • dpad
    come on, it's just a matter of polling SDL_CONTROLLER_BUTTON_DPAD_UP/DOWN/LEFT/RIGHT!
    shoulder buttons would be extremely handy too, while you're at it. and that would be it!
    (or maybe you could also add support for controller hot-plugging, SDL2 can do that)

It's all I can think of for now. That's not a lot, and then we can distribute binaries without fear :)

feedback: All the pixels are too big!
me: THAT'S BY DESIGN! Each of them is carefully crafted, just let their beauty invade your soul!
feedback:Your game is unplayable with my fancy xbone controller left stick! why can't I use the D-PAD!??
me: er...well...um... LOOK! OVER THERE! A DIVERSION! *runs to the exit*


A binary export is basically this:

  • a pico-8 exe stripped of the devkit (and other options), with a customized icon
  • the cart (data.pod)

some observations:

1) you can swap the data.pod files around, it's just a full cart.
in yet another format though? it's huge! an empy cart is 53kb as p8, 3kb as png, 828kb as pod!

2) you can launch the exe with command line options.

2.1) -splore works!
export an empty cart, launch it with -splore and there you have it, a Standalone Pico-8 Splorer!
(note that the blank data.pod needs to stay there)

2.2) -run mycart doesn't work.
bummer.

2.3) -p str works.
export this:

str=stat(6)=="" and "none specified." or stat(6)
print(str)flip()
load(str)

run with -p mycart.p8.png ... there it is, a Standalone Pico-8 Player!
no doubt You can use it with various emulator front-ends.

That's great, but I guess it's an overlook? can these be used/distributed freely now that it's there?

edit:
load() is gone for external carts: (from v0.1.11e changlog) "Fixed: Exported binaries can load carts outside of bundle"
-splore is gone too.


I agree that the Pico-8 binary exporter does need a bit of work, but I am sure that zep is working on making it more robust. At the moment, I would me more comfortable distributing my carts as HTML/JS in an Electron wrapper, plus I can use the "GPIO" as a rudimentary way for a leaderboard system/networking, which I would also like to see integrated into Pico-8, but with more restriction, like a 56K modem.


@chand1012: yeah the html5 version is really flexible. I tried electron/nodejs.. ended up with tens of files up to 280Mb. I find it quite obnoxious. now on android you can make a 2Mb webview app, that's a huge step from phonegap. too bad there's still nothing like that on desktop...


  • D-Pad! Yay! \o/ (but still dreaming of shoulder buttons and hot-plugging)
  • load() is restricted (see above)

That's it. I don't see anything else in the changelog regarding binaries.
(I didn't bother testing things again though)


@ultrabrite, you could check out this little gem over here:

https://github.com/pojala/electrino



[Please log in to post a comment]