General ? about speed (timing)...
Author
Hi there... :)
Well, I just started to read some of NeHe's tuts and played around
with the sources (in C++ and MASM) - everything works like a charm.
Then I started to write my own test-app (in MASM) - still worked
like a charm... but OH NOES !?!
I ran it on another pc and had to realise that the speed of the
GL-movements is different on every pc... :O
I tried 5 other samples (not modified by me) from the tutorials on
other pcs, but they all show different speed !
For example #21 (Grid Crazy) or #9 (Moving bitmap in 3D-Space):
I've got XP(SP2), Core2Duo, Geforce 7600 (and I thought that the samples
run at a speed as they should do).
Another pc has XP(SP2), 2,6GHz, older ATI (much slower than mine): But the
speed of the samples is 2-3 times FASTER (TOO FAST... definitively!).
While I could play "Grid Crazy" or watch a spinning 3D-Cube at "human"
speed on my pc, everything moves fast like hell on 2 other (lamer) pcs ?!?
Didn't anybody have problems with this ?
Sry, if there has already been a topic about this, but
I did some research...
Thanks... :)
totally unrelated to opengl, timing is OS related in general. (SDL has some platform independant timing functions).
Author
Quote:Original post by SimonForsmantotally unrelated to opengl...Huh, how is that ?
I mean... I'm running the OpenGL-Samples by NeHe.
It's just confusing, that for example "Grid Crazy" isn't playable
on SLOWER machines, because you and your enemies are moving far too FAST... :/
EDIT/
Forgot to mention, that on every pc the tested samples run at 1-2% CPU Usage !
So where's the logic ???
Quote:Original post by ShamusQuote:Original post by SimonForsmantotally unrelated to opengl...Huh, how is that ?
I mean... I'm running the OpenGL-Samples by NeHe.
It's just confusing, that for example "Grid Crazy" isn't playable
on SLOWER machines, because you and your enemies are moving far too FAST... :/
well thats a problem with NeHes code really. (NeHe has its own forum)
most likely you can solve it on the machines that run it too fast by activating v-sync. With v-sync activated a normal windows machine will run the application at 60fps, without v-sync it will run it as fast as it can. (most of NeHe:s tutorials should be able to run at 800-1500fps without v-sync even on relativly old hardware)
however a proper solution would be to implement a proper timer. (so that the framerate doesn't impact the game/simulation speed.)
Author
Quote:Original post by SimonForsman(NeHe has its own forum)Sry, I saw it too late...
Quote:Original post by SimonForsmanhowever a proper solution would be to implement a proper timer. (so that the framerate doesn't impact the game/simulation speed.)Are there other beginner-tuts with stable speed, e.g. handling with a proper timer ? :)
www.gametutorials.com probably has some (as they focus on games, not graphics)
There are also some articles here on gamedev that deal with timers.
http://www.gamedev.net/reference/articles/article753.asp for example.
it shouldn't be too hard to modify NeHes little gridgame to use timebased movement instead of framebased.
for windows you could use the timeGetTime function to get the number of milliseconds since the OS started.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/multimed/htm/_win32_timegettime.asp
if you use SDL you can use SDL_GetTicks (or something similar) (not that high resolution, but its good enough for games)
There are also some articles here on gamedev that deal with timers.
http://www.gamedev.net/reference/articles/article753.asp for example.
it shouldn't be too hard to modify NeHes little gridgame to use timebased movement instead of framebased.
for windows you could use the timeGetTime function to get the number of milliseconds since the OS started.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/multimed/htm/_win32_timegettime.asp
if you use SDL you can use SDL_GetTicks (or something similar) (not that high resolution, but its good enough for games)
basically what you want to do is:
long ctime = SDL_GetTicks();
while(!done) { //main loop
long oldtime = ctime;
ctime = SDL_GetTicks();
long dt = ctime-oldtime; //time since last frame:
//then whenever you move an object
//instead of doing
//someObject.x += 0.5f;
//you do
someObject.x +=5.0f*dt*0.001f; //thus it will move 5.0 units / second
//code to render all objects
}
you can make it more robust by using fixed timesteps aswell, and ofcourse you can use another timer.
long ctime = SDL_GetTicks();
while(!done) { //main loop
long oldtime = ctime;
ctime = SDL_GetTicks();
long dt = ctime-oldtime; //time since last frame:
//then whenever you move an object
//instead of doing
//someObject.x += 0.5f;
//you do
someObject.x +=5.0f*dt*0.001f; //thus it will move 5.0 units / second
//code to render all objects
}
you can make it more robust by using fixed timesteps aswell, and ofcourse you can use another timer.
Author
Everything went quite solid now.
After implementing a tick_counter I still had
some flickering, but I forgot to push up
the Priority_Level. Now it works like a charm !
Big thx again !!!
After implementing a tick_counter I still had
some flickering, but I forgot to push up
the Priority_Level. Now it works like a charm !
Big thx again !!!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
