That is certainly possible. And at least doing the approach 1 first will validate if the performance improvements are there to be gained.
I can’t for certain say whether rewriting a bunch of the C# code and then converting as is to C++ is easier than converting to C++ while refactoring the entity handling approach in one go. One of those may or may not be less effort than the other one.
Well doing approach 1 would kind of already validate whether approach 2 has a chance of fixing the performance.
Also I opened a thread recently that would validate the idea of using C++ components for speed, so if this is done first: Using C++ components in the game it will set the stage for more C++ stuff and also give us results as to whether the kind of speed up we want from using C++ is actually achievable or not.
For just getting started I see just two choices:
- Someone edits the game to take out the entities from the Godot scene tree and still render them somehow and runs logic for them to check if the part which I think is slow (letting Godot handle the scene tree and collisions in there), and sees how fast that is
- The custom physics integration and running the entities separately just needs to be done in a quick and dirty way that doesn’t necessarily have all features working and might crash often, but as long as it is stable enough we’ll get some performance numbers with that