The internal structure of resource binaries consists of 3 parts:

Header buffer

Fixed-length buffer of 12 bytes. Contains the length of the TOC buffer, as well as format identifiers.

The header buffer for the default spawnset looks like this:

3A68783A 72673A01 15340000

TOC buffer

Variable-length buffer that lists all the chunks (assets). Here are the first 3 entries in the TOC buffer for the resource file 'dd':

10 00 6465627567 00 21340000 6E070000 00000000
11 00 6465627567 00 8F3B0000 00000000 7BCC0557
10 00 6465707468 00 8F3B0000 AB010000 00000000

The first byte represent the chunk type. Here's the list of chunk types:

As you can see, the second TOC entry represents an empty chunk. These were probably meant for fragment shader entries in the TOC buffer but now seem to be unused. Shaders are now 1 chunk containing 2 files (a vertex shader and a fragment shader), but it might not have been like this during development.

Chunk data buffer

Variable-length buffer that contains all chunk data. This data differs per chunk type.

Audio chunks

The chunk data for an audio chunk is the exact same as the contents of a 2-channel .wav file with 44.1kHz sample rate in PCM format.

Model binding chunks

The chunk data for a model binding chunk is simply plain text.

Model chunks

The chunk data for a model chunk consists of 4 parts:

Here are the model headers for 'dagger', 'hand', and 'hand2':

B4000000 A4000000 2001
78030000 B9000000 2001
A4040000 EE000000 2001

The vertices are stored as a list of vertex objects, which are defined as:

Here is an example:
9A99193D 00000000 075F983C 6E12433E 653B3FBF 6F1223BF 492E7F3D 1158993E

The indices are stored as a list of 32-bit unsigned integers.

Shader chunks

The chunk data for a shader chunk consists of 4 parts:

Here are the shader headers for 'debug', 'depth', and 'particle':

05000000 FB020000 62040000
05000000 EA000000 B0000000
08000000 E8050000 0C090000

The shader name is listed so the format knows at which point to start reading the vertex and fragment buffers.

The vertex and fragment shader buffers are stored as plain text (GLSL code).

Texture chunks

The chunk data for a texture chunk consists of 2 parts:

Here are the texture headers for 'dagger', 'hand', and 'sorathmask':

1140 40000000 40000000 07
1140 00010000 00010000 09
1140 F0000000 F0000000 08

Each pixel contains 4 color components in the order: alpha, blue, green, red. All components are 8-bit unsigned integers (bytes). The stride of a texture can be calculated by multiplying the texture width with 4.



There are 3 files in Devil Daggers which use this format. These are 'audio', 'dd', and 'core'.

The 'audio' file

This binary consists of audio files (.wav) and a "loudness" file. It is the largest binary and makes up for almost 90% of all data.

In addition to audio chunks, the audio file contains a loudness file. The loudness file is a plain text file that lists all "loudness" values for most audio. These values are numbers and represent which audio files have priority when playing, e.g. a sound with loudness 2 will be prioritized over a sound with loudness 1 by the audio engine; both sounds will still be played, but the one with the higher loudness value will sound more apparent than the other. Loudness does not correspond to volume. In other words; specifying a higher loudness value doesn't necessary make a certain audio asset louder on its own. You could say that audio assets with a higher loudness value effectively make all other audio assets with lower values more quiet.

The loudness specifies the volume for 217 audio assets, 5 of these assets do not exist in the current version of the game (collectgib1loop, collectgib2loop, collectgib3loop, eyepacify, ricochetmagic5).

51 audio assets have no loudness specified. When no loudness is specified, the game defaults to loudness 1.0 for these assets.

Oddly enough, the binary format treats this file exactly the same as the .wav assets. Devil Daggers Asset Editor treats this file as a .ini file however.

The 'dd' file

This binary consists of models, textures, shaders, and model bindings. The file contains some garbage data in the TOC buffer (unused entries with type 0x11).

The 'core' file

This binary consists of UI-related shaders. It is the smallest binary. The file contains some garbage data in the TOC buffer as well as some more garbage at the end of the file.