Code: Show/Hide u12 X
u12 Y u8 Tile |
| Quote: |
|
SubSpace Level File Specification (.lvl) OPTIONALLY (prepended to standard .lvl): A 256-color bitmap image file may be prepended to the map data. The standard tileset bitmap is a 49718 byte bitmap, 304x160 pixels. Tilesets must be 304 pixels wide (19 16-pixel wide tiles wide). Tilesets _can_ be fewer than 160 pixels high. "_castle.lvl" has a tileset that is only 144 pixels (9 tiles high). Other heights may work, but have not been tested. If the "Total BMP file size" (the first four bytes after "BM" at the beginning of the bitmap) is incorrect, SSME will almost certainly choke and Subspace will likely as well. REQUIRED: For each non-blank tile on the map: 01 23 45 67 \______/ \--> Tile number \ \-------> Coordinates of tile Tile numbers (hex): 00 = blank (not legal in .lvl file) 01-13 = normal tiles 14 = border tile 15-A1 = normal tiles A2-A5 = vertical doors A6-A9 = horizontal doors AA = flag AB = safe zone AC = goal AD-AF = flyover B0-B7 = flyunder (opaque) B8-BE = flyunder (with transparency) Special tiles: D8 = small asteroid 1 (1x1) D9 = large asteroid (2x2) DA = small asteroid 2 (1x1) DB = starport (6x6) DC = wormhole (5x5) All other tile numbers are illegal. For tiles larger than 1x1, tile coordinates mark top left corner and no other tiles can be placed where they would be overlapped by the large tile (FACTS will remove the illegal tiles). I don't know what will happen if you manually place an overlapped tile. Coordinates: "01 23 45" represents an example coordinate set pulled from a level file. The X and Y coordinates are packed in the three bytes by a simple formula: 01 23 45 ---> X = 301h, Y = 452h Note: the simplest way of reading this is that each tile is one four-byte integer (in VB, this would be called a "Long"). Read it in and you have (assuming little endianness): TileValue = Tile * (2^24) + Y * (2^12) + X Of course, this is just an example. The X and Y coordinates can vary from (0,0) to (1023,1023), which yields "00 00 00" through "FF F3 3F" (using the packing formula above). Note: Apparently, the tiles in the .lvl do not have to be in order. It's nice if you're making a program to keep them in order, but if you're manually editing, it doesn't seem to pose a problem if the tiles are out of order. (I make no claims regarding compatilibity, of course... :) Note: The "assuming little endianness" comment just means that if you're working on, say, a Sparc system, you have to remember to mangle the byte order, but on any x86 style CPU, there's no problem there. This analysis brought to you by: The FACTS Team http://ss.ClayJar.com/ subspace@clayjar.com Based on information gathered from our own analysis of the format. |
