Server Help

Helicon · Posted: Fri Nov 21, 2003 11:57 pm Post subject: Level Format Suggestion

Tell me what's wrong with this:

24 bits total
8bits: tileValue (9bits:x) (9bits:y)

tileValue contains tile and object constants plus (isn't there room?):
QUAD1
QUAD2
QUAD3
QUAD4

they define the beginning of the quadrants, so that x and y can be defined with 9 bites(2^9 = 1024/2) instead of 12. Still bit shifting, but i like it.

keep in mind, that if the tile is the first value read, there is no need to include x and y when defining a quadrant

Code: Show/Hide

Tile:QUAD1
Tile:QUAD2
Tile:NormalTile1
x:200
y:503
Tile:QUAD3
Tile:QUAD4
...etc

in the above example there is only one defined tile:
at (200,503) from the origin(lower left) of the 2nd quadrant which starts at (0,512)
which means that in the old format it would be expressed as

X:200
Y:503+5012
Tile:NormalTile1

sure, there is overhead with defining the quadrants(which may not be necessary if there are no tiles defined there). but usually there are more than just a few tiles in a map... so the 3 extra saved bytes/tileRecord start to make sense.

I also don't see why a tileset should be appended to the beginning of the file. Wouldn't be best to make lvl a sort of lvz-esque glorified .zip with a map (in the above format) and a .png (already lossly compressed) tileset with a matching filename

so lvl is an archive containing (for example):
mainMap1.png
mainMap1.lvl
including the QUAD1 tileValue would also ( i believe, if its unused currently) allow for a backwards-compatible parser to be written, assuming the file isn't zipped
_________________
Signatures just seem so quaint.

Mine GO BOOM · Posted: Sat Nov 22, 2003 11:40 am Post subject:

Instead of making up your own storage method for LVLs, why not use a proven one? Storing the map information as a png itself (like how you convert lvl -> bmp) will heavily compress the map a lot more and will be much more reliable than you or others trying to create efficient algorithms for using these quads. Then you could just tack on the png 'map' after the png tileset.

Helicon · Posted: Sat Nov 22, 2003 12:21 pm Post subject:

enough said!
please keep talking... i dont know much about png's from the inside. could you type out a sample? not bit by bit of course, but just abstractly...

Smong · Posted: Sat Nov 22, 2003 1:50 pm Post subject:

Using your QUAD thing would require the tiles in the level to be sorted into some kind of order, whereas currently they don't have to be.

Also you can create a .lvl with no tileset and then include tiles.bm2 (or even as .png) in a .lvz.

Helicon · Posted: Sat Nov 22, 2003 8:24 pm Post subject:

why not store them in some kind of order? it's adding a one-time burden to the editor and taking more bits off the file that the client has to download and store...

MGB's idea is much more effective for compression, though.

Mine GO BOOM · Posted: Sat Nov 22, 2003 10:51 pm Post subject:

Official PNG website. I'm pretty sure someone has made a java library for loading pngs, as they are very nice, and are older/as old as subspace itself.

Dr Brain · Posted: Sun Nov 23, 2003 12:03 am Post subject:

Java has it built in.
_________________
Hyperspace Owner

Smong> so long as 99% deaths feel lame it will always be hyperspace to me

Helicon · Posted: Sun Nov 23, 2003 12:10 am Post subject:

of course it does