• Create Account

Banner advertising on our site currently available from just \$5!

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

18 replies to this topic

### #1MrFraggs  Members   -  Reputation: 160

Like
0Likes
Like

Posted 09 July 2013 - 09:49 PM

Hey everyone, how goes it?

So i've been working on programming a game in C++/SDL2.0 ever since SDL 2.0 release candidate came out. I have spent about 2 days straight of doing nothing except trying to find and implement a game loop I thought would be best for me. Now, I don't mean best ever, I just mean deciding between fixed step and variable step, etc. Basically what I have now is a game loop that calls the Update() function about 60 times per second, while not capping the framerate. I have been thinking about also capping the frame rate to 60, but i'm not sure if that's necessary yet, as all I draw on the screen for now is a blue color. The Update() function will update all of the game logic when it starts to be implemented, while Render() draws everything. Ever since I switched back to C++ from XNA, i've been trying to basically emulate a XNA framework into C++, as that's where I found it to be the easiest.

If it matters at all, i'm planning on making a 2D tile based game. So do you guys mind taking a look at my main game loop, and telling me if I should change it over to a different setup? Here is the code to just the main game loop:

 //Event structure
SDL_Event e;

const int MS_PER_UPDATE = 1000 / UPDATES_PER_SECOND;
const int MAX_FRAMESKIP = 5;

Uint32 elapsedMS = 0;
Uint32 startTime = SDL_GetTicks();
Uint32 nextGameTick = SDL_GetTicks();
int loops;

int numFrames = 0;

while(game->IsRunning())
{
while(SDL_PollEvent(&e))
{
//Exit the game if the user hits the 'X' button on the window.
if(e.type == SDL_QUIT)
game->SetIsRunning(false);
}

//Game update, render loop
loops = 0;
while(SDL_GetTicks() > nextGameTick && loops < MAX_FRAMESKIP)
{
game->Update();
nextGameTick += MS_PER_UPDATE;
loops++;
}

//Render the current frame
game->Render();
++numFrames;

//Used to display FPS/UPS
elapsedMS = SDL_GetTicks() - startTime;
if(elapsedMS % 1000 == 0) {  //Only update once per second
game->FPS = numFrames / (elapsedMS / 1000.0);
game->UPS = numUpdates / (elapsedMS / 1000.0);
}

} // End main loop


So basically, here are my questions:

1) Is this an efficient game loop? By that I mean, will it update at about the same rate on all computers? It's designed to update the logic at 60 times per second no matter what the computer (usually), but the frame rate will change.

2) Is 60 updates per second too much? Too little?

3) How much should I look into capping the frame rate?

Let me know if you guys see anything you think I should change. I've been wracking my brain over this for 48 hours now, i'm ready to move on! Thanks guys!

### #2Ectara  Crossbones+   -  Reputation: 3093

Like
0Likes
Like

Posted 09 July 2013 - 10:20 PM

Quickly skimming over the code sample posted, I can point out one thing: If you want to set two variables to the same time value, don't call the function that returns the time twice in a row. I'm not sure if that was what you were going for, but it is possible for the two to wind up with different values. Best to copy from one to the other.

Additionally, I find it hard to picture how you would get your logic to update precisely 60 times per second on any machine without capping the framerate on machines that run it faster. Machines that can't run it fast enough, however, is tougher. Some people wisely choose to update the game state proportionately to how much time has passed, but not all types of games lend themselves to this kind of intricacy.

### #3MrFraggs  Members   -  Reputation: 160

Like
0Likes
Like

Posted 09 July 2013 - 10:43 PM

I planned on doing it based off time, I just haven't got far enough into development to get that far. My main goal now was just setting up the skeleton of the game, which started with getting the frame rate and update rate running at the right rate.  What information might you need? There isn't a whole lot more to my game right now aside from initializing SDL, and some empty functions that haven't been put to use yet. Right now, Update() just set's the title of the window to display the FPS/UPS, as I haven't gotten far enough to implement my own bitmap font.

