-
Notifications
You must be signed in to change notification settings - Fork 0
Custom File Types
Some assets, or all of them are packaged into binary files, done with Python in a few scripts available in ./tools/. This is simply to make C's parsing files much easier, as text-based data files require parsing syntax, and that's annoying in pure C lol. Even so, you would need to vendor in cJSON or something like that, which is additional library that may break the CMake build. Python's dependencies are much easier to handle with venv.
A sprite usually contains its sprite sheet, and a sprite data file, usually generated by your pixel art program. Here, I use Aesprite.
The layout of a .sprite file (Header):
| Byte Offset | Length | Data |
|---|---|---|
| 0 | 4 | The version number of the tool used to generate this sprite |
| 4 | 8 | Unsigned long of the number of bytes of the sprite sheet |
| 12 | SPR_SIZE | The image bytes copied |
The layout of a .sprite file (Continued, here the byte offset is calculated from after the image bytes):
| Byte Offset | Length | Data |
|---|---|---|
| 0 | 4 | Width of the original sheet (unsigned int) |
| 4 | 4 | Height of the original sheet (unsigned int) |
| 8 | 4 | How many frame tags (unsigned int) |
Then for each frame tag, it runs in to write a name_length (unsigned int), a name (char *, utf8), a from frame (unsigned int) and a to frame (unsigned int).
Then it would try to write in how many frames there are (unsigned int). Again similarly, for each frame tag, it would write the source width, source height, relative x, relative y, relative width, relative height, absolute x, absolute y, absolute width and absolute height of where that frame is inside the texture file (all unsigned int).
For savvy enough people to mess with the project itself
- System
- Custom File Types