Soulfu camera bug

The current project that I spend time on when I feel like games programming is Soulfu. The code as released by its author was written to demonstrate his ability to implement all parts of a game engine. The community took it, cleaned it up and eventually lost the time and energy to continue. Because of this, while the code is now cleaner, it has bugs which were not present in the original game and the source code for it.

I've been fixing up the bugs as I get the time and interest. The one I was looking into today was to do with camera direction on room transitions.

Leaving the village to the castle foyer:


Entering the castle foyer from the village:


Leaving the castle foyer to the dining hall:


Entering the dining hall from the castle foyer:


There are two room transitions here. The first is from the village to the castle foyer, where the movement is generally aligned with the Y axis and camera. The second is from the castle foyer to the dining hall, where the movement is generally aligned with the X axis and is perpendicular to the camera.

What the screenshots show is that the first transition (and any that have the same camera/movement alignment) gives a reversed camera direction. This means that if the player were to keep the movement key depressed, the movement direction will also be reversed and the character will move back out of the door they just entered. This is awkward, wrong and does not match the correct behaviour that is exhibited on the second transition.

The camera direction is calculated within the custom scripting language that Soulfu's author created.

SystemGet(SYS_CAMERASPIN, 0, 0) - new_spin + (old_spin+32768)

After checking a lot of other things, I gave up and ignoring this equation wrote my own.

SystemGet(SYS_CAMERASPIN, 0, 0) + (old_spin - new_spin) + 32768

Now the camera works correctly. Mathematical equations and that programming languages work in the same way, implies that the two equations should be equivalent. The script where this calculation is made has not changed, so the cause of the bug must have been the community cleanup and their changes to the custom scripting system's compiler.

Ideally I'd like to tear out the custom scripting system and replace it with anything else that is popular enough to be stable and able to be treated like a black box. While the game is still riddled with enough bugs that exactly what and how many are present is unknown, they would get in the way of the process. So I'll most likely fix all the bugs, verify the game is restored to its original stable state and then reconsider. Surprisingly, it is easier to debug this scripting language from C and the code running within it, than it is to debug Python when using it in the same way.