Open
Conversation
Also util to get the current working dir.
No dependency management yet.
Default main module is not fully implemented yet though.
This allows for greater flexibility since the main module is now a sub system and can be integrated in the existing dependency management chain.
Contributor
|
Currently crashes on release: |
Setting of linker options was done incorrectly and CMake proves to be an inconsistent son of a bee once more...
Provide helper function to get the default root path as an absolute native path.
To prevent erroneous use of ezStringBuilder to create paths.
The function returns -debug, etc. as a string, which is used to load the proper game modules in the current config mode, e.g. asteroids-debug.
pullRuntimeBinaries has been generalized to work with krepel and outside project as well. kr_client_copy_dlls for krepel projects is now obsolete. This makes it easier for client projects to retrieve runtime files whenever they want.
Instead of using ezWindow directly.
The state in this commit is not to be taken to seriously, as things will change a lot soon.
kr::GameLoop was removed and the global registry now associates a name with a given callback. Dependency management is still NOT implemented yet. Also fix issue with global clocks. Renderer and module now keep their own instances.
Game loops can now be sorted by priority, which ist just a signed 32 bit integer. I refrained from implemented a full-blown dependency management system as it is probably overkill for us. There is a convenience function to print the tick order, which can be used for debugging (kr::GlobalGameLoopRegistry::printTickOrder).
Because by now its not just a registry anymore.
Also add some docs for kr::DefaultMainModule::tick.
We now have a proper project template (as opposed to having everything hardcoded as string within a single python script). Every files' name and the contents of the files that belong to the project template can use the substitution syntax ~{var_name}.
The krGameLauncher is basically obsolete now because it is always generted to the new projects and will be called like the project with a `_launcher` suffix.
as well as GameTest1 which depended on it.
Member
Author
|
I think it's time to take this code right into some action to see how we can extend the framework. There are still several parts missing like easier rendering interface, but that also depends on our rendering code, which will be heavily refactored soon I believe. I want to test the current framework with asteroids for example to see how to improve it. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The idea is to have a proper game framework where we can create new games fast in a flexible way.
Oh and... whoops, did some more work than just the game framework. 😛