-
Notifications
You must be signed in to change notification settings - Fork 3
Formats
libDarnit uses a few formats not found anywhere else. There's mostly no reason for this other than "why not." Support tools for working with them are mostly available though.
- LDI - libDarnit Image - Filesystem image format for libdarnit
- LDMZ - libDarnit Map - Map file format for libDarnit
- MTS
- DSPR
- STZ
- TMA
- Supported image (picture) formats
A LDI file "libDarnit Image" is a file container clumping multiple files together into one. It is mainly to reduce clutter without needing massive directory hierarchies. Like zip, an LDI can be opened even if it's appended to another file (that isn't a LDI) since the necessary info about it is also located at the end of the file.
To access a file inside an LDI, you need to mount the LDI. This adds all the files in the LDI to the VFS that darnit-filesystem looks in when you try to open a file.
To create a LDI file, it is recommended that you use the with libDarnit provided utility called darnit-fsimage. It adds all the files in a directory to a LDI. Inside the LDI, the file appear under the directory you added them from.
For example, if you run darnit-fsimage directory directory.ldi, the file directory.ldi will be created containing the files in directory. If you have a file called file1.blargh inside directory, after that you mount directory.ldi, you can open it by calling d_file_open with directory/file1.blargh as fname.
All integers in the LDI file is stored in big endian. Here is a figure showing the structure of a LDI file.

typedef struct {
unsigned int magic;
unsigned int version;
unsigned int files;
} FILESYSTEM_IMG_HEADER;This is the main header, it's located at the start of the file.
- magic - The magic number for LDI files is 0x83B3661B
- version - The version for the currently implemented LDI specification is 0xBBA77ABC
- files - The number of files contained in the LDI file
However, LDI files can also be appended to other files and still be perfectly mountable. Therefore, at the end of every LDI file, the following struct is present.
typedef struct {
unsigned int file_size;
unsigned int magic;
} FILESYSTEM_IMG_END;- file_size - Size of the LDI image file including all headers but this one
- magic - Same magic number as in the man header
As visible in the structure, following the main header, there's a bunch of FILESYSTEM_IMAGE_FILE structs. One for every file in the image in fact. These are tightly packed. The struct is shown below.
typedef struct {
char name[128];
unsigned int pos;
unsigned int length;
unsigned int comp;
} FILESYSTEM_IMAGE_FILE;- name - A NULL terminated string with the name of the file including the full path it shows up under when the image is mounted.
- pos - Number of bytes into the data area that the file data is stored
- length - Size of the file in bytes
- comp - A "checksum" of the filename calculated by casting the chars to unsigned and adding them all together. Used for fast file lookup
No data is compressed.
LDMZ is a map file format made for quick and trivial loading at run-time with minimal external dependencies (all you need is a zlib decoder, sdb_image provides this if you don't want zlib.) LDMZ supports multiple layers, but only one tileset per layer. This is normally not an issue.
Currently, the only way to create an LDMZ map file is to convert a Tiled TMX map with darnit-tmxconv. darnit-tmxconv is included with libDarnit.
For conversion to be successful, you need to add a map property called "tileset" with its value being the path to a tileset to use. You can override this per layer by creating an entry like that in the layer properties.
Object polygons are not supported, and the width of an object is ignored.
LDMZ does not support polygons. Object coordinates are in whole tiles, not in pixels. This is because tilesize is overrideable load-time.
libdarnit can load image (texture) data from any image format supported by stb_image. STB Image supports the following formats:
- JPEG (baseline only)
- PNG
- TGA
- PSD (composited view only)
- BMP (except for 1-bit per pixel resolutions and RLE encoded images)
- GIF (no animation though)
- HDR
- PIC