30
Frame based simulations will experience errors when updates fail to compensate for non-linear rates of change.
For example consider an object starting with position and velocity values of zero experiencing a constant acceleration of one.
If we apply this update logic:
velocity += acceleration * elapsedTime
position += velocity * elapsedTime
We can expect ...
21
You're moving the circle by one pixel per frame. It should not come as a big surprise that, if your rendering loop runs at 30 FPS, your circle will move 30 at pixels per second.
You basically have three possible ways to deal with this issue:
Just pick one frame rate and stick to it. That's what a lot of old-school games did — they'd run at a fixed ...
16
If your frame time is unpredictable (whether or not this is your fault; the OS may be using resources occasionally, etc), capping to a predictable frame rate that is somewhat lower than your achievable framerate will do a lot for predictable latency, which can make the game feel a lot better.
Changing how long between when you process input and render ...
13
Delete the Thread.sleep() call (assuming you're on a desktop machine and have power to spare!).
In general you never sleep in your game loop (except on Android, where there appears to be no other choice). The bad thing about Thread.sleep is it is unpredictable and may cause your game to give up exec time for longer than 16ms, which is the maximum time a ...
12
You will end up using a lot less CPU (multi taskers will thank you) and people on mobile devices will appreciate this, too.
10
You should never, ever, ever, ever, ever use Sleep to control framerate.
This has been gone over before and I'll refer you to the other question for discussion of the reasons why. One thing not mentioned there is that at the typical modern refresh rate of 60Hz, and with the typical 1 millisecond granularity of Sleep calls, it's actually impossible to Sleep ...
10
This looks like you could solve it with a priority queue or min-heap. The code to process the queue would look something like this:
while(eventQueue.Count > 0 && eventQueue.Peek().executionTime <= Time.time) {
eventQueue.Dequeue().action();
}
This means you have only one check to do on frames when no events happen - you don't have to scan ...
9
If you read the pygame.time.Clock.tick() and pygame.time.Clock.get_fps() documents, you'll find that:
tick() works with milliseconds - it returns the number of milliseconds since the last call
get_fps() returns an average of the last 10 calls to tick(). If you do the math, that's pretty damn good that you're getting 59.8 most of the time, since with 60 FPS ...
9
Yes it's possible, but it's not without its complications.
While frame interpolation can work real-time on videos, that isn't necessarily the case with video games. Even though this is processing real-time on videos, the software is able to "look ahead" to the next frame. This is a pretty critical component of interpolation. This is where the issue comes ...
8
This is probably due to the Garbage Collection kicking in every x seconds. In general, you should minimize (or even eliminate) creating "garbage" in an XNA game. Examples of things that could create garbage during the game loop:
Calling anonymous methods or closures.
Setting/clearing delegates or event handlers.
Using an enum as a key in a dictionary. ...
7
var ms = 17 // this frame's step
var step = (1/60) * 1000 // this is your desired step
var dt = ((ms / step)|0)*step // calculate number of 'steps' in ms, truncate it to an int, multiply by step
This will fix a timestep to a multiple of 1/60. If you wanted an integer dt, just truncate again using dt|0.
I'd advise against this, though. I would either find a ...
7
To measure framerate you need two counts:
How many frames (not draw calls) have passed, and,
How much time has passed.
Your framerate is therefore calculated as:
frames / time
There are a few subtle complexities to this.
First thing is that you need a good, accurate, high resolution timer. You don't say what platform you're on so I'm not going to make ...
7
Your code is currently running each time a frame renders. If the frame rate is higher or lower than your specified frame rate, your results would change as the updates don't have the same timing.
To solve this, you should refer to Delta Timing.
The purpose of Delta Timing is to eliminate the effects of lag on computers that try to handle complex graphics ...
7
I think render to texture is still your best bet. If you took a "screenshot" of what the camera sees and just display that texture the rendering cost should be cheap even at 30fps.
6
The oscillation is a common thing. Likely from CPU scheduling and other processes on the system.
The first frame being very long is an error in your code. Consider what lastFrame is set to when the application starts (likely 0), so for the first frame you're just setting deltaTime to the time/1000. You can add a check that if lastFrame is 0, the deltaTime ...
6
If you know in your Update method that you don't need or want to render anything simply call SupressDraw() on your game object (http://msdn.microsoft.com/en-us/library/microsoft.xna.framework.game.suppressdraw.aspx). You don't need to add any additional logic into your Draw method to handle this, and your frame skipping logic can be moved into your Update ...
6
The lowest framerate you can get away with depends on the game.
In chess, a still image is just fine until someone makes a move! In a fast-paced FPS, you'll typically want >30 frames per second.
This comparison of an animation at 15, 30 and 60 frames/second should give you a rough idea, but it's best just to try it out -- every game is different.
6
The general solution to this problem is to have an update function with a completely fixed timestep. Unity calls this FixedUpdate, in physics engines you can run the simulation several times before updating the world, etc. but it's all the same concept.
While this fixed update function will always be slightly out of sync with everything else in your world, ...
6
You can't reliably control the FPS with functions like SDL_Delay, they call the operating sleep function, which tells the operating system "Please don't give me any CPU time for at least N miliseconds", the operating system is then free to decide:
At what granularity (i.e., as you said you specify 1ms and it waits for 15ms, it has a granularity of 15ms) it ...
6
A system along these lines has been used in The Force Unleashed. I'm not aware of other titles that have used it though.
6
It depends on where you're calling your step from. If you're calling it from Update, your movement will indeed be framerate independent if you scale with Time.deltaTime, but if you're calling it from FixedUpdate, you need to scale with Time.fixedDeltaTime. I figure you're calling your step from FixedUpdate, but scaling with Time.deltaTime, which would result ...
6
The most consistent way to do this is to use a fixed time step for your game logic. This avoids game logic oddities due to rounding errors when frame rate changes (collisions or events that don't happen or happen too often).
Fixed Step:
A typical fixed step loop would look like:
Uint32 time_step_ms = 1000 / fps_the_game_was_designed_for;
Uint32 ...
5
Should you cap the framerate: Yes
Is a high CPU usage unwanted: Yes
Or even dangerous!: Could be but if so not your problem
You want to cap the framerate because you are extremely unlikely to achieve any benefit (to your game) by calculating at a frequency higher than your ability to display the results. ie, if your monitor can only display at 60Hz then ...
5
There is literally no good option other than testing on a range of target hardware.
Simply testing on slower hardware isn't enough. Older cards are often on different driver series, meaning that they support a lower version of Direct3D or OpenGL.
Cards of similar speeds but from different manufacturers will have different behavior. The behavior can differ ...
5
That's because you limit your frame rate, but you only do one update per frame. So let's assume the game runs at the target 60 fps, you get 60 logic updates per second. If the frame rate drops to 15 fps, you'd only have 15 logic updates per second.
Instead, try accumulating the frame time passed so far and then update your game logic once for every given ...
5
I don't see why you couldn't use it! Keep in mind that you may have to code differently to account for the differences between fixed/variable timestep, so if you're planning on making it fixed when you release, you'll need to make adjustments. See this article: http://rbwhitaker.wikidot.com/time-steps
Is this a good indication that my code is ...
5
I'll usually use System.Diagnostics.Stopwatch for this.
IEnumerator AsyncWorkCoroutine(float millisecondBudget) {
var watch = new System.Diagnostics.Stopwatch();
bool workComplete = false;
long tickBudget = (long)(System.Diagnostics.Stopwatch.Frequency
* millisecondBudget/1000f);
while(workComplete == false) {
...
Only top voted, non community-wiki answers of a minimum length are eligible