My main goal right now is just to be able to get a steady game loop going. What would you recommend I do with it? I was using this:

The third example, modified a few variable names and added code to keep track of FPS/UPS. Let me know what I can do to help you help me!

### #4Ectara  Crossbones+   -  Reputation: 3093

Like
0Likes
Like

Posted 09 July 2013 - 11:46 PM

//Used to display FPS/UPS

elapsedMS = SDL_GetTicks() - startTime;

if(elapsedMS % 1000 == 0) {

//Only update once per second

game->FPS = numFrames / (elapsedMS / 1000.0);

game->UPS = numUpdates / (elapsedMS / 1000.0);

}

I'm curious if this part does what I think it does. Do you really mean to check to see if the time taken to update before drawing takes an even multiple of 1000ms, or am I missing something?

The most important thing is what kind of game/application will this be? This might work well for a little side-scroller, but for a bitmap editor, it is a horrible way to do things. For the most part, you absorbed the lesson, but truly, the loop's purpose determines its structure.

### #5haegarr  Crossbones+   -  Reputation: 5609

Like
2Likes
Like

Posted 10 July 2013 - 01:25 AM

IMHO the loop suffers from the following quirks:

1. It makes no sense to render although the state isn't updated, because the rendering produces exactly the same image as the rendering before. (However, it is okay if you expect game->Render() to last longer than the 1/60 seconds in the real game.)

2. The conditional (elapsedMS % 1000 == 0) becomes true in exactly 1 millisecond per second, assuming that SDL_GetTicks has a real resolution of at least 1 millisecond. It is very unlikely that this condition is hit in the way as wanted. (See also Ectara's comment above.)

3. The way you compute FPS//UPS (letting issue 2 aside) gives the average FPS//UPS since the very beginning. This means that over time the shown values become more or less stable. You probably want to show the average of the last n seconds instead (i.e. a floating time window).

Edited by haegarr, 10 July 2013 - 01:29 AM.

### #6MrFraggs  Members   -  Reputation: 160

Like
0Likes
Like

Posted 10 July 2013 - 01:28 AM

//Used to display FPS/UPS

elapsedMS = SDL_GetTicks() - startTime;

if(elapsedMS % 1000 == 0) {

//Only update once per second

game->FPS = numFrames / (elapsedMS / 1000.0);

game->UPS = numUpdates / (elapsedMS / 1000.0);

}

I'm curious if this part does what I think it does. Do you really mean to check to see if the time taken to update before drawing takes an even multiple of 1000ms, or am I missing something?

The most important thing is what kind of game/application will this be? This might work well for a little side-scroller, but for a bitmap editor, it is a horrible way to do things. For the most part, you absorbed the lesson, but truly, the loop's purpose determines its structure.

All that part does is update the FPS and UPS every second, instead of 60 times per second. No need to see the numbers change at a speed when you can't even read them! I think the only thing I need to worry about is this program running the update cycle pretty much at the same speed on all computers. I believe the point of the tutorial I followed was to do just that, and if the user's computer is slow, to shave off some frame rate instead of losing game logic. That was my ultimate goal with my game loop, so I was hoping to have someone tell me whether I actually implemented it right or not.

But yeah, the code you questioned just keeps track of the FPS/UPS and updates it once per second instead of 60, since the game updates 60 times per second. The game is going to be a tile based 2D game like I said, but if you need a visual on exactly how the gameplay might look, think of like Hotline Miami, or even Pokemon games, the way it's a big map where you can move along both x and y planes. I want to use the term top down, but loosely.

### #7Ectara  Crossbones+   -  Reputation: 3093

Like
1Likes
Like

Posted 10 July 2013 - 03:04 AM

All that part does is update the FPS and UPS every second, instead of 60 times per second.

But yeah, the code you questioned just keeps track of the FPS/UPS and updates it once per second instead of 60, since the game updates 60 times per second.

Allow me to rephrase: you are checking to see if the time taken to update before drawing is an even multiple of 1000ms. What that test does is check that the time that elapsed was 1000, 2000, 3000, etc., disallowing 999, 1001, or any other much more likely number. What I'm saying is, if that's truly the code, it's pure luck that it is updating once per second, and the frame rate is likely less stable than it appears, because the frame rate calculation only runs when the tide comes in.

I think the only thing I need to worry about is this program running the update cycle pretty much at the same speed on all computers.

I think this idea has good intentions, but it seems ultimately flawed in the direction it is being considered. One shouldn't strive to have the logic run at the same speed, no matter what the machine's configuration, and magically have the game's rendering not depend on the completion of the game's logic. The focus really should be on accepting that no machine will complete each frame near the target frame rate, and instead keep some sort of accumulator of time passed; when the time has gone over the interval between logic updates by however many frames, draw that many frames, and leave the remainder of time for the next iteration.

In layman's terms, instead of trying to scale the time spent, scale the work you do based on time elapsed. You want the world to move the same rate, even if the game runs at 15fps. Pokemon is a bad example for this; there was only one set of hardware on which it ran, so it was simply designed to run essentially as fast as possible, with very minimal timing code to keep everything synchronized as they should be, rather than trying to make it look the same on all machines. For this reason, if you play it on an emulator, by speeding up the clock rate, the game becomes unplayably fast, whereas if I start up Quake III and raise the clock rate on my processor, the game renders faster, but the world moves at the same rate.

As an anecdote, when I was testing out the physics engine I was writing at the same time that I was testing my software renderer, I was swapping back and forth between my OpenGL plugin and my software renderer plugin between tests, and was surprised to find that the world moved much faster with the software renderer, which rendered at 20fps or so, than it did using the OpenGL renderer, at 200fps. It was then that I learned how important it is to accumulate the time that passes, and update the world in fixed increments, rather than just taking however much time passed, and updating the world by that much. Not only did it cause a disparity between speeds of iterating through the game loop, but it led to problems like objects "tunneling" through each other, because at one point, the actor is on one side of the wall, but after the next update, it has gone straight through the wall, because there were no updates between the two points in time, where the actor was close to the wall and would have been stopped by the collision detection.

If anyone else has better solutions than what I've learned, I'd be interested in knowing, as well.

### #8MarekKnows.com  Members   -  Reputation: 844

Like
0Likes
Like

Posted 10 July 2013 - 10:39 AM

Have a look here for sample code of how you should be structuring your game loop:

http://gafferongames.com/game-physics/fix-your-timestep/

---
Free C++, OpenGL, and Game Development Video Tutorials @
www.MarekKnows.com
Play my free games: Ghost Toast, Zing, Jewel Thief

### #9MrFraggs  Members   -  Reputation: 160

Like
0Likes
Like

Posted 10 July 2013 - 12:02 PM

Like I said, that has nothing to do with the actual FPS/UPS calculations. The FPS/UPS variable it updates to is STRICTLY for display purposes. I added that code in after I had the rates updating at the same time as it had after I added that code. It has NOTHING to do with the actual fps/ups calculations, just the display of information that tells me how many times per second the game is updating. If I run the game, which is just a blue screen still, it updates the title of the window with that information, telling me that i'm getting about 4000-4500 FPS, and about 60-62 UPS right now. But instead of that number in the title bar changing 60 times per second, which is how many times Update() get's called per second (UPS), it checks to see if a second in time has passed, and if so, updates the title bar. Nothing more, nothing less. I can't stress that enough. It has absolutely NOTHING to do with the actual game loop.

I used Pokemon as more of an example of the display I was going for, with a kind of top down approach with a full 2D world, and not a 2D side scroller. I have no intentions of emulating Pokemon gameplay at all, but at the time, that was the first game that popped into my head to use as an example of the type of display I was looking for. I should have said, not a 2D side scroller, but a 2D tile based world.

GafferonGames' link is the only other link I used that I actually tried to implement the gameplay, but it almost seemed a little too complicated for a smaller indie title. Not only that, but I was having trouble trying to decipher the actual game loop in terms of FPS/UPS. Going for a time based Update() is my goal here, I guess i'm just implementing it wrong. I'll have to look over it again, for a third day in a row, and see if I can grasp it any better than I previously had. One question about this article though, is the integrate() function basically the Update() function i'm trying to use? Keep in mind, my game logic hasn't really been born yet, which is why I don't even pass a gameTime variable into Update(). It will eventually, but like I said, I need to get the main game loop running in a way I'm happy with and know it SHOULD run about the same on MOST systems first.

Edited by MrFraggs, 10 July 2013 - 12:19 PM.

### #10MrFraggs  Members   -  Reputation: 160

Like
0Likes
Like

Posted 10 July 2013 - 03:38 PM

So I reworked my loop, and this is what I have, but with an unexpected result:

double t = 0.0;
const double dt = 0.01;

double currentTime = SDL_GetTicks();
double accumulator = 0.0;

while(game->IsRunning())
{
while(SDL_PollEvent(&e))
{
//Exit the game if the user hits the 'X' button on the window.
if(e.type == SDL_QUIT)
game->SetIsRunning(false);
}
//Game update, render loop

double newTime = SDL_GetTicks();
double frameTime = newTime - currentTime;
if(frameTime > 0.25)
frameTime = 0.25;
currentTime = newTime;

accumulator += frameTime;

while(accumulator >= dt)
{
game->Update();
accumulator -= dt;
t += dt;
}

game->Render();

} // End main loop


Now, I know that SDL_GetTicks() only has a resolution of 1ms, so I may find a better one soon. Here is my code for calculating frames per second and updates per second:

	updateCount++;
time = SDL_GetTicks();
if(time - timeBase > 1000) {
UPS = updateCount * 1000.0 / (time - timeBase);
FPS = frameCount * 1000.0 / (time - timeBase);
timeBase = time;
updateCount = 0;
frameCount = 0;
}


timeBase, frameCount and updateCount are all initialized to zero in the constructor, and frameCount++ is located in the render function, but I didn't find it necessary to include that entire function for one line of code, which is basically in Update() as well.

Now, here is where I'm confused. the FPS is about 270, while the UPS is about 7000. This seems a little off, but I could be wrong. I haven't incorporated the time stuff into the Update() function yet, since there's nothing on the screen to worry about updating, but I will when I get this loop going correct. How does it look to you guys? Would you do anything different? Thanks!

### #11Ectara  Crossbones+   -  Reputation: 3093

Like
1Likes
Like

Posted 10 July 2013 - 05:46 PM

Have a look here for sample code of how you should be structuring your game loop:

http://gafferongames.com/game-physics/fix-your-timestep/

That's a perfect article to explain this.

Putting it simply, yes. It is using mathematical terminology.

it checks to see if a second in time has passed, and if so, updates the title bar.

What I was saying, is that the code is broken if that's what you're expecting it to do.

updateCount++;

time = SDL_GetTicks();

if(time - timeBase > 1000) {

UPS = updateCount * 1000.0 / (time - timeBase);

FPS = frameCount * 1000.0 / (time - timeBase);

timeBase = time;

updateCount = 0;

frameCount = 0;

}

While this might not be 100% related, this is a more correct way to tell if a second has passed since the last update, regardless of why you're doing it.

the FPS is about 270, while the UPS is about 7000. This seems a little off, but I could be wrong.

This is perfectly normal. While I don't quite see how the two snippets fit together, it is very obvious how in the update loop it is possible to update more than once before it finishes and the rendering begins, and this is the way it should be. If it is updating once or less before rendering, I'd start to show concern, because if the world isn't crawling along, a spike in activity from another process could easily cause the game to border on unplayable.

Edited by Ectara, 10 July 2013 - 05:47 PM.

### #12MrFraggs  Members   -  Reputation: 160

Like
1Likes
Like

Posted 10 July 2013 - 08:13 PM

Ectara, I see what you meant now, sorry if it sounded like I came off as arrogant on that one! I didn't mean to at all, I just thought that what I did wasn't really clear, since you don't have all my code in front of you, just snippets.

Thanks for the replies, I went ahead and spent a day working through the link you guys posted trying to understand it better than I did before. I found a silly mistake that caused those updates and render cycle numbers to be off. The timer's he uses is based on seconds, even though they aren't real timers. They clearly say, "hi_res_timers_in_seconds", and no matter how many times I read it, nothing clicked. I finally saw it about two or three hours ago and got it fixed. Now my Update() runs properly at about 60 times per second, or whatever I set it to!

I only have two more questions, and i'll post my current loop below. First, will this loop run the update function on most computers the same amount of times? I know if a computer can't handle it, the frame rate will drop, which is expected. But will the game logic run at the same speed even when the frames drop? I probably sound like a broken record, and for a 2D game it probably won't even be a huge problem, but if i'm going to learn something, I want to learn it right

Second, i'm not sure if this is based on my UPS calculations, or the game logic itself, but my UPS runs between 59.99xxx and 60.00xxx, where the xxx are any numbers, usually the same each time it switches. Is this really a huge problem, or can I ignore that?  It switches between the two constantly, and i'm not sure if that is going to effect my game logic. I set up a test where each update loop i have an x variable that increases by 1 each pass, so I could see how many times per second it updates. In theory, it should update by 60 each time if i'm running the update loop 60 times per second. It does a pretty good job of that, but every few seconds it will increase by 61 or so, meaning sometimes Update() will run an extra time. Will this end up being a huge problem, or is it normal and I should just ignore it?

Thanks for all the help, I really appreciate the time and effort you guys are putting in to assist!

Here's my code, I grabbed the timer function online somewhere, as I was having some trouble grasping the QueryPerformanceCounter() function.

Main Loop:

const float dt = 1.0f / 60.0f;  //60 Would be desired updates per second

float currentTime = game->Time();  //Get the current time.
float accumulator = 0.0f;

while(game->IsRunning())
{
while(SDL_PollEvent(&e))
{
//Exit the game if the user hits the 'X' button on the window.
if(e.type == SDL_QUIT)
game->SetIsRunning(false);
}

//Game update, render loop

float newTime = game->Time();
float frameTime = (newTime - currentTime); //Convert to seconds
if(frameTime > 0.25f)
frameTime = 0.25f;
currentTime = newTime;

accumulator += frameTime;

while(accumulator >= dt)
{
game->Update();
accumulator -= dt;
}

game->Render();

} // End main loop



Timer Function:

//hi res timer in seconds
float Game::Time()
{
static __int64 start = 0;
static __int64 frequency = 0;

if (start==0)
{
QueryPerformanceCounter((LARGE_INTEGER*)&start);
QueryPerformanceFrequency((LARGE_INTEGER*)&frequency);
return 0.0f;
}

__int64 counter = 0;
QueryPerformanceCounter((LARGE_INTEGER*)&counter);

return (float) ((counter - start) / float(frequency));
}



UPS/FPS Tracking:

updateCount++;
time = Time();
UPS = updateCount / (time - timeBase);
FPS = frameCount / (time - timeBase);

//Set the title each second
if(time - timeBase >= 1) {
timeBase = time;
updateCount = 0.0f;
frameCount = 0.0f;

std::stringstream strs;
strs << "FPS: "<< FPS << " UPS: " <<  UPS;
std::string temp = strs.str();
char* theTitle = (char*)temp.c_str();
//Set window title to fps
SDL_SetWindowTitle(mWindow, theTitle);
}


### #13Pink Horror  Members   -  Reputation: 1670

Like
0Likes
Like

Posted 10 July 2013 - 08:51 PM

You might want to consider a game that sleeps or waits for vsync instead of rendering as many times as possible. It's also a little better, I believe, to track performance in time, not FPS. Knowing your update is right at 60 UPS is nice - at least you know you have corrected your game loop now. Knowing it takes 12 ms on average, maybe with 18 ms spikes, is nicer. (I understand your update is nearly empty as of now, this is just an example.)

You won't get to be one of the guys here who talks about his awesome 4000 FPS game, but you might keep your CPU's fan from getting too loud.

### #14Ectara  Crossbones+   -  Reputation: 3093

Like
0Likes
Like

Posted 10 July 2013 - 09:09 PM

But will the game logic run at the same speed even when the frames drop?

Nope, it will pretty much never update at the same speed. However, this is not a bad thing, and is what is supposed to happen. This distinction may just be me being pedantic, though. A fast computer will execute the game loop in very little time, whereas a slow computer may take longer. However, the faster computer will execute the game loop more times, accumulating time until it is time to update the world. The slower computer will accumulate much more time between iterations, and perform more updates per iteration. Technically, the logic is done at different rates for each machine. The important part is that they each update the world proportionately to the amount of time that has passed in fixed time steps.

In summary:

Fast computer iterates through loop many times, slow computer iterates through loop few times.

Both of them update the world the same amount, by being based on time in discrete time steps.

For a very silly analogy, Alice and Bob are asked to get six eggs from the market, and return in one hour with exactly six eggs. Alice can make it to the market and back in 20 minutes, whereas Bob takes a full hour to go to the market and return. Alice, wanting to show off and be flashy, runs back and forth from point to point, taking two eggs in her basket at a time, and bringing them back. Bob takes his time, and grabs all six eggs, putting handfuls of two in his basket at a time, in one trip in order to make the deadline. After one hour, both return, and each are holding their six eggs.

Second, i'm not sure if this is based on my UPS calculations, or the game logic itself, but my UPS runs between 59.99xxx and 60.00xxx, where the xxx are any numbers, usually the same each time it switches. Is this really a huge problem, or can I ignore that?

The most likely cause is floating point imprecision, and can likely be safely ignored, depending on what you will use your UPS calculation to accomplish. You can likely get away with rounding or truncating for display purposes.

Edited by Ectara, 10 July 2013 - 09:11 PM.

### #15MrFraggs  Members   -  Reputation: 160

Like
2Likes
Like

Posted 10 July 2013 - 09:28 PM

You might want to consider a game that sleeps or waits for vsync instead of rendering as many times as possible. It's also a little better, I believe, to track performance in time, not FPS. Knowing your update is right at 60 UPS is nice - at least you know you have corrected your game loop now. Knowing it takes 12 ms on average, maybe with 18 ms spikes, is nicer. (I understand your update is nearly empty as of now, this is just an example.)

You won't get to be one of the guys here who talks about his awesome 4000 FPS game, but you might keep your CPU's fan from getting too loud.

Running at 4000+ FPS is definitely not a goal, just something it's doing. I'm not limiting it for now, just because I don't really have a need to aside from less cycles. Once I start adding things to the game, i'll see how they effect the FPS, and if it's capped, I won't know how it effects it unless it drops below my target. Then, when i'm confident that I won't be adding anything else that may significantly lower my FPS, I can work on capping it. My logic isn't currently based on FPS, but the amount of Update() passes per second, which I have set to 60 right now.

Also, I believe using any kind of Sleep() function when not explicitly programming multiple cores is bad. That's just what i've picked up over the years of learning, so until I get into that area if need be, I want to stay away from anything that puts the thread to sleep for now. I appreciate the suggestions though, definitely gives me things to think about!

Now, Ectara, I haven't really implemented any kind of time based logic, and I think that using a semi-fixed time step loop like this one, I read that it isn't necessary all the time. I could be way off, as I've only really spent the last few days deeply researching this. I came from XNA, which basically handled all this stuff for me. I did use ElapsedGameTime in XNA, which I think I can easily use here. That time function I used should keep track of the total time the game has been running, and if not, I can always use the less-precise SDL_GetTicks(). But say I was moving a sprite, and had something like this. This obviously wouldn't be all the logic, but I think it gets my point across:

SpritePositionX = 0

SpriteSpeed = 5

So, since I tried to get the updates to go the same amount of time (hence semi-fixed step, which is how http://gafferongames.com/game-physics/fix-your-timestep/ described it), each update if I were to move, I would do:

SpritePositionX = SpritePositionX + SpriteSpeed.

I know with game time based updating (which i'm not saying i WON'T use), since i'm trying to get Update() to run so many times per second, wouldn't it move 5 pixels each pass, which would be 60 x 5 pixels per second? I tried passing both dt and t to my Update method, and when playing around with variables increasing by 1 * some game time, I couldn't find a difference in increasing it by a static amount, like I used with SpriteSpeed, and increasing it by say, SpriteSpeed * gameTime. I understand the concept, but I can't really figure out if implementing it in my current design is necessary.

I could definitely be wrong on all of this, down to the entire game loop itself. Definitely not saying i'm right at all on anything, which is why i'm coming to you guys for help! Should I go by game time, which I think would look something like this:

Update(gameTime)

{

GetLastGameTime;

GetCurrentGameTime;

Find the difference;

Calculate logic based on difference;

}

I'm assuming based on your comments above that the game loop I have now will work well, (I hope!), so I think any changes I make come down to whether to update my logic based on time or Update() passes.

Edited by MrFraggs, 10 July 2013 - 09:30 PM.

### #16Ectara  Crossbones+   -  Reputation: 3093

Like
2Likes
Like

Posted 10 July 2013 - 10:17 PM

I know with game time based updating (which i'm not saying i WON'T use), since i'm trying to get Update() to run so many times per second, wouldn't it move 5 pixels each pass, which would be 60 x 5 pixels per second?

To do this you'd either move units_per_second / 1000 * ms_elapsed at every update, using coordinates with fractional parts, or constrain your updates per second to match your rate of movement's unit of time. The first would be used in most real-time games; even rounding or truncating to integer co-ordinates for calculations works in some applications. The second would be used in more controlled environments; revisiting the Pokemon analogy, the game simply ran as fast as it could, and the amount to move per update is largely decided based on how many times it could update per second, with the load placed on it.

### #17MrFraggs  Members   -  Reputation: 160

Like
1Likes
Like

Posted 10 July 2013 - 10:58 PM

Alright i'll have to try both options out and see how they work, preferably across multiple pieces of hardware. Thanks for all the help, especially Ectara! It's hard to believe some random guy across the interwebs appreciating much, but believe me, I do

### #18Ectara  Crossbones+   -  Reputation: 3093

Like
0Likes
Like

Posted 10 July 2013 - 11:20 PM

Alright i'll have to try both options out and see how they work, preferably across multiple pieces of hardware. Thanks for all the help, especially Ectara! It's hard to believe some random guy across the interwebs appreciating much, but believe me, I do

It's what makes it all worthwhile.

### #19Pink Horror  Members   -  Reputation: 1670

Like
0Likes
Like

Posted 16 July 2013 - 06:47 PM

Running at 4000+ FPS is definitely not a goal, just something it's doing. I'm not limiting it for now, just because I don't really have a need to aside from less cycles. Once I start adding things to the game, i'll see how they effect the FPS, and if it's capped, I won't know how it effects it unless it drops below my target. Then, when i'm confident that I won't be adding anything else that may significantly lower my FPS, I can work on capping it. My logic isn't currently based on FPS, but the amount of Update() passes per second, which I have set to 60 right now.

Also, I believe using any kind of Sleep() function when not explicitly programming multiple cores is bad. That's just what i've picked up over the years of learning, so until I get into that area if need be, I want to stay away from anything that puts the thread to sleep for now. I appreciate the suggestions though, definitely gives me things to think about!

Sleeping without multiple cores is bad? How'd you pick that up? Sleep is good! Sleep means other programs can run. If you only have one core, you need sleeping or waiting of some kind even more than the multicore system. People don't just run one executable at a time these days. There are all sorts of background tasks that need that CPU. Good programs don't hog the CPU.

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

PARTNERS