Open m-r-hunt opened 1 month ago
Hmm... I'd like to avoid expanding the scope of sokol_fetch.h too much (and if yes, then by allowing some sort of plugin interface to hook up your own virtual file system functions, so that such things could be implemented without extending sokol_fetch.h itself.
Interestingly I've had the opposite requests in the past: allow sokol_fetch.h to do HTTP requests on native platforms instead of loading from the local filesystem).
If you only need to load files from the Emscripten filesystem wrapper it's probably better to directly use the Emscripten filesystem functions together with regular fopen/fread/fclose, e.g. see: https://emscripten.org/docs/api_reference/Filesystem-API.html, and if you need both (loads files from HTTP and the Emscripten filesystem), write your own minimal wrapper API.
Here's my thought process/motivation:
on other (non-web) platforms, I want to have my asset files distributed somehow with my game and load them with sokol_fetch
on web/emscripten I want to have the asset files embedded with the build so they are loaded up front and then access them with the same code using sokol_fetch without being platform aware
Obviously that's not the only possible workflow, and I can get my game to work (I'll probably ditch sokol_fetch and just load the files the old fashioned way on all platforms).
If you don't want to support this then just close this issue, no worries.
I was trying to use embedded files from Emscripten (https://emscripten.org/docs/porting/files/packaging_files.html) with sokol_fetch but it seems like sokol_fetch always makes a http request in a web build and has not support for loading from the virtual filesystem.
It seems like it would be a nice option to be able to do this so you can access embedded files in a unified way with sokol_fetch. I guess there would need to be something to tell sokol_fetch what is a http request and what is a local file access.