I dove head first into trying to get the timers working today, but unfortunately I haven't quite gotten it yet. I never realized decoupling the physics and display updates could be such a touchy subject, but it makes quite a bit of sense now that I've read over a few articles on it about 100 times. The idea is that if the animation updates are tied directly to the display updates, than the 'world' time of the game is different on every machine, and every time it is executed on each machine. The reason for this is display updates are not constant. Even with simple primitives a game could run between 50-60 fps inconsistently. What happens when the objects updates aren't decoupled from the frame updates is every change in fps results in a change in the speed at which the animation updates. Even if an object is moving on a straight line at a constant speed, the drops in framerate will result in a 'slower' (to the eye) object.
What's involved in the process of separating the two is integrating over a specific delta time based on the last time the frame was drawn. Since there are differences between the draw calls each update, the world needs to be updated in different time spans. For example, if draw call 1 takes place at time 5, and draw call 2 takes place at time 10, dt = 5. Now, let's say our physics timestep is 0.5; that means 10 calls need to be made to the world updater in between those two calls. Now, if draw call 3 takes place at time 13, dt = 3 and the physics updater only needs to make 6 calls.
Unfortunately I don't have my head wrapped around the integration used for the update yet. Euler's integration was the method that I thought would work for what I needed, but according to what I've read the integration over the velocity is only accurate with a constant acceleration. I do not have a constant acceleration at all (it changes every frame update), so that leaves me in the boat of implementing what the author of this article suggests, the RK4, or Runge Kutta order 4 integrator. Unfortunately for me, despite the foresight of getting my Bachelor's in Math as well as Comp Sci, I never took differential equations. It turns out the differential equations is one of the most important concepts for those of us interested in 'real-world' simulations. Who knew? So, even though the code for the integration is simple, I don't get it. I mean, I get that it's an integration of my force function that goes to the 4th derivative to get an accuracy good enough for my needs, but I don't necessarily get how. If I don't get how something works at its deepest iterative level, it just doesn't click in code. Though, I understand more about differential equations now than I did 4 hours ago (none?), so I think I'll get the kinks worked out eventually.
Today's big hit is the first working texture! Even though it isn't an actual game texture (that is, it's simply a white box with a black border over my ship) it is a working texture that didn't break the whole game. Which is great, considering last night it was a non-working texture that did break the whole game. OpenGL needs lighting for textures, otherwise the world gets very dark; news to me. But from here I can start to get some better place holder art in for my buttons and the objects onscreen, and finally start work on the menu (tomorrow's first project, I promise). I think that is it for today, so bask in the glory of my textured game:
No comments:
Post a Comment