| Author |
Message |
StinkyLikecheese
Guest
Offline
|
 Posted: Tue Jan 28, 2003 6:19 pm Post subject: Level Format information? |
 |
 |
|
|
| As far as I can tell, the .lvz format is a glorrified zip file which can contain any sort of things. The .lvl file contains the actual map tiles and tile placement? If this is true, what is the format for subspace maps?
|
|
| Back to top |
|
 |
Mine GO BOOM
Hunch Hunch
What What
Age:41
Gender:
Joined: Aug 01 2002
Posts: 3615
Location: Las Vegas
Offline
|
| Posted: Tue Jan 28, 2003 6:28 pm Post subject: |
|
|
|
|
.lvz are pretty much a zip with a system to handle the extra info, such as what object goes where.
As for the .lvl, its a regular bmp with extra data tacked at the end. Just read the header information of the bmp to find the size of it, then skip past all the bmp stuff. Every 4 bytes after the bmp stuff is the actual placement of tiles. They are as follows:
That means that out of that 4 bytes (32 bits), the first 12 bits are the X coords, the next 12 bits are the Y coords, and the last 8 bits is which tile id is placed there.
EDIT: The programmer of FACTs had a nice text file on this, though i can't find where it is currently located at on my hd..
|
|
| Back to top |
|
|
nintendo64
Seasoned Helper
Age:39
Gender:
Joined: Dec 01 2002
Posts: 104
Location: Dominican Republic
Offline
|
|
| Back to top |
|
|
SOS
Server Help Squatter
Joined: Dec 02 2002
Posts: 329
Offline
|
| Posted: Tue Jan 28, 2003 11:54 pm Post subject: |
|
|
|
|
Note: The bitmap prepended to it can be any colour depth
| 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.
|
_________________
3y3 4m l33t h4x0r
j0! 3y3 4m t4lking to j00!
fux0red 5cr1pt k1dd13.
-"l33t h41ku"
|
|
| Back to top |
|
|
nintendo64
Seasoned Helper
Age:39
Gender:
Joined: Dec 01 2002
Posts: 104
Location: Dominican Republic
Offline
|
| Posted: Wed Jan 29, 2003 8:40 pm Post subject: |
|
|
|
|
i found on my harddrive the FACTS programmer Beta LVL Editor with source code, it's in Visual Basic, i hope it helps.
-nintendo64
FACTS-DS3 with Source Code
FACTS2.zip - 254.61 KB
File downloaded or viewed 137 time(s)
|
|
| Back to top |
|
|
Helicon
Server Help Squatter
Joined: Dec 03 2002
Posts: 771
Location: GNU Doldrums
Offline
|
| Posted: Wed Jan 29, 2003 9:56 pm Post subject: |
|
|
|
|
i have been looking for this code for a year, unfortunately this zip does not include the Shared Modules.. as in the registry functions
_________________
Signatures just seem so quaint.
|
|
| Back to top |
|
|
nintendo64
Seasoned Helper
Age:39
Gender:
Joined: Dec 01 2002
Posts: 104
Location: Dominican Republic
Offline
|
| Posted: Wed Jan 29, 2003 10:33 pm Post subject: |
|
|
|
|
sorry here they are 
-nintendo64
Shared Stuff for FACTS DS3
__Shared__.zip - 5.17 KB
File downloaded or viewed 120 time(s)
|
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Statistics
Register
Profile
Login to check your private messages
Login
Ok now I'm begging! 
