Log In  


So I've been chugging along with my pico8jam2 entry, and one thing that is nice is that there's a -run flag. But because I'm using an external editor and a build script, I need to reload the entire binary every time I make a change. The only thing that takes forever is the intro screen:

I know that it's part of the "fantasy console" but it'd be REALLY nice to have a -skipintro flag just for development, so that I can get my app running as quickly as possible for quick iteration.

3


Ctrl-R reload the cartridge (.p8) if modified (in another editor).


@jihem - thanks for the tip, but it's still not really optimal for me, as I re-build my p8 from the commandline. It'd be nice to just be able to kill pico8, and relaunch the application.


1

would be cool if you could send a signal to pico8 to reload the cart.


I've also wanted an option to skip the boot-up while developing a cart. Just wanted to throw it out there to show that there are more users who would appreciate an option like that.


I've tried to send keyboard messages to a running pico-8 process (in windows) to execute a reload (with CTRL+R) but for some reason it does not process special keys like ESC and CTRL ... only alphanumeric keys are working. Maybe you're more successful on your OS/environment.


While not the most convenient of solutions, I wrote a little patcher that'll skip the little boot splash, idea being that you have this version of pico-8 you use in what tool that you use -run in, and it'll jump straight to booting the cart a bit faster.

pico8-nosplash.exe

Please excuse the fact that the program looks like it's from 1991, I couldn't fix that >_>


@gamax - can you tell me what you're doing with the patcher? I would love to make a linux version.


Just replacing an instruction that loads the boot counter with 0xFFFFFFF1 to 0x28, which effectively skips the stuff before that, I.E the boot splash

it looks for "C7 05 E0 47 52 00 F1 FF FF FF" and puts in "C7 05 E0 47 52 00 28 00 00 00", you won't find that exact same line of bytes in the linux version, especially the x64 one, but perhaps looking for F1 FF FF FF will get you someplace.

Bytes for Linux x64 version are "C7 05 CD 5D 52 00 F1 FF FF FF" -> "C7 05 CD 5D 52 00 28 00 00 00" at offset 54E9.

Bytes for Linux x32 version are "C7 05 C0 20 31 08 F1 FF FF FF" -> "C7 05 C0 20 31 08 28 00 00 00" at offset 452E.

The highest you can put it is 0x32, any higher and it'll hang on boot. I chose 0x28 because it only skips the splash and maintains the start up text and logo, but 0x32 is slightly faster.

A thing I noticed is that in the Windows version this replacement will also effect reboot but in Linux a different instruction is used and thus reboot still maintains the boot splash. Keep in mind this is all 0.1.6 specific and can and will change in the next version, the pattern is simple though and should be super easy to update.


Very cool, thank you - I'll see if I can get a bindiff of some sort.


Thanks to mamax92 on IRC for helping me get bsdiff's working for the 32bit and 64bit versions of linux:

https://gist.github.com/josefnpat/68373e97b38aae3768361a1253a528e7


1

