Your level format looks interesting.
Is all the information about the level encoded in what looks like a colored 2D barcode?

Just curious: would you like to share some more information about it with us?

EDIT: I know it probably isn't like a barcode, it just reminded me of one.

What I think is interesting about it, is that it doesn't seem to save the data as metadata but as image data [EDIT: particular embedded in a preview image].

And I would guess it doesn't really work like a barcode. I think they just write their level format (about which I'm curious too) in this box in the image (or better, in these several ranges of the image data).
And then it looks like a 2D barcode, but it is of course more efficient than 2D barcode formats because there is no need for mechanisms to detect and locate the information or for fault-tolerance.

Right. The actual level data is encoded inside the white rectangle at the bottom. You can do whatever you like to the rest of the image, and resave it, and it will still load.

Fascinating.

very cool.

Are you using .png alpha channel as height or something sneaky like that?

I am hungry for more information on how you accomplished such a clean and compressed level format.

I'm no dev and I dont know it but I guess its more than just the plain blocks. It has to be compressed with some specific level format.
1 pixel = 4 byte (32bit RGBA png)
If your level has a white rectangle with 480x3 pixel that would be 5760 byte.
If he would save a 256x256x48 level 1:1 he would need at least 3.145.728 * SIZE_OF_ONE_BLOCK.
I daresay hes compressing it on the map level (so repeating chunks of blocks are wrapped up) + some space for the chunk/block triggers.

I can confirm that the level data is stored in the odd box. Changing other portions of the image, including the metadata, has no effect on playability.

I have also found that resizing the image breaks the level and (on linux) just segfaults. It also segfaults if you put black slashes (don't ask) through the voxelcode.

Of course it is in the box only. Just place a block in the Editor, and compare the rectangle or extract the bytes and compare them with an empty level.
But since its compressed and I have no idea what algorithm he uses I didn't manage it to decode the level data.

I tried messing with the level data in GIMP - but with no success. Due to the compression, everything I tried (however small the changes) damaged the syntax and lead to unreadable levels or made Voxatron crash.
There was one little success, though: When I slightly lowered the alpha value of one single pixel in the data of an empty level, the file was actually still readable. The only differece was that in the "objects"-tab of the editor the items 9 to 15 were missing.

I've given it some attention as well, but mainly because I wanted to write a Blender -> Level-data exporter. I tweeted @lexaloffle about it and here's the response:

SenshiSentou:
@lexaloffle Any chance you could make the algorithm you use 4 saving level data to the pixels bar public so we can start writing exporters?

Lexaloffle:
@SenshiSentou I plan to make some exporters/importers, and post a spec for the file format. Check back in a Couple of Weeks (tm).

So it looks like we'll be getting some more information on this ingenious little encoding soon(ish)! =)

That's great news!

wee! blender!

Any update on this? I'd love to be able to render Voxatron levels in other software.

We don't need anything fancy, just a raw dump of the voxel data would be a start!

I held off publishing the file format because it was (and still is) changing so much

But a raw dump of data is certainly overdue. What format would suit you?
size[3], palette[256][3], dat[size[0]size[1]size[2]]?
Or a bunch of pngs? (one for each slice)

A bunch of pngs is not practical when sharing...

Couldn't you dump information into a .txt file? Sort of like for each coordinate in a room, use a format like [t,c,m] where T would be "true", whether or not that coordinate had a physical voxel, C would be the color, and M would be the misc. properties of the voxel (I.E. Sand, void, indestructable, part of an entity, etc.).

Sorry if I'm coming off as inner-workings-of-software illiterate, but I just finished a very simple algorithm in TI basic and feel like a master mathematician/high-level programmer right now.

Oh god, I should stop typing.

heh, well in this case it probably doesn't make much difference because the data is quite simple (It will be just the colour index, with zero for empty). The harder work is doing something useful with the data.

Anyway, so I just ended up doing all 3 (: You can save as a .txt, .png or .raw and it picks the format based on the extention. .png is a single image of each slice arranged vertically (e.g. 16x256 for a 16^3 model. I'll post more details with the release.