Just a short update here! I ran into some problems with the new Quaternion code, I’ll detail those in a later post. As part of getting that to work, I got sick of having to start the game over and over again. To alleviate this tedium, I implemented unit testing for the Actor methods related to the Quaternion work in the Grim Engine. Neat, but why was that interesting?
To get this working, I needed to solve a few problems:
- Some methods depend on a working, initialized GameEngine
- Linking all of the parts of ResidualVM into the test binary
In some of the methods, the engine depends on being initialized, with all of the correct settings. An obvious example of this is the check to see which game is being run by calling the getGameType() method. So, to fix this, I have written the minimum required code to start the main engine from the tests.
With that fixed, the next problem was that linking together the test binary was not as simple as before. If you just add the libgrim.a object, there will be quite a few missing objects in the final linked binary. To fix this, I found all of the .a files generated by the compiler and added them to the module.mk file for the testing build. Just adding them will not solve all of the dependency issues because the linker will search in order through the .a files to find the required symbols. If the objects containing those symbols haven’t been passed to the linker yet when encountered, the symbols will still be unresolved. So, you must order the objects so that all of the symbols can be found. Additionally, I added some extra code to the module.mk file so that when (for instance) support for Grim isn’t built and only Myst3 support is, the associated tests are not run.
I don’t think this will get submitted to ResidualVM, but it was an interesting exercise. This work can be found in my GitHub here. You must configure with –enable-text-console for this tree to work as it skips some GUI initialization that way.