Closed sug0 closed 1 year ago
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_ASSETS
relative 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.
Somewhat related to https://github.com/phoboslab/wipeout-rewrite/issues/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 anASSETS
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)
.