I noticed that load() supports filenames without extensions and will pick filebasename.p8 if it exists, else filebasename.p8.png (I didn't exactly try the priority order, as there is only either a .p8 or .p8.png in my distributed game folder).
However, reload() won't work with a file basename. It needs the .p8 or .p8.png extension. When distributing a game both for p8 and png though, you don't know in advance what you'll need, and would need to create two versions of the code, one reloading files in .p8, the other reloading files in .p8.png, for both versions to work. I actually wrote a string replacement script to support them both!
It would be nice if reload() supported file basename like load() for this reason. I don't know if this is a bug report or a suggestion, but I would expect reload() to be consistent with load() so I opened this thread in the bug section nevertheless.
> The intent is that P8 is for development, PNG for release, so this situation should not happen.
Hm, that would make sense for a single release. But as many game projects, I do a release, then go back to development, add patches, and release again. So either I must rely on my p8 -> p8.png string replacer, or I must add ".png" manually but then revert it when I go back to development.
Also I'm not sure if ".p8.png" works in binary exports made from .p8 files... (and you may realistically want to export native binaries for everybody + PNG cartridges for PICO-8 owners)
> either I must rely on my p8 -> p8.png string replacer, or I must add ".png" manually but then revert it
Sorry I don’t know what the string replacer is.
What I do (and many others?) is to keep both P8 and PNG. I edit the P8 for development, also have it in version control, and save as PNG to release. I don’t edit and save the PNG directly, I treat it as a compiled artifact, not source code.
The issue is with the reload() function specifically. I'll give an example:
-- copy spritesheet reload(0x0, 0x0, 0x2000, "spritesheet_data.p8")
This will work when running a multi-cartridge game with your_game.p8 and spritesheet_data.p8 in your pico-8/carts folder, and when exporting a binary from those two carts.
However, this will not work when saving all your cartridges as .p8.png in order to distribute them as a multi-cartridge project, while benefiting from the compressed size of png carts (and also the png label itself, although that mostly matters for the main/entry cartridge).
It size is not an issue, you may want to keep the additional/data cartridges as .p8 (also, so they don't appear in your png cartridges list while they are not something you'd want to load as a game).
But if you want to distribute all your cartridges as .p8.png (besides the other formats, such as .p8 and binary) then you need to edit your code specifically for the png distribution:
-- copy spritesheet reload(0x0, 0x0, 0x2000, "spritesheet_data.p8.png")
My "string replacer" just does that: it finds occurrences of '.p8"' and replace them with '.p8.png"'.
Fortunately I got a "pipeline" to help me modify stuff in my code before exporting, but other developers doing things manually may want something more simple when they want to export in various formats for distribution.
Ah! For multi-cart, I think the common thing is to distribute binary executable only (exported with the right params to include the p8 files). Jack of Spades is one game that also publishes native carts; the main cart is PNG and the data carts are P8, which seems fine (sizes are still very small compared to other kinds of games).
For what it's worth I agree with the original suggestion: reload() should support a filename that's just a basename, similar to the load command. For consistency, it should match load: reload(0x0, 0x0, 0x2000, "spritesheet_data") should search for spritesheet_data.p8 then spritesheet_data.p8.png.
I briefly considered whether it should match the suffix of the currently loaded cart, but it's already going to be confusing that it's going to pick one over the other if both exist, so it's probably best to always do the same thing. Multicart dev workflows probably need some light scripting anyway (e.g. always keep your sources as .p8, and script the export to .p8.png), but the lighter the better.
@merwok Ah, right, I 'load' code cartridges which doesn't have the issue. I think there was a special case where I had to reload from a code cartridge because I was interested in the memory inside it (not all data is in separate data cartridge because the export limit is 16 cartridges, so by putting some data in code cartridges I can reduce the number of cartridges), but otherwise I just reload from data cartridge, where I can decide to keep them all either as .p8 or .p8.png (but currently I'm doing either all p8 or all png).
@freds72 I was worried about having to stick to .p8 cartridges even for code and therefore having bigger files even in my so-called "png distribution". Not that it makes a big difference in our modern world and with people downloading the files directly from itch.io, not from BBS on a machine with a slow connection... But for principle I wanted the distributed zip file to match the format (p8 or png) to match user expectations.
@dddaaannn Thanks for the insight, it's not a big deal for me right now but it could help other devs to get this automated in the future.
[Please log in to post a comment]