Allow configuring the path of game assets
sug0 opened this issue · comments
Somewhat related to #47
The game currently assumes all assets are stored under the same directory the executable is launched from, e.g. wipeout/<asset-path>. The make file should define an ASSETS variable, that could be overridden to, e.g. /usr/share/wipeout. This would improve the packaging of this game.
It should be a relatively trivial patch to implement, changing all hard-coded paths to reference some flag defined with, e.g. -DASSETS=$(ASSETS).
See also #10.
Part of the suggestions was also adding a compile-time variable like that for packaging integration.
The changes I made were so it could be packaged. Though I made it consciously in a way that wouldn't be as useful as adding that option too, just because of time and effort. For packaging I ended-up targeting $out/opt and having a script in bin execute the wipegame executable from the opt path, since this was using SDL_GetBasePath, and on many platforms it's the directory of the executablt itself.
Note that SDL_GetBasePath on some platforms (e.g. macOS) it ends-up using the "appropriate" path for assets. So it's the correct function for a game to use, but it's not done in the most useful manner for distro packaging :).
Reason I haven't merged this yet is 1) it only works for the SDL build (though maybe that's ok for now?) and 2) I believe the API should be different. I need to think about it a bit more, but here's my idea:
Every platform_*.c should provide the following 3 functions:
uint8_t *platform_load_asset(const char *name, uint32_t *bytes_read)platform_load_userdata(const char *name, uint32_t *bytes_read)platform_store_userdata(const char *name, void *bytes, int32_t len)
For SDL we use SDL_GetBasePath() and SDL_GetPrefPath() as suggested in @samueldr's PR. For Sokol we should at least figure out the base directory of the executable.
With these 3 functions for each platform, we could use (e.g.) UserDefaults.standard.set(savedata, forKey: name) on iOS to store the save file. Similarly, consoles could write save data to a memory card here.
Finally, the paths used by these 3 functions may be overridden by -DPATH_ASSETS=... and -DPATH_USERDATA=.... Am I correct in my understanding that these will always be absolute paths? I.e. there's no need to resolve PATH_ASSETS relative to the executable, ever?
Finally, the paths used by these 3 functions may be overridden by
-DPATH_ASSETS=...and-DPATH_USERDATA=.... Am I correct in my understanding that these will always be absolute paths? I.e. there's no need to resolvePATH_ASSETSrelative to the executable, ever?
That's how I assumed using those macros would work. Assume the path is valid and the packager knows what they are doing.
Generally PATH_USERDATA wouldn't be used by distro packaging, but might be useful for more specific use-cases, e.g. builds targeting distros made for those made-for-emulation portable devices.
Above commit implements this all as I previously outlined. Additionally the Makefile now supports a USER_CFLAGS var:
make USER_CFLAGS="-DPATH_ASSETS=/some/specific/path/"
no intro or music with this compile flag.