Since the proposed patches were only working for older versions of PICO-8 (I'm using 0.1.11g and will soon upgrade to 0.1.12), I spent a lot of time disassembling the binary myself to find a counter similar to the one gamax92 mentioned.

I finally found a patch for 0.1.11g and 0.1.12c. The binaries are likely to change in the future, so I will give different layers of explanations, from a sum-up for those who just need to get it work on specific versions, to a deeper explanation for those who need to understand or make it work on more versions.

  1. specific patches for the last two versions (Linux only)
  2. how to quickly find the new addresses to patch in future versions, assuming the code doesn't change too much
  3. a generic method described step-by-step to find the boot counter and alter it (can be applied to other variables as well)

DISCLAIMER: This is intended for development purpose. Don't try to strip PICO-8 information from your release cartridge!

Call to contribution: feel free to add the addresses to patch for Windows and OSX, or even patch files if you feel like it.

1. Patches for 0.1.11g and 0.1.12c (Linux 64-bit only)

PICO-8 0.1.11g (Linux 64-bit)

Replace [83 e8 0a] with [83 c0 37] at address 000099d8. Alternatively, trust me and apply the attached patch file below.

With bspatch

Download pico8_0.1.11g_linux_x64_skip_splashscreen_bs.patch from my gist.

sudo apt install bspatch
bspatch pico8 pico8_0.1.11g_skip_intro pico8_0.1.11g_linux_x64_skip_intro_bs.patch

With xdelta

Download pico8_0.1.11g_linux_x64_skip_intro_xdelta.patch from my gist.

sudo apt install xdelta
xdelta patch pico8 pico8_0.1.11g_linux_x64_skip_intro_xdelta.patch pico8_0.1.11g_skip_intro

PICO-8 0.1.12c (Linux 64-bit)

Replace [83 c0 04] with [83 c0 37] at address 0000aa40. Alternatively, trust me and apply the attached patch file below:

With bspatch

Download pico8_0.1.12c_linux_x64_skip_intro_bs.patch from my gist.

sudo apt install bspatch
bspatch pico8 pico8_0.1.12c_skip_intro pico8_0.1.12c_linux_x64_skip_intro_bs.patch

With xdelta

Download pico8_0.1.12c_linux_x64_skip_intro_xdelta.patch from my gist.

sudo apt install xdelta
xdelta patch pico8_0.1.12c_linux_x64_skip_intro_xdelta.patch pico8 pico8_0.1.12c_skip_intro

2. How to quickly find new addresses in future versions

If you are using a different OS or version of PICO-8, you'll need to find the addresses of the instructions handling the boot counter by yourself, then find a place to modify its value. We assume the function names haven't changed.

Note that on OSX, the app is packaged so you have to work on the binary inside the package (not tested).

If you still have access to gdb or some disassembly tool, check the move_boot function:

> gdb -batch -ex 'file pico8' -ex 'disassemble move_boot'`

At the beginning of the function, search for these kinds of instructions:

mov    0x95c99a(%rip),%eax        # 0xd673e0 <pstate>
add    $0x4,%eax
cmp    $0x1,%eax
je     0x40aace <move_boot+174>
(...more cmp, je, jne or even xor...)

The numerical values may have completely changed. In some versions, we sub instead of add.

This is where we are checking the counter that gets incremented every time move_boot is called. Read the numbers on the left of the instructions, and you'll get the addresses where you need to patch.

Install a hexadecimal editor and search for the corresponding lines (remove 0x400000 from the displayed address, e.g. 40aa49 -> 00aa49), then try to change the value added to %eax, e.g.

83 c0 04              add    $0x04,%eax
to
83 c0 37              add    $0x37,%eax

Part 3 explains why we choose 37, but since you're on a new version, the optimal value may be different; experiment!

If there is no add instruction at all, try to change the compared values instead. The counter is signed, so use a negative value if needed.

83 f8 01              cmp    $0x1,%eax
to
83 f8 e0              cmp    $0xffffffe0,%eax

But you may need to do that on many comparisons until you find the right one (probably one more below, comparing to higher value, will be the one you want; but you may need to change the others too to avoid some glitches).

3. How to make the patch yourself (step-by-step)

Note: I am very new to disassembly and patching, so I combined my basic knowledge of assembly, my own programming experience and some online help. I have found all the commands mentioned below just trying to solve the boot screen issue, so it should be accessible for you if you are comfortable with basic programming and binary editing, and you understand the concept of assembly.

Note 2: I only give commands for Linux (and OSX probably) with actual addresses and instruction bytes for PICO-8 Linux x64 0.1.11g and 0.1.12c, although you can apply the same principles to any OS as long as you have the adequate tools.

Note 3: I only used a few options in the command-line, so if you know better usages of those tools (or better tools!), please tell me. I'm in particular interested in debugging assembly in a visual editor (it seems gdb-mi can do this, but I have only used it with programs for which I had the actual source).

Steps

  1. Install disassembly tools and some hexadecimal editor (I use objdump and gdb for disassembly on Linux, and either Bless Hex Editor or the HexViewer plugin for Sublime Text for hexa editing; but you'll find many editors).

  2. Search occurrences of words you're interested in. In our case, we search for "boot" and "splash".

Ex:

> objdump -d pico8 | grep boot -C 10
(-C for number of lines to show around matching lines; use -A for lines after and -B for lines before)

00000000004061c0 <boot_init>:
( Address Bytes to hexa edit    Instruction and arguments)
  4061c0: 53                    push   %rbx
  4061c1: 31 c0                 xor    %eax,%eax
  ...

000000000040aa20 <move_boot>:
  40aa20: 41 55                 push   %r13
  40aa22: 41 54                 push   %r12
  ...

Result: we find the following related functions:

  • boot_init
  • move_boot
  • reboot_machine
  • boot_embedded_cart
  • init_editor_state
  1. Debug with gdb to break into those and see what is called

Ex:

> gdb pico8
> (gdb) break move_boot
Breakpoint 1 at 0x4099b0
(repeat for functions of interest)
> (gdb) run
Thread 1 "pico8" hit Breakpoint 1, 0x00000000004099b0 in move_boot ()
> (gdb) continue
Continuing.
(repeat)

Result: we repeatedly break into move_boot, and notice the splash screen appears frame by frame when continuing. So move_boot must be some update function to show the boot screen.

Hint: esxamining the callstack also helps understand function relationship:

(gdb) backtrace
#0  0x000000000040aa20 in move_boot ()
#1  0x000000000040ced7 in codo_main_update ()
#2  0x000000000047a8b7 in codo_main ()
#3  0x00007ffff6e35b97 in __libc_start_main (main=0x4049d0 <main>, argc=1, argv=0x7fffffffd5f8,
    init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffd5e8)
    at ../csu/libc-start.c:310
#4  0x0000000000404a0a in _start ()
  1. Disassemble move_boot and try to understand what it's doing via a mix of instruction reading and live debug.

Ex:

(when not runnign gdb)
> gdb -batch -ex 'file pico8' -ex 'disassemble move_boot'
(when running gdb)
> disassemble move_boot

[in PICO-8 0.1.11g]
Dump of assembler code for function move_boot:
   0x00000000004099b0 <+0>: push   %r14
   0x00000000004099b2 <+2>: push   %r13
   0x00000000004099b4 <+4>: push   %r12
   0x00000000004099b6 <+6>: push   %rbp
   0x00000000004099b7 <+7>: push   %rbx
   0x00000000004099b8 <+8>: sub    $0x410,%rsp
   0x00000000004099bf <+15>:  mov    %fs:0x28,%rax
   0x00000000004099c8 <+24>:  mov    %rax,0x408(%rsp)
   0x00000000004099d0 <+32>:  xor    %eax,%eax
   0x00000000004099d2 <+34>:  mov    0x870f48(%rip),%eax        # 0xc7a920 <pstate>
   0x00000000004099d8 <+40>:  sub    $0xa,%eax
   0x00000000004099db <+43>:  cmp    $0x1,%eax
   0x00000000004099de <+46>:  je     0x409ab8 <move_boot+264>
   ...

[in PICO-8 0.1.12c]
 Dump of assembler code for function move_boot:
 => 0x000000000040aa20 <+0>:  push   %r13
    0x000000000040aa22 <+2>:  push   %r12
    0x000000000040aa24 <+4>:  push   %rbp
    0x000000000040aa25 <+5>:  push   %rbx
    0x000000000040aa26 <+6>:  sub    $0x818,%rsp
    0x000000000040aa2d <+13>: mov    %fs:0x28,%rax
    0x000000000040aa36 <+22>: mov    %rax,0x808(%rsp)
    0x000000000040aa3e <+30>: xor    %eax,%eax
    0x000000000040aa40 <+32>: mov    0x95c99a(%rip),%eax        # 0xd673e0 <pstate>
    0x000000000040aa46 <+38>: add    $0x4,%eax
    0x000000000040aa49 <+41>: cmp    $0x1,%eax
    0x000000000040aa4c <+44>: je     0x40aace <move_boot+174>
    ...

disassemble is really convenient to read function-start-relative addresses (written <+X>) and see where jump commands lead inside the same function. However, it doesn't show binary, so you may want to use objdump when before starting the patching phase.

To visualize a function, I recommend:

objdump -dF pico8 | grep [address or function name]\> -A [enough lines to see the whole function content]
('\' to escape the '>')
  1. Looking at jumps and conditional jumps (jmpq, je, jne, etc.), you start identifying loops. You can verify this live by debugging with breakpoints at specific addresses to see which lines are executed when. I recommend breaking before/after jump points.

Also mind called functions with callq (in "<>"), their names can help you understand what kind of non-trivial operation takes place.

Ex:

0x0000000000409bd3 <+547>:  callq  0x46f1b0 <codo_clear_bitmap> (0.1.11g)

Trying to break on codo_clear_bitmap:

(gdb) break *0x409bd3
Breakpoint 1 at 0x409bd3
(gdb) run
Starting program: .../pico8
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff6e13700 (LWP 18791)]
[New Thread 0x7fffeee1f700 (LWP 18793)]
[New Thread 0x7ffff7fc5700 (LWP 18795)]
[New Thread 0x7fffecb35700 (LWP 18797)]

Thread 1 "pico8" hit Breakpoint 1, 0x0000000000409bd3 in move_boot ()
(gdb)
  1. When you spotted a few lines that do something visible on screen, I suggest you try disabling/modifying them to test your hypotheses.

For instance, you will see a call to codo_play_sfx, likely to play the boot jingle:

0x0000000000409be3 <+563>:  callq  0x4b0a30 <codo_play_sfx> (0.1.11g)
0x000000000040ac53 <+563>:  callq  0x4c5ce0 <codo_play_sfx> (0.1.12c)

Or with objdump, in hexadecimal:

409be3: e8 48 6e 0a 00        callq  4b0a30 <codo_play_sfx> (0.1.11g)
40ac53: e8 88 b0 0b 00        callq  4c5ce0 <codo_play_sfx> (0.1.12c)

Replace the whole instruction (including arguments) with nop (no operation) to disable it completely. In a hexadecimal editor, replace the 5 existing bytes with the nop code. On Intel x86 this is 90, which gives:

90 90 90 90 90

! Save as a copy of pico8, like pico8_no_boot_sfx. You wouldn't want to alter the original PICO-8 (not that you can't redownload it, mind you) !

If you disassemble the modified executable to check, you'll get something like:

0x0000000000409be3 <+563>:  nop
0x0000000000409be4 <+564>:  nop
0x0000000000409be5 <+565>:  nop
0x0000000000409be6 <+566>:  nop
0x0000000000409be7 <+567>:  nop

You can try the same with pico_print calls, to stop printing the PICO-8 version number and HELP instruction.

  1. Time to find the boot counter. We search some variable tested at the beginning of move_boot, before a jump:
> gdb -batch -ex 'file pico8' -ex 'disassemble move_boot'

[in PICO-8 0.1.11g]
...
0x00000000004099d2 <+34>: mov    0x870f48(%rip),%eax        # 0xc7a920 <pstate>
0x00000000004099d8 <+40>: sub    $0xa,%eax
0x00000000004099db <+43>: cmp    $0x1,%eax
0x00000000004099de <+46>: je     0x409ab8 <move_boot+264>
0x00000000004099e4 <+52>: cmp    $0x4,%eax
0x00000000004099e7 <+55>: je     0x409a63 <move_boot+179>
0x00000000004099e9 <+57>: xor    %r12d,%r12d
0x00000000004099ec <+60>: cmp    $0x7,%eax
0x00000000004099ef <+63>: jne    0x409b18 <move_boot+360>
...

[in PICO-8 0.1.12c]
...
0x000000000040aa40 <+32>: mov    0x95c99a(%rip),%eax        # 0xd673e0 <pstate>
0x000000000040aa46 <+38>: add    $0x4,%eax
0x000000000040aa49 <+41>: cmp    $0x1,%eax
0x000000000040aa4c <+44>: je     0x40aace <move_boot+174>
0x000000000040aa52 <+50>: cmp    $0x4,%eax
0x000000000040aa55 <+53>: je     0x40ab2d <move_boot+269>
0x000000000040aa5b <+59>: cmp    $0x7,%eax
0x000000000040aa5e <+62>: jne    0x40ab84 <move_boot+356>

or with bytes:

> objdump -dF pico8 | rg \<move_boot\> -A 22

[in PICO-8 0.1.11g]
...
4099d2: 8b 05 48 0f 87 00     mov    0x870f48(%rip),%eax        # c7a920 <pstate>
4099d8: 83 e8 0a              sub    $0xa,%eax
4099db: 83 f8 01              cmp    $0x1,%eax
4099de: 0f 84 d4 00 00 00     je     409ab8 <move_boot+0x108> (File Offset: 0x9ab8)
4099e4: 83 f8 04              cmp    $0x4,%eax
4099e7: 74 7a                 je     409a63 <move_boot+0xb3> (File Offset: 0x9a63)
4099e9: 45 31 e4              xor    %r12d,%r12d
4099ec: 83 f8 07              cmp    $0x7,%eax
4099ef: 0f 85 23 01 00 00     jne    409b18 <move_boot+0x168> (File Offset: 0x9b18)
...
(you'll also get a result with callq <move_boot>)

[in PICO-8 0.1.12c]
...
40aa40:  8b 05 9a c9 95 00     mov    0x95c99a(%rip),%eax        # d673e0 <pstate>
40aa46:  83 c0 04              add    $0x4,%eax
40aa49:  83 f8 01              cmp    $0x1,%eax
40aa4c:  0f 84 7c 00 00 00     je     40aace <move_boot+0xae>
40aa52:  83 f8 04              cmp    $0x4,%eax
40aa55:  0f 84 d2 00 00 00     je     40ab2d <move_boot+0x10d>
40aa5b:  83 f8 07              cmp    $0x7,%eax
40aa5e:  0f 85 20 01 00 00     jne    40ab84 <move_boot+0x164>
...
(you'll also get a result with callq <move_boot>)

We may have a switch-case, if-else or some while loop here. Maybe something like:

if (counter == 1)
{
  ...
}
else if (counter == 4)
{
  ...
}

but it doesn't really matter if you have debugged the lines and know where you want to be to skip the splashscreen.

There is also a branching depending on whether you're loading a cart or not (see load_working_cart). In practice, when loading a cart, you'll see a BOOTING CARTRIDGE... message instead of TYPE HELP FOR HELP). But we will focus on removing the delay for everything before.

For now, we can debug the variable mentioned near <pstate>:

[in PICO-8 0.1.12c, we want to watch 0xd673e0]
(gdb) display *0xd673e0
1: *0xd673e0 = 0
(gdb) break move_boot
Breakpoint 1 at 0x40aa20
(gdb) run
Starting program: .../pico8
...

Thread 1 "pico8" hit Breakpoint 1, 0x000000000040aa20 in move_boot ()
1: *0xd673e0 = -15
(gdb) continue
Continuing.

Thread 1 "pico8" hit Breakpoint 1, 0x000000000040aa20 in move_boot ()
1: *0xd673e0 = -14
(gdb) continue
Continuing.

It seems to be a counter indeed.

(Actually, I tripped a lot to find the right one; I even messed with the x/y pixel iteration counter used to draw the splash screen!)

  1. The idea is to skip some steps by advancing the counter enough, as gamax suggested. There are different ways to do this, here is a simple hack I found.

After the counter has been assigned to the %eax register, we are checking its value:

[in PICO-8 0.1.11g]
0x00000000004099d2 <+34>: mov    0x870f48(%rip),%eax        # 0xc7a920 <pstate>
0x00000000004099d8 <+40>: sub    $0xa,%eax
0x00000000004099db <+43>: cmp    $0x1,%eax

[in PICO-8 0.1.12c]
0x000000000040aa40 <+32>: mov    0x95c99a(%rip),%eax        # 0xd673e0 <pstate>
0x000000000040aa46 <+38>: add    $0x4,%eax
0x000000000040aa49 <+41>: cmp    $0x1,%eax

We can hack the variable just before the comparison, by increasing the final value.

In 0.1.11g, we can add some value to %eax instead of subtracting it, to gain the difference. In 0.1.12c, we still add, but a higher value.

Both versions will give the same result for the same added value.

  • add 0x16 or less: splash screen still appears (the higher the number, the more the beginning is cut)
  • add 0x17-0x2d: no splash screen (the higher the number, the smallest the delay on start, so prefer 0x2d)
  • add 0x2e-0x32: also no boot jingle, but version appears glitched
  • add 0x33-0x37: also no logo nor version (just copyright)
  • add 0x38 or more: the .p8 cartridge passed as argument is not loaded, so you cannot edit/run the game at all

So in principle, 0x37 is the value for the fastest start, but everything from 0x2e should be quite efficient.

Maybe it's also possible to skip the copyright, but it seems that it's just a simple print, and that what takes time are actually the following steps (either the HELP instruction or BOOTING CARTRIDGE). Skipping delay in this part will be left as an exercise for the reader ;)

  1. Open the pico8 binary in a hex editor, save a copy of it and search for the addresses of the instructions to modify, subtracted by 0x400000 (see https://reverseengineering.stackexchange.com/questions/16841/address-to-file-offset). If your editor doesn't support addresses starting at non-rounded values, you also have to round the last figure to 0.
[in PICO-8 0.1.11g]
We have:
4099d8:	83 c0 0a             	add    $0x0a,%eax

Without offset:
0099d8 / 0099d0 (rounded)
000099d0:  31 c0 8b 05 48 0f 87 00 [83 e8 0a] 83 f8 01 0f 84  :1...H...........

Replace the [] part:
000099d0:  31 c0 8b 05 48 0f 87 00 [83 c0 37] 83 f8 01 0f 84  :1...H.....7.....

We now get:
4099d8: 83 c0 37              add    $0x37,%eax

[in PICO-8 0.1.12c]
We have:
40aa46: 83 c0 04              add    $0x4,%eax

Without offset:
00aa46 / 00aa40 (rounded)
0000aa40:  8b 05 9a c9 95 00 [83 c0 04] 83 f8 01 0f 84 7c 00  :..............|.

Replace the [] part:
0000aa40:  8b 05 9a c9 95 00 [83 c0 37] 83 f8 01 0f 84 7c 00  :........7.....|.

We now get:
40aa46: 83 c0 37              add    $0x37,%eax

Save the copy. You can now generate your patch with any patch utility.


Not to sound like a wet blanket here. But guys, I =LIKE= the bootup sequence, and it only happens once per system reset.

Also if you're hoping just to bypass it for reasons of hide it, I think everyone will know your cart is PICO-8 from the telltale color set and minimal pixel resolution.

Now if there's a way to make a CUSTOM boot-up screen, say that includes not only ZEP's logo but additional information in a custom 128x128 screen ike for your .EXE cart and you must press a key to actually run your cart then, that could be useful.

Windows as you know you can change what the bootup screen looks like, so it might be something similar to this and worth pursuing.


For a custom bootup screen I would put it just after the usual boot screen, but I see your point since there is also some text like LOADING CARTRIDGE... in the middle that makes it not really like a proper splashscreen in modern PC/console games (on PS4 you could even see a custom image like the company logo immediately when launching the app, before even seeing the Middleware info and stuff; but that's just to give immediate feedback to the player before the game starts).

Skipping the boot screen is for development, I like it too when playing an actual cartridge but that wasn't what we criticized. It's only an iteration time issue (it's not a big deal before a long play; it becomes when you start testing a really small feature many times with many small changes).

But as you said it only happens once per system reset, so there is always the Ctrl+R reload trick mentioned earlier in this thread. I managed to make it work on OSX and Linux, but apparently some people had issues with Windows so skipping the intro may still be useful to them.

Now that's right, I forgot to also post my reload script which is the preferred solution is you can make it work on your OS:

reload.sh (Linux)

Works 95% of the time, may fail due to timing issues.
It's not smart enough to detect different cartridges being played though, so if you are testing different games or versions of the game, it will blindly reload the first pico8 window it finds, which may not be the build you want to test.

#!/bin/bash
# --sync makes sure the window is active before sending the key, but it gets stuck
# if no matching window is found, so timeout makes sure it doesn't happen
timeout 0.15 xdotool search --sync --class pico8 windowactivate key ctrl+r &&
echo "Reloaded pico8"

OSX: use a corresponding command-line tool, or if you're shortcut-savvy, try Better Touch Tool and map some shortcut to your build script + send Cmd+R to PICO-8 window.

Windows: same with AHK. I had inconsistent behaviours when using AHK with Unity, but it should be able to handle meta keys like Ctrl for simple actions.


Now that I've used Pico-8 for some time I think I need to clarify what I said, I like the bootup sequence WHEN I'm working on code.

If I'm compiling to an EXE or JS or something, I think it's intrusive.

Question, does your patch work when you compile to EXE/JS.

And is there a way to compile to EXE where it may fill the screen (leaving black on the edges) but still leave the Window buttons below visible and active ?

And is there a way to compile to EXE using a skin like THIS:
https://www.lexaloffle.com/bbs/?pid=68085#p


@dw817 In this case I'd recommend the new headless scripting mode:

export_cartridge.p8

pico-8 cartridge // http://www.pico-8.com
version 16
__lua__
-- Run this commandline script with:
-- $ pico8 -x export_cartridge.p8

-- It will export .bin and .p8.png for the current game release
-- Make sure to build your game and save it in your pico8/carts folder first (by copying it manually or by saving inside PICO-8).
-- Note that it will not warn if cartridge is not found.
-- Paths are relative to PICO-8 carts directory.

cd("picosonic")
load("game.p8")
-- png cartridge export is done via SAVE
-- the metadata label is used automatically
save("game.p8.png")
-- other exports are done via EXPORT, and can use an icon
-- example of export options (see documentation for more details):
-- instead of the .p8.png label
-- icon is a 16x16 square => -s 2 tiles wide
-- with top-left at sprite 2 => -i 2
-- on pink (color 14) background => -c 14
export("game.bin -i 2 -s 2 -c 14")
export("game.html -i 2 -s 2 -c 14")

Usage:
pico8 -x export_cartridge.p8



[Please log in to post a comment]