More updates!

Timers

Timers are now up and running. Going with the KISS philosophy I've implemented them as a wrapper data class; game objects can define their own timers for whatever they need. In terms of data a timer is just a long int record of a particular time in clock ticks, which it can update by getting the "current" time from a master timer that's hooked into the kernel ("current" in quotation marks because it updates once every frame, but that's quick enough).

Timers have a simple set of functions, such as the standard Reset to sync up with the master timer and TimeElapsed functions to get the time in milliseconds from the last Reset. But from my experience the two most useful functions are the ones I've called "TimeStep" and "TimeCheck".

TimeStep returns the fraction of a second since the last reset, and then resets the timer. It's useful for things like animations or basic physics, as you can start an update function with something like

float timeDelta = my_timer.TimeStep();

, and then multiply everything by the timeDelta to get time independent movement.

TimeCheck takes in a time length in milliseconds as an argument, and returns whether or not the timer has reached this length. If it has reached the time length, it adds this time length onto the timer. It's useful for when the code wants something to happen in a specific interval: you can use code like:

while (my_timer.TimeCheck(1000)){    // do something time related}

This performs something every second. Using a while loop ensures that if for some reason there's a delay of more than a second it performs the action the appropriate number of times - although now I think about it I'll need to put some kind of check in case the time length is extremely long so this code block isn't called way too many times. Another thing for the to do list.

Keyboard Input

I wasn't sure how much to put into the input system, so I decided to apply KISS again until I see how it goes in a couple of games. Currently SDL events get farmed out to an input module, which then packs up the keyboard "key pressed" and "key released" events into signals, which in turn get passed on to the game code. Previously I've put in code to do other things like "key held down" events, but I think I might implement that on the game side for now.



Now all I have left is the audio (and some small clean up tasks too). This time round I'd like to try SDL_mixer. I haven't played around with SDL_mixer before so this could take me a couple of hours to set up - or it could take a couple of days. Once that's done I can call this library "prototype ready" and move onto the next stage.