Log In  

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.

P#1921 2011-11-01 10:37 ( Edited 2011-11-01 14:37)

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.

P#2109 2011-11-01 18:28 ( Edited 2011-11-01 22:46)

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.

P#2133 2011-11-01 19:17 ( Edited 2011-11-01 23:17)

Fascinating.

P#2361 2011-11-02 15:38 ( Edited 2011-11-02 19:38)

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.

P#2385 2011-11-02 16:33 ( Edited 2011-11-02 20:33)

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.

P#2406 2011-11-02 17:16 ( Edited 2011-11-02 21:19)

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.

P#2436 2011-11-02 20:31 ( Edited 2011-11-03 00:33)

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.

P#2498 2011-11-03 02:38 ( Edited 2011-11-03 06:39)

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.

P#2810 2011-11-04 08:25 ( Edited 2011-11-04 12:25)

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)! =)

P#2854 2011-11-04 13:27 ( Edited 2011-11-04 17:27)

That's great news!

P#3482 2011-11-07 10:46 ( Edited 2011-11-07 15:47)

wee! blender!

P#3489 2011-11-07 11:23 ( Edited 2011-11-07 16:23)

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!

P#6665 2012-10-02 05:10 ( Edited 2012-10-02 09:10)

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)

P#6670 2012-10-03 11:20 ( Edited 2012-10-03 15:22)

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

P#6671 2012-10-03 14:27 ( Edited 2012-10-03 18:27)

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.

P#6677 2012-10-05 10:16 ( Edited 2012-10-05 14:17)

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.

P#6678 2012-10-05 15:26 ( Edited 2012-10-05 19:26)

[Please log in to post a comment]

Follow Lexaloffle:          
Generated 2024-03-28 13:01:34 | 0.042s | Q:35