Frame Rates

Started by
14 comments, last by Dovyman 21 years ago
I got the blitting part of the sprite engine down, and I move onto animation, basically just moving from one piece of the sprite to the next every frame, but this is way too fast. Now I can use a timer to slow rendering down, but that seems kind of stupid, you''re wasting valuable processor time sitting in a timer loop while you could be processing other graphics... how do I solve this? -Paul-
Advertisement
You could for example use one thread for updating the screen (blitting, flipping or whatever..) and another one driven by a timer for updating the animation.

-Ring0
Use interpolation, or "time based" animation. This type of animation is independant of frame rate and everyone see''s the same thing.

I think there is some info on it in the articles section, but you can also check out www.angelcode.com.

¬_¬
For tile/sprite based animation interpolation isn''t the way to go. Interpolation is for 3D graphics. Tiles and Sprites have a limited number of displayable frames and there''s only so many pixels on the screen.

The better solution is to lock the frame rate. There are a couple ways of doing it.

The best way is to use two if statements to create a min and max timeframe to draw a frame. If it''s too soon, don''t draw anything. If it''s too late, don''t draw anything. Using this method you can keep processing everything else like keyboard input even though nothing is being updated to the screen. This method forces every computer to run at least your maximum frame rate so everything moves consistantly but drops frames if a PC can''t keep up. Which is no different than interpolation in 3D.

You can see how this is implemented by looking at the source code for the Gang Wars client.

The other method is using a while which halts your program until enough time has passed and then moves on. This is generally what the old school programs use. If you have nothing better to do, it''s a perfectly acceptable way of doing it. At 30FPS the player isn''t going to notice. However if the computer is running too slow, your program will drag. That''s what the double if method I use corrects.

The main reason I use the double if is because it''s an MMO and there''s constantly messages comming in that need to be handled. The game loop ends up running at thousands of iterations per second while only 30 frames are drawn to the screen which is a perfectly acceptable rate for tile/sprite based games.

Ben


IcarusIndie.com [ The Rabbit Hole | The Labyrinth | DevZone | Gang Wars | The Wall | Hosting | Tiberian Merchandise!!!! | GameShot ]

  FramesRun++;if(GetTickCount()-LastFrameRender > 30 * FramesRendered){	if(GetTickCount()-LastFrameRender < 30 * (FramesRendered+1))	{		render_frame();		lpDDSPrimary->Flip(0, NULL);	}	FramesRendered++;	//process everything else even though nothing is drawn        //like user input	if (GetTickCount()-LastFrameRender>1000)	{		FPS=FramesRun;		FramesRendered=0;		FramesRun=0;		LastFrameRender=GetTickCount();	}}  


Everything outside the first if will run as fast as possible. Everything in the first if will run at 30FPS or lower. Everything in the second if will run at exactly 30FPS or not be called.

If you allow text entry, putting it in the first if is a pretty good idea so you don''t have to use an extra timer to keep input from being read too fast if they can enter text. There''s nothing more annoying than trying to type a key and having several letters come out.

Ben


IcarusIndie.com [ The Rabbit Hole | The Labyrinth | DevZone | Gang Wars | The Wall | Hosting | Tiberian Merchandise!!!! | GameShot ]
quote:Original post by Dovyman
Now I can use a timer to slow rendering down, but that seems kind of stupid, you''re wasting valuable processor time sitting in a timer loop while you could be processing other graphics...


Yeah, a lot of people say that locking the frame rate is a poor way of controlling animation.



¬_¬
quote:Original post by KalvinB
If you don''t lock your frame rate all you end up doing is drawing the same exact frame over and over and over.


You might draw the same sprite-frame over and over, but the movement of the sprite relative to the screen might change over time. Locking frame rate is a bad idea.

Basically, it all boils down to describing things in terms of Something per second or Something per frame. They are interchangeable, assuming you know the elapsed time between frames (which you can easily find). If they are interchangeable, why cripple the framerate?

Author, "Real Time Rendering Tricks and Techniques in DirectX", "Focus on Curves and Surfaces"
Author, "Real Time Rendering Tricks and Techniques in DirectX", "Focus on Curves and Surfaces", A third book on advanced lighting and materials
"You might draw the same sprite-frame over and over, but the movement of the sprite relative to the screen might change over time. Locking frame rate is a bad idea."

Depends on the game and how you do movement. As I edited into my post, Diablo II has a locked frame rate. It wouldn''t benefit from interpolation and a variable framerate because it''s purely tile based movement. You can move those 32 pixels between tiles in 32 fps or 100000 fps and it''ll look exactly the same. By locking the frame rate they freed up the CPU to handle things like AI.

2D top down shooters like Raptor or whatever would probably use interpolation since they use non-tile based movement. They use more math and physics instead of simple addition and subtraction.

They''re not entirly interchangable. Interpolation keeps you graphics card moving while the 2 ifs give it a break if it''s not needed.

Ben


IcarusIndie.com [ The Rabbit Hole | The Labyrinth | DevZone | Gang Wars | The Wall | Hosting | Tiberian Merchandise!!!! | GameShot ]
You are correct - for some games (chess, for instance), it might not be bad to lock frame rate. There are whole classes of games where the notion of continuous framerate doesn''t make a lot of sense.

On the other hand, time based animation is not just for 3D. Asteroids is a 2D game for which locking the framerate would be a bad idea.

The original posting was fairly vague and time based animation is still the better general answer (IMHO). I have seen many postings where people need help getting used to time based animation. Once they understand that, it is trivial for them to revert to frame based movement if that makes more sense.

Author, "Real Time Rendering Tricks and Techniques in DirectX", "Focus on Curves and Surfaces"
Author, "Real Time Rendering Tricks and Techniques in DirectX", "Focus on Curves and Surfaces", A third book on advanced lighting and materials
Note that you are not REALLY locking the frame rate. locking the frame rate is when you put something like "sleep(30);" or an infinite loop in your render cycle so that it slows down everything. That is why people say locking the frame rate is a horrible idea.

¬_¬

This topic is closed to new replies.

Advertisement