LVL file format

[Drake7707]

For some reason even beyond me, i wondered about the file format.

Now a lvl file can be as much as 4mb, but usually it's smaller because it only saves x,y, tile for every non 0 tile. But why wouldn't there be a flag like compressed/uncompressed, that, when the number of tiles exceed 333334 tiles (~1mb) it switches over to a standard bitmap like

 

tile tile tile tile tile tile .... tile

 

for every tile, that would also be ~1mb. That way, lvl files will never exceed 1mb.

[Shock]

Oh man.. Very clever.

 

Can I have your brain?

[rootbear75]

?

maybe my brain is farting right now... but im not understanding exactly what ur saying

[Bak]

if there's more than 333,334 tiles, then about 1 in 3 spots on the map is a tile, which is ridiculous (hmm shouldn't it be 1 in 4 since 8 is 1/4 of 32?). The only only maps I can thing of that would benefit are the ones that have a tile background, but since lvz takes care of that in a much nicer way it wouldn't have much application (scan your zones folder for .lvl files bigger than 1 mb in the tile section [skip the tileset and elvl data]).

 

Even more savings would be to have a "current tile" and just give the tile numbers of the locations, rather than pairs. Using this, the trade off would occur much sooner.

 

Currently you use 32 bytes per tile. With the mine you would use (!@#$%^&*ume tile id <255> means change tile)254 * 16 bytes for changing tiles (if you use all 254 tile types, as an upper bound) + 24 bytes per tile.

 

32*x = 254*16 + 24*x

x = 508

 

So if a map has 508 tiles you'd be saving space (instead of 333,334 tiles). This means you save space for lvl sizes bigger than (not counting the tileset) 15.9 kb. You could take it a step further and have vector-like drawing instructions where rather than only being able to place points on the map, you can place entire lines and rectangles. So for example, to place a line of the same tile type you could do:

 

<254>

 

it would again, use the current tile type. This would mean encoding a line would take 48 + 8 bytes, so that if the line is 3 or more tiles long, it would save space to encode it this way. Rectangles would be similar. However this is interesting because now the size of the map is dependent on the program that's saving it as well as the format, since this is very similar to like vector graphics.

 

The thing is, all this is nice and all, but it's a bit overkill. Think of when you were making DCME. If you couldn't load a map very easily right at the beginning, you would have probably been swayed away from the project.

[Samapico]

Actually it wouldn't be too hard. As Drake said, just save the map as a 256colors bitmap and you save space without any encoding. Now, make that bitmap a PNG with standard encoding, and you get a very small filesize easily

 

But anyway, all that talk is useless if there isnt a new continuum client

[Bak]

i'm not so sure about that png thing (hey that rhymes!). pngs are good when there's large areas of contiguous color, so this would correspond to a large area of the same tile. save for the blank tile, this isn't usually the case... worth a shot tho. Then again you could just zlib compress the .lvl file when you send it and get about the same compression as png...

[Samapico]

yeah, zlib would definitly be simpler.