Rationale
Create an intuitive API for asset loading from both internally within the ROM (ROMfs) and externally via the SD card (SDfs), which reduces or eliminates the need for wrangling a linker to insert an asset into a game.
Existing work
libdragon's DragonFS looks like it comes with tooling and a C-compatible API, with the idea of default URI's (rom:// vs sd://) for different accesses, vs. manually mounting a drive
libcart comes with a FatFS implementation, which would be required for SD card anyway, and could be useful for keeping the ROMfs simple. The file functions are C-like, but named differently for what seems to be an archaic reason
Initial Comments
I don't believe we need anything fancy like libdragon's concept of creating e.g. a sprite_t from a texture file. Our equivalent concept could simply be "fread a texture into a buffer and then call gSPSetTextureImage" and it would be fine™️ .
Rationale
Create an intuitive API for asset loading from both internally within the ROM (ROMfs) and externally via the SD card (SDfs), which reduces or eliminates the need for wrangling a linker to insert an asset into a game.
Existing work
libdragon's DragonFS looks like it comes with tooling and a C-compatible API, with the idea of default URI's (
rom://vssd://) for different accesses, vs. manually mounting a drivelibcart comes with a FatFS implementation, which would be required for SD card anyway, and could be useful for keeping the ROMfs simple. The file functions are C-like, but named differently for what seems to be an archaic reason
Initial Comments
I don't believe we need anything fancy like libdragon's concept of creating e.g. a
sprite_tfrom a texture file. Our equivalent concept could simply be "freada texture into a buffer and then callgSPSetTextureImage" and it would be fine™️ .