|
Written by Stefan Hendriks
|
|
Monday, 09 July 2007 |
Ah, time management is so important. Not only in real-life but even more important in games. The problems is everybody has a different computer, different video-cards, cpu's, memory, operating systems even.
So, you need to figure out some constant time, ticks, to rely on.
Luckily this problem has been tackled before, so let me briefly explain how this is done...
At first you need to think of 'what do i want as a constant game-tick'
, ie something i have to fall back. The most-fastest tick in the game
that is, where everything is based on. In the engine, it is 10
miliseconds.
In SDL there is a nice method called SDL_GetTicks, which will give you the miliseconds passed since you initialized SDL.
With this you can measure the time , in miliseconds, passed between frame 1 and frame 2 of the game. The time passed, can be devided by 10 to know the amount of game-ticks (1 game tick is 10 miliseconds, remember?). Ofcourse, if you have a super fast computer and the time passed is < 10 , you need to fall back on 1 game tick, or use some floating point precision for time managing (which is an overkill imo).
So, now we know the game-ticks we can build on top of that.
I have tested various settings and currently the game will run 70 to 80 FPS in windowed mode, up to 400 fps in fullscreen mode. That is in 8 bit mode. In 16 bit mode this is a lot slower. Yet, fps does not go below 50 (in windowed mode) and 120 in fullscreen mode.
Other news is that the terrain types are almost built in, meaning you can attach a BMP file to a terrain type, which will figure out all cells from your picture (with the given width/height you specify per terrain type). From there the amount of faces and varieties can be derived.
Still no internet at home, so i cannot commit the code in the SVN repository, nor show you any screenshots yet (there is not much to see on the outside though).
|
|
Last Updated ( Tuesday, 10 July 2007 )
|
