Yep saving I get, but I don't understand how I load my map. Surely there must be a way to load a map you have already saved?

I guess I'm not quite understanding. Are you asking how to load a map into the PicoMap editor, or how to load it into Pico-8's built-in map editor?

Sorry. Yes I would like to be able to load a map into the PicoMap editor to make more changes and things.

Hmm, I thought that part was pretty straightforward, but maybe I skipped explaining something.

So, when you've made a map, you need to exit by pressing esc, then go to the data strings tab and press ctrl+v to paste the contents of the clipboard there. You need to be sure and paste over the existing strings, otherwise it could read the wrong ones, and be sure to save the cart after doing this. You can actually save, load, and edit many levels, since the level strings are stored in a table, and this whole table is output to the clipboard.

I'm not seeing it. This is what I have, but you'll see that the strings aren't similar and if I just paste them at the bottom nothing seems to be happening.

Okay, I know what's happening.

Looks like you're using the export feature to output the level maps, but that's only supposed to be used later, to send the levels to the cart where they'll actually be used. The strings containing level data are constantly being output by the program as you edit your levels, so all you need to do is press escape, and paste the contents of the clipboard over the existing strings.

I did things this way because it lets you freely edit the spritesheet and semi-compressed level data in the editor before further compressing them in the final cartridge so much more can fit. I tried to explain everything, along with illustrations, in the system description and tutorial, as it's a bit complex and data has to be stored in an unconventional way to fit so much in a cart.

Ohhh I thought the copied text and the export was the same thing. I'm a bit dense. Thanks!

I understand the confusion, I had to break things up to make the fullest use of space. In the final cart, the spritesheet is used for raw binary level data, since that gives a full 12KB of contiguous possible level space, and the data's pretty much incompressible. Your sprites will be compressed into a string, since that does compress okay.

In the next update, I'm planning to incorporate a version of zep's PX9 compression system as an option, as that should allow storing a whole 2nd spritesheet in map memory if you don't need all 12KB for levels, which most projects probably shouldn't. Haven't quite settled on a standard solution for spritesheet switching, though.

The Most Impressive Tool Made to Date

This is now the number one most impressive and useful tool ever created for Pico-8, while keeping the aesthetics of Pico-8.

I am more impressed by this work than I am by PicoCAD or Memsplore, which are both outstanding in their own right, but as far as I'm concerned, you're in a league of your own. Mainly because this tool will have SIGNIFICANT impacts on what users can or are willing to make.

Having been writing a book on PICO-8 for the past 2 years now, thinking I had seen most everything, this has come along and made me reconsider just how complete the book is....

Thank you so much for your contribution to the community and also for the documentation. If all software did it like you have, there's no telling how many more people would be drawn into their untapped abilities. Seriously, as the runner of the unofficial api docs , I feel like there will be some massive changes made to the presentation of it all, having seen what you did here.

@iiviiGames,

Thank you for your kind words,

I think the biggest thing this program does is show that Pico-8 is more capable than people would expect, basically by using a new spin on old compression techniques that people don't bother with anymore due to plentiful storage and memory.

To be fair, I'm not the first or only person to work at expanding the system's capabilities by going beyond the standard map system, for example:

• @paranoidcactus has used a custom metatile-like map system for multiple action-platformer games

• @2Tie appeared to be using a custom metatile system in PICOROID, their WIP Metroid demake

• @Saffith developed a metatile-type system heavily based on autotiling and used it in their game Barp the Balldragon, and even released an editor for the game that gave me some design ideas (though I barely understood the code when I tried reading a few bits of it).

• @pancelor made the Bigmap Editor, which takes advantage of Pico-8's new HiMem features and, when combined with zep's PX9 compression, allows a few times more map space than previously available.

My goal with PicoMap was to not only prove that Pico-8 was more capable than people thought, but to make exploiting that capability relatively easy, so people could make, say, an expansive platformer without doubling their effort by having to start from scratch in making an expanded map system. I think for a moderate expansion in map size the bigmap editor will probably be more intuitive to use, but if somebody wants to make a game with a big 'ol world to run around in, It should make things a lot easier for them than they otherwise would have been. I've also learned a lot in making it, so that's cool too.

PICOROID just replicated the room and metatile system from famicom metroid, with some minor improvements. I had also written about metatiles (using Pokemon Green as an example) in one of the pico zines a year or two back; actually, i wonder if that one ever got published?

But yeah, pico-8's been very capable of this sort of thing for a while, but this tool definitely makes more things accessible. I'm suprised people are still noticing picoroid all this time later! (i did manage to fit the whole game map into memory back then, but ran out of tokens to implement enemy logic)

@2Tie,

Yeah, some time after getting the idea for what would become PicoMap I looked through the forum to see if similar things had been done, and came across Picoroid. That's pretty cool that you managed to implement a similar tile setup to the NES, even using monochrome tiles with definable color attributes. Just curious, do you have any idea around how many tokens your metatile system was using?

Also, I would be very interested in checking out your article on metatiles, if you still have that around somewhere. ;)

Hey @JadeLombax, I'm trying to export a small map just to take the editor for a test drive and figure things out, but whenever I try to export Picomap crashes with this...

I made sure to change the export cart in the user settings, and placed a matching file in the Pico 8 folder. Am I doing something wrong?

@Turbochop,

I don't know that I've come across that exact glitch before, so it's hard to say. If you could post the cart you're trying to export from to the thread, though, I could try and pinpoint the issue.

Hello, I can reproduce in 0.2.5e this error by just loading up #picotron and then exporting.

Hmm, okay. I'll check this out after work today, see if I can figure out what's up.

A small update : I took some time to binary search the last version that worked on 0.2.5e and turns out the first version of Picomap that boots is the ninth (so the update that moved the do..end out of a single-line if) and from this one to the most recent version, all versions fail on export.

EDIT : I'm trying to pry the cart open to see what happened too. It looks like it breaks on trying to extract a number from an empty string (looks like it's caused by not having objects in the cart, according to tab 2?). Still digging.

EDIT 3 : Looks like

 local start_screen
 if #c > 0 then
    start_screen = val(c,1,3)\16
 else
    start_screen = 0
 end

instead of just local start_screen = val(c,1,3)\16 (tab 2 line 42) allows the export to visibly do something. I don't know if it works though.

I was wondering if it was something like that, but I didn't think I used that kind of shortcut in here. Will have to check this out some more, sorry, been busy w/other stuff.

It's alright, between the moment I reported the bug and the moment I tried to debug it I was also busy with some other stuff, life happens, right!

Yikes, Pico-8 0.2.5.d (or e) seems to have done a number on this. After some testing, it seems the string error you guys are getting might be due to not saving the level strings before exporting, as attempting to export a header-only level string with no objects in it gave me the same error. The problem is that when I try exporting with objects in the string, the screen just goes black and the editor doesn't come up again. Also, CPU usage is way up for some reason, like 75% with just a few objects in a map, which is crazy.

I'd like to understand why all this is happening, but at this point I think it might just be easier to upload a version of the build I've been using for my Mega Man port. It's a prototype of v0.50 with some WIP features and a little bug or two, but it works and exports okay. I think I'll comment out a few things, do a bit more debugging, and upload that.

Version 0.42 is up. Debugging took longer than I planned, but it seems to be working well with no significant bugs, and since I based it on a prototype of 0.50, there are some architectural improvements. Details in the changelog.

Edit: Reuploaded to fix a small glitch with the mask object tool.