Large-scale engine refactor #58
Merged
Conversation
This file contains 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
Just use ClientRoot to fetch these for now - most of the places where we're accessing these are gonna need refactoring so that we can have many game/server instances. I think ISubSystems should have a Root parent, which you can use to access these variables rather than using GetInstance() everywhere
We don't want bindings to be "global" like they are now. Ideally we want to make it so that C# can use bindings based on whichever context / realm / etc. it's in, and we want to be able to spin up multiple clients & servers if necessary. So in order to do that, we're going to do class-specific bindings rather than the monolithic namespaced bindings we have now. This should hopefully also make things a little bit easier to manage. Note that the engine won't run properly at the minute because I haven't updated anything to use these new bindings - they're still a work-in-progress. I also want to do a few things in order to make bindings more powerful, as well as make bindings automatically translate from C++ types to interop-compatible C types - that'll probably be what I tackle next.
Will be replaced again later on, this just makes it easier to do so
might re-write interopgen later
…rite this tomorrow)
# Conflicts: # Source/Mocha.FrameworkBench/Mocha.FrameworkBench.cpp # Source/Mocha.Host/Framework/handlemap.h
This refactors only the Framework version of the HandleMap, which isn't being used anywhere in the engine yet. - Use std::vector as backing collection instead of std::unordered_map - Remove HandleMap::Find(), HandleMap::RemoveAt() - Speed things up significantly by returning const refs to unique_ptr instead of copying shared_ptrs - Add operator[], Front(), and Back() This provides a significant speedup - from ~7M lookups/s to ~16M/s. This still isn't as fast as using Mocha::Array (~181M/s) so there's still a lot of work that could be done here.
InteropGen cleanup
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Description
This pull request implements a lot of large-scale engine changes that are part of #53, but does not include any network-specific code.
Global.NativeEngine(or justNativeEnginein most cases)GlobalnamespaceHandleMapnow has functions forRemove,RemoveAt, andFindAPI Changes
Callbacks
Managed -> Native Callbacks
To register a callback that can be called from C++: