Rewrite the project in modern C++

[mxlgv]

Many things converted from Java look extremely strange. The resulting code, to put it mildly, does not correspond to modern C ++. Maybe it's worth rewriting while maintaining compatibility with level files?

[AntonEvmenenko]

Hi @turbocat2001,

Well, this is definitely a great idea.

However, undoubtedly, it's a very large and complex task. I'm afraid that if we approach it directly, without prior preparation and without breaking it down into parts, two problems might arise:

1. We might burn out without completing the implementation.
2. We could break or alter the game's behavior (e.g., breaking or affecting the physics).

So, if you're interested in my humble opinion, I would attempt to approach this task roughly in the following order:

1. Unit tests: the current C++ code closely resembles the original Java code, which provides us with some confidence that the game behaves similarly to the original one. I think the behavior of the physics should be our main concern. However, if we start making changes, without unit tests, it will be quite challenging to determine whether the game's (physics) behavior is changing or not.
2. memory leak(s) caused by improper handling of dynamically allocated memory #11
3. Naming issue: if you check the code, you'll find many variables with names like field_44, var5, etc. I believe we should replace all these names with the meaningful ones.
4. Fixed-point math handling: currently, fixed-point math is used for physics. While this is a good approach, there is an issue associated with the fact that it's applied in a rather straightforward manner, which greatly hampers code readability and understandability. I think it would be great to use a library for this purpose instead, like this one
5. ...
6. Rewrite the project in modern C++ #14

[AntonEvmenenko]

Unit tests: the current C++ code closely resembles the original Java code, which provides us with some confidence that the game behaves similarly to the original one. I think the behavior of the physics should be our main concern. However, if we start making changes, without unit tests, it will be quite challenging to determine whether the game's (physics) behavior is changing or not.

Another thought regarding testing: In our case, unit testing might not be the best option because we have a huge amount of decompiled code. Many functions have names like method_27, and it's often difficult to understand what they do, let alone writing tests to cover all the necessary cases.

Perhaps, in our case, something like higher-level functional testing would be more suitable. I'll try to explain what I mean by that below.

Let's remember the goal: we need a way to determine if the game (physics) behaves the same way after we make changes to the code.

I propose an approach where we write a separate program that simulates a player. This program will launch the game and perform a fixed and always identical set of actions, after which it will verify that the game is in the correct state. Specifically, I envision it like this:

1. The testing program launches the game
2. The testing program starts a specific level, for example, the first one, "Intro"
3. The testing program sends a sequence of button presses to the game. This sequence should follow these rules:
   a. It's the same for each test
   b. It includes ALL control keys (acceleration, brake, leans, etc., depending on the chosen control scheme)
   c. It leads to the motorcycle eventually crossing the finish line
4. The testing program records the time (local game time, the one that is displayed by the game when finishing the level; we should NOT use the operating system time here) taken to complete the level. If this time matches the reference time, everything is fine. If not, our changes have broken something