high, im currently working on a top down RPG.. anyway, i was planning on locking the frame-rate at 30 or so FPS.. but just recently i have switched my drawing code to use OpenGL so now i am getting a pretty decent framerate (around 3-500 on my machine but its p4 3 gig radeon 9600)...i was thinking i should take advantage of this and use time based movement instead of frame based... this way, i could get high FPS and play the game at a normal speed.. anyway, im asking your opinions about this. is it worth the pain? my first game (a pong clone) i did time based movement, and had some undesireable results. everything appeared fine, but the enemy AI would be kind of jerky at times, also (and most disturbing), was on some machines, the enemy AI was impossibly hard... on other machines, it was extremely too easy to beat the AI... i pretty much attributed it to the TB movement, but i could be wrong. im pretty sure thats why it was happening though... since i couldnt get time based movement working properly, im a little nervous to implement it into my newer game. i mean, i was getting weird bugs in pong.. i dont want things to start popping up in my game.. but it would suck to have to lock the framrate.. (would anyone notice a diff between say 60 FPS and hundreds of FPS?).. also, i plan to add networking to the game (NO not a MMORPG!).. i want to learn winsock anyway, and i figured i would learn it and implement it into the game after i got a good feel of it by networking a more simple game (like maybe my pong..).. i only want about 2 or 4 people to connect to deathmatch / team up... also, is frame independant movement better for networked games? thanks for any advice!! [edited by - graveyard filla on May 26, 2004 3:23:44 AM]

I just finished my first game and I''d have to put a vote in for frame based movement. I made an asteroids clone and with all those asteroids and missiles flying everywhere, it''s just easier to do collision detection at set intervals. In my program, every frame I calculate all the movement and collision detection whether or not the frame was displayed. I implemented a simple frame-skipping/speed throttling algorithm using SDL''s SDL_GetTicks(). Game play is no different on slower or faster computers. All that changes is how smooth the graphics are. Sure, it''s cool when you run some 3D game or demo at 243 fps on your super-fast expensive video card, but most of those frames are not even being written to a screen with a 75hz refresh rate. It''s just a cheap thrill, not necessary for good, fun games. 60 fps provides as smooth of gameplay as you''ll ever want. It keeps the algorithms simpler... trust me. Here''s my code:

#include "SDL.h"
#define TICKS_PER_FRAME 16 // 60 fps is approx 16 ms per frame

Uint32 tick_tock = SDL_GetTicks();
Uint32 old_tick;
int time_passed;
int extra_time = 0;

while(gameover==0){
old_tick = tick_tock;
tick_tock = SDL_GetTicks();
time_passed = tick_tock - old_tick;

if(time_passed <= (TICKS_PER_FRAME - extra_time)) {
SDL_Delay(TICKS_PER_FRAME - extra_time - time_passed);
extra_time = 0;
}
else if(time_passed > (TICKS_PER_FRAME - extra_time)) {
extra_time = time_passed - TICKS_PER_FRAME + extra_time;
tick_tock = SDL_GetTicks();
goto EndOfDisplay;
}
tick_tock = SDL_GetTicks();
// Put the code to render a frame to the screen
EndOfDisplay:
// Put the code to check input and calculate the next frame
}

My complete game and source code are here:
http://www.geocities.com/steveth_45/



steveth45 = new gamecoder;

In terms of real development, I'd say: Do what fits your needs. If frame-based fits your needs best, then use that. Otherwise, use time-based.

However, for learning, I would suggest you keep trying time-based, until you get comfortable with it. The same applies to frame-based, if you're also uncomfortable with various aspects of that method. Understand both, so that when more important projects come along, you can make good design decisions. Don't just run away from time-based because it can be more difficult. It definitely has its uses, probably more than frame-based does, although that second part could be debatable. It often just depends on what type of project your working on.

Regardless, like I said, be sure to be comfortable with both. The knowledge will help you out later on.

[edited by - Agony on May 26, 2004 12:56:45 PM]

steveth45 is correct as far as single player games go. But if you ever plan to network, then having time based movement is easier to synchronize across a network connection. Also if you disable vertical sync on the video card, then you can unlock the framerate form the refresh rate. And most people with high end video cards/monitor can refresh up to 150Hz. The other advantage of time based movement is that you guaruntee that the game speed(not frame speed) will be the same, no matter what speed machine it runs on.


First make it work, then make it fast. --Brian Kernighan

The problems of this world cannot possibly be solved by skeptics or cynics whose horizons are limited by the obvious realities. We need men and women who can dream of things that never were. - John Fitzgerald Kennedy(35th US President)

Do not interrupt your enemy when he is making a mistake. - Napolean Bonaparte

Captain Jester,
I agree except that you said that an advantage of time-based movement is that you guarantee game speed will be the same regardless of the system. I have acheived that with frame based code so I don''t see how that''s an advantage.



steveth45 = new gamecoder;

while locking the frame rate works on faster systems than yours, what about slower systems, that, say, can only max at 27 fps? (when you''re locking at 30) In that case the game will run slower on that machine.

___________________
-Nicholas Anton, Owner RaptorTech
-Admin(at)Raptor85.com

Raptor,
Take a look at my code, it''s simple. The framerate is locked only so far as game logic is concerned. There is frameskipping code that skips the part of each frame where the graphics are rendered. Any Windows system capable of surfing the net and downloading my game should be able to handle the logic portion of the code at my fixed framerate of 60 fps. If you are not sure, download my source code; I use lookup tables for sine and cosine to do 2D transformations so the ship and asteroids can rotate. It''s the rendering portion of most games that take the _vast_ majority of processor time. My code example skips the rendering part of each frame when the loop falls behind where it should be. Sure, on a slow 486 the game might not look as smooth if 4 out of 5 frames are skipped, but the gameplay will go on at the _same speed_.

To clarify: There are _two_ things going on in my code. One is "speed throttling" where the game will not exceed the prescribed framerate. The other is "frame skipping" which is really just skipping the graphical rendering portion of each frame so the game will play at the same speed on slower systems.

Graveyard is working on a top down RPG, the "logic" portion of his code will probably be faster than my asteroid game. I think he could safely use a 60 fps framerate.

leia, shouldnt i send my objects Update() function the time passed since the last frame? will the general layout look something like this?

while(!done){   time_now = old_time;   old_time = SDL_GetTicks();   time_passed = old_time - time_now;   //do my game here    Some_Object.Update(time_passed);}Some_Object::Update(Uint32 time_passed);{     if(im_moving_right())        xPos = xPos + (SOME_NUMBER * time_passed);}

so is this all there is to it? and what weird things should i expect / look out for? like i said im a little nervous because of the results i had with pong, but i was also a (bigger)newbie back then.. you think i should just go for it (i want high FPS allowed!)? do you see anything wrong in my exmaple code? thanks again for all your help