-
Notifications
You must be signed in to change notification settings - Fork 102
Fix NON_PORTABLE build. Ship::Context needs to be initialized first. #618
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
…resolving files. Move offending calls inside functions where they are used. Those will always be called after GameEngine() which runs Ship::Context::CreateUninitializedInstance() early.
coco875
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm then move hardcoded string "mk64.o2r" and "spaghetti.o2r" in const variable then
Not sure what you mean, you would like to define them in a single place for all their occurence in the whole project ? NON_PORTABLE mean the ressource manager will search in CMAKE_INSTALL_PATH & in user's HOME but to do so it need to be properly initialised before, which was fixed in the GameEngine(), see src/port/Engine.cpp in https://github.com/HarbourMasters/SpaghettiKart/pull/532/files. |
|
This is a good change! Thank you. I believe coco is asking to put
And then you use assets_path in the function call just like you have |
|
I just mean have to be a bit more future proof if we change file name in this file not all the code |
|
What about using define in src/port/Engine.h, like this : #define GAME_ASSET_FILE "mk64.o2r" |
|
That can work but why use macro and not static char array ? |
The issue is this is global for the whole code-base. If that's what we want that's fine. But modmanager.h isn't the best place for this. Maybe defines.h, maybe mk64.h If wanting it only in the local file, constexpr, const char*, or #define with an #unfdef at the end of the file are the best options. |
|
The "spaghetti.o2r" is also used in src/port/Engine.cpp.
To be able to use globally without thinking about extern stuff. If we declare the variable in a file, then other files must use extern to reference it. I should check how it compiles if in the same file we have the extern declaration (from header) and the const variable. Note I didn't audit header and how they are included. But this complexity just to gain a few byte ?
I'm thinking how this could be generic for all games. Using a define could be done from cmake also. All games share the same construct with engine and game assets. |
|
For string see how we have done for path of asset, we never use extern thanks to the static key word, also compiler have optimisation in release to de-duplicate string |
|
This specific situation is so trivial I don't think it's necessary to think about all games unless you want to put in the work of PR'ing to all of them. Some projects may decide they don't want the change. Engine.h is also a good place. I don't think I considered it earlier, but it's also an applicable place. I think we've mentioned a number of good solutions. Please pick one. #define for engine.h is okay. constexpr is okay, if I think coco's suggestion is good. |
|
Sorry I'm lagging on this PR. I'm sick thus, I didn't hack yesterday and I'm a bit slow. A static is ok and builds fine. Without static, it complains about duplicate symbols. I didn't try to define an extern. If we build with static, then we have twice spaghetti.o2r, one for ModManager and one for Engine. Atm I'm building at -O0 so I want to build in prod just to know if clang will also duplicate strings. If we build with #define then we only have one occurrence of each string. I used this command to check for those strings (on OpenBSD but I guess the same applies to Linux also): I know I started this bikeshed, but I do not have any strong opinions. Considering assets are variables (with memory alignment?) I think we should do the same for coherence purposes. Regarding other games, it seems to me some of the code could be factorised and shared. I can't tell how far I would invest my time in this project. At least, I want to fix audio on OpenBSD and all games share the same issues: Conclusion. I think we all agree for: Then the only question remaining is how we share this variable (in which header) with Engine.cpp and ModManager.cpp ? |
|
Put it in Engine.h for now and we will move if necessary, it's just a variable |
…me_asset_file and engine_asset_file.
Please check the commit log. As I'm new to SpaghettiKart, I don't know yet how to use mods. The change looks safe but if someone can confirm mod still works, I would appreciate.
Patches found on https://aur.archlinux.org/cgit/aur.git/tree/spaghettikart-pkg-fixes.patch?h=spaghettikart-git
Without the patches it fails like this on OpenBSD (as example) :