gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Beginners > game loop speed / Vblank

#31644 - ThUg4LiFe - Mon Dec 13, 2004 1:48 pm

right well, i was wondering how you make a game maintain a set fps? because surely if there is a lot happening at a particular time (accumulating scores, enemies animations, health and speed calculations) the game loop would more than likely take longer than a loop where there isnt much happening (such as the player just standing still)

each game loop there would be more aspects of the game and display to update which have been brought into it when more is happening. i would assume this makes each loop take longer, and thus you would get a "slow-down" effect

i know i read that a game loop should (would?) be around one VBlank and there are 60 VBlanks to a second, but surely it would not be around one VBlank for a game (or at a time in a game) where there is less/more happening? i do not know the answer, but if the game loop time would vary because of such things, then can i find out what the longest game loop would be, and force the code to start each loop again only once that amount of time has passed.... so if a loop is finished quicker, it will wait til the set elapsed time from execution before continuing? this would prevent slow-down and such, i think :\

#31648 - identitycrisisuk - Mon Dec 13, 2004 2:29 pm

I think most games manage to keep the frame rate at 60 VBlanks a second, with a few having slowdown every now and then like Advance Guardian Heroes. They generally just let it happen if it slows down and don't try to make things move based on time. I don't know how this is dealt with for multiplayer though, I'd have thought it would be more important then.

Generally speaking, unless you're trying to do some crazy effects like masses of sprites on screen at once or 3D maybe, your game loop really should be less than a 60th of a second. If you're getting slowdown it's likely you need to optimise something. I've never seen any games that choose a lower framerate and because of the way the hardware works I'm not really sure if it would be possible.
_________________
Code:
CanIKickIt(YES_YOU_CAN);

#31653 - ThUg4LiFe - Mon Dec 13, 2004 3:03 pm

okay thanx. i think you could control it though by preventing the game running faster than a set time, because it can (for a tiny fraction of a second) freeze at the end of each game loop until a sent time from exectution has passed. say you wanted to keep each game loop to 2 Vblanks if it may run slower than 1 Vblank to a game loop, you would therefore need to freeze the game loop at the end until 2 vblanks have passed from the last freeze, so the first would take affect after 2 vblanks, the next after 4 and so on... no matter how quick the game loop was, the next will always start after 2 vblanks

i can think of other types games where this must be done or another technique, like strategy games, in which you can change the game speed


however this may be highly unnecessary and inefficient for a side-scrolling 2d action adventure, but i had to ask because i managed to think of a way for the enemy A.I. to work in my game, but because there can be up to 10 enemies at a time, for each enemy onscreen it would need to be working out a route (faster than they are moving/animating) which id limit to a check of all the surrounding directions of their current position at first (then their potential route position thereafter) and see which direction makes them closer to the player, and then store that as the next step of the route, and the check is once per game loop... but each loop would also be calculating/adjusting their health, speed, animation set and such - then also calculating/adjusting the players score and health ans such if in combat..i was thinking that when there is the maximum 10 on screen there would be a noted difference between the speed of the game (or frame per second) compared to when the player is just standing still or just walking on-screen when there isnt much happening - but i dont know, my concerns may be unfounded

Last edited by ThUg4LiFe on Mon Dec 13, 2004 3:12 pm; edited 1 time in total

#31655 - identitycrisisuk - Mon Dec 13, 2004 3:09 pm

You could do that thing waiting for 2 VBlanks but thinking about it, you would be drawing the screen twice. I've generally found that slowdown comes more from the graphics being drawn rather than the calculations done in the game loop (this may be different on GBA and it is obviously still possible to do through a huge loop or something). So if you get slowdown through the drawing of the graphics then waiting for 2 VBlanks won't really help you.

Like you said it may not even be a problem for you, probably better to try out your ideas, not ignoring optimisation completely but not worrying about it too much until some slowdown does occur.
_________________
Code:
CanIKickIt(YES_YOU_CAN);

#31663 - DiscoStew - Mon Dec 13, 2004 4:11 pm

identitycrisisuk wrote:
You could do that thing waiting for 2 VBlanks but thinking about it, you would be drawing the screen twice
In a sense you are correct because what is being drawn to the screen every other frame is exactly the same as the previous one, but if the sprite and background registers are updated every other VBlank, then it can be pulled off to show 30FPS instead of 60FPS.

Quote:
I've generally found that slowdown comes more from the graphics being drawn rather than the calculations done in the game loop
I agree with you, but only under the circumstances if you were running under a bitmap mode where you normal would have to redraw the screen. I think for tile-based modes and sprites, the hardware can manage. With sprites at least, it only has a limited number of rendering cycles to draw, and if it reaches it's limit, then it stops and goes to the next scanline.
_________________
DS - It's all about DiscoStew

#31665 - identitycrisisuk - Mon Dec 13, 2004 4:17 pm

DiscoStew wrote:
In a sense you are correct because what is being drawn to the screen every other frame is exactly the same as the previous one, but if the sprite and background registers are updated every other VBlank, then it can be pulled off to show 30FPS instead of 60FPS.


If that can be done that might be cool in some situations. I worked on a game once where we decided to drop from 60 fps to 30 as it would drop to around 30 when there were lots of particles on screen and there wasn't much we could do about it. If it's always 30 then you don't notice that it's slower.
_________________
Code:
CanIKickIt(YES_YOU_CAN);

#31668 - ThUg4LiFe - Mon Dec 13, 2004 4:47 pm

identitycrisisuk wrote:
DiscoStew wrote:
In a sense you are correct because what is being drawn to the screen every other frame is exactly the same as the previous one, but if the sprite and background registers are updated every other VBlank, then it can be pulled off to show 30FPS instead of 60FPS.


If that can be done that might be cool in some situations. I worked on a game once where we decided to drop from 60 fps to 30 as it would drop to around 30 when there were lots of particles on screen and there wasn't much we could do about it. If it's always 30 then you don't notice that it's slower.


just have to add, that your last comment is how im looking at it. you wont notice its slower - and you also wont have to make the game slower as a result - animations would just need to be done twice as fast at 30fps (instead of 60fps) all it means is you potentially cannot have as many frames in one second of animation. but for a gba 2d game i dont think this would matter too much, a maximum of 30 frames in a second is fine by me

anyway, i wont worry about it though unless a problem DOES arrise

#31708 - tepples - Tue Dec 14, 2004 1:10 am

ThUg4LiFe wrote:
however this may be highly unnecessary and inefficient for a side-scrolling 2d action adventure, but i had to ask because i managed to think of a way for the enemy A.I. to work in my game, but because there can be up to 10 enemies at a time, for each enemy onscreen it would need to be working out a route (faster than they are moving/animating)

Path finding can be slow. I'd suggest splitting the path finding operation across several frames, with the game animating in the background. Think about it: how often does a human player re-evaluate a path?

Anyway, a lot of Game Boy mono games ran at 30fps or 20fps because the original Game Boy screen couldn't keep up with fast scrolling. It's easier to get away with a slow frame rate on an LCD than on a CRT, and even the GameCube Game Boy Player manual explains this on page 8, where it explains the motion blur setting.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.