Game Resource Importer

game-resource-importer provides a procedural macro similar to include_bytes! which also converts the data to another format and saves it in a directory that can be committed to source control (or not). To minimize the manual work of exporting specific types, the idea is to convert from source files like .blend and .ase files to formats usable by games, like raw RGBA arrays and glTF (or even simpler 3D formats). In order to achieve this, the appropriate local program (blender, aseprite) is executed by this procedural macro to export the correct format. Additionally, the saved file is parsed at compile time and returned as a directly usable struct.

Since you may wish to compile your game on a system without these programs (such as CI), the converted file is saved in a directory called .game-resource-imports, so that you can include it in source control. The .game-resource-imports directory is placed in the nearest parent directory to the import_resource! caller which contains a Cargo.toml, so generally next to your src folder. The conversion process is only triggered if the source file is newer than the latest converted version.

Timings for how long executing each part of the procedural macro took are written to target/game-resource-imports/timings.log.

Supported formats:

• Aseprite files (.ase, .aseprite) for importing into regular images. Spritesheets and animations maybe later?
  • Can be converted to image-rgba and image-palette (only up to 256-color palettes).
  • Requires the aseprite[.exe] executable on the path.
• GIMP files (.xcf) which can be exported as 32-bit RGBA TGA images.
  • Can be converted to image-rgba.
  • Requires the gimp[.exe] executable on the path.
• Krita files (.kra) which can be exported as 32-bit RGBA TGA images.
  • Can be converted to image-rgba.
  • Requires the krita[.exe] executable on the path.

Wishlist:

• Trenchbroom files (.map)
  • The first format: raw brushes, since they're nicer in gameplay code, probably actually a sane amount of work, unlike...
  • The second format: basically whatever I end up doing with blender files, minus the animations, for rendering usage
• Blender files (.blend)
  • Could base the conversion off of glTF, and extract the following into structs:
    • Meshes (primitives, sets of triangles you can render with a specific set of parameters)
    • The scene graph
    • Materials (0-5 images? could reuse the TGA images for rgba textures, since you need to write the pixels to the gpu anyway, no use being already uncompressed. gpu compressed formats are their own thing of course)
    • Skeletons (vertex weights, the actual bone transforms)
    • Animations (depends on the skeletons)
• Some audio format? .aup?
  • .wav is definitely the intermediate format here, but I'm unsure which DAW to prefer here.
• Tracker files (.xm)
  • Depends on if this would benefit any player implementation. There are probably pretty good ones that just play from the .xm bytes, in which case this library is not needed, just include_bytes them.
  • Otoh, this could turn into a whole integrated .xm renderer project, similar to how tga files are converted to usable pixels during runtime. That's probably too much work though.