Code Update
Today I have been working on re-structuring the code by adding more classes. This will help later on in the project. I also made a "Shape class" which I plan to use to instantiate many rigid bodies for the simulation. Each rigidbody has it's own shader reference and model matrix. I have been researching online about how to best handle 3D rotation along any axis. I am not 100% clear on how this will work out when I will want to have sudden rotations to the objects in any direction. I believe that by following tutorials and reading papers about rigid body simulations, this will eventually solve itself. I noted that I will need to save the orientation of each individual rigid body, and for this I will use a quaternion that represents that. Supposedly this will affect how some physics calculations are done in the code. I found an interesting powerpoint online which at least mentions this briefly which can be found here.
Something I plan to fix next is the "game loop". At the moment, there is just a while loop in which the rendering occur. I also record the deltatime since I naively followed a camera tutorial earlier. The deltatime affects how much the camera moves when pressing certain keys on the keyboard. The plan is to have more or less fixed logic timesteps. Such that all physics logic will be calculated in a class/function completely separated from the rendering. Normally, calculating the logic in games is much faster than rendering, but now that this will be a minor physics simulation I am not so sure. Anyways, if the rendering process has completed faster than a time threshold (60 frames per second) there will be some extra delay before it can render again. On the other hand if the rendering is too slow, more logic function calls will be made before rendering occurs again. The ideá is that instead of sending some deltatime to the physics code, I will instead send an integer counter variable that is incremented by 1 for each call to the physics calculation function. This counter replaces "time" which is a very bad measure if you want to have a game where the logic runs with a consistent speed. I learned this from reading a book about game programming patterns which can be found here.
Something I plan to fix next is the "game loop". At the moment, there is just a while loop in which the rendering occur. I also record the deltatime since I naively followed a camera tutorial earlier. The deltatime affects how much the camera moves when pressing certain keys on the keyboard. The plan is to have more or less fixed logic timesteps. Such that all physics logic will be calculated in a class/function completely separated from the rendering. Normally, calculating the logic in games is much faster than rendering, but now that this will be a minor physics simulation I am not so sure. Anyways, if the rendering process has completed faster than a time threshold (60 frames per second) there will be some extra delay before it can render again. On the other hand if the rendering is too slow, more logic function calls will be made before rendering occurs again. The ideá is that instead of sending some deltatime to the physics code, I will instead send an integer counter variable that is incremented by 1 for each call to the physics calculation function. This counter replaces "time" which is a very bad measure if you want to have a game where the logic runs with a consistent speed. I learned this from reading a book about game programming patterns which can be found here.
Kommentarer
Skicka en kommentar