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 ...
15
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
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. ...
8
Delta Time is used to make your game speed constant, independently of framerate.
If your game starts to get "heavier", it will start to slow down in framerate on less powerful android systems. For example, if you made it to run on 60 FPS, an Android cellphone that can run it at 30FPS will have the game slowed down by 50%!
By including the DeltaTime in the ...
8
You'll likely be using constant acceleration. So no need to worry! The derivative of constant acceleration with respect to time is 0. That means it doesn't change with respect to time, so it doesn't matter what your frame rate is. If you were using variable acceleration you'd set up your equation like:
acc += jerk * time //only needed if your acceleration ...
8
Say you want to limit your framerate to 60fps, that means that every frame has a render time of 1/60s = 16,67ms (rounded)
To limit your frame rate you just check the time at the start of your game loop, you can then compare it with the time at the end of the game loop: if the difference is less than 16.67ms you should stall for that time.
One way to do ...
7
The theory is: Check when you last rendered a frame, and if it's not time to draw another frame yet, then don't, and wait until it is.
7
It may not be a direct answer to your question, but it is my advice ;)
Do not move your sprites based on the number of frames, but do it based on wall-clock time. Why? Oh well, it is very easy for a game to have a variable frame-rate, so, imagine your character is jumping from platform to platform, and the PC lags for some reason. If his movement is based ...
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
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 ...
7
This is called vsync (vertical sync), which traditionally means that your rendering rate is synchronized with the vertical refresh rate of your monitor to avoid tearing. Nowadays LCD screens don't have "vertical" refresh rates, just simple refresh rates, but it's the same thing.
As others have said in the responses, your video card driver settings cause ...
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
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 ...
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 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
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
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 ...
5
Not really, no.
There's one scenario: you're calling the draw method so often you don't leave yourself the resources to do anything else. That's not your FPS negatively affecting how the game runs, though. The cause would be a badly written game, engine or framework; the FPS would just be a side-effect.
You have a glitch that surfaces on your desktop. Your ...
Only top voted, non community-wiki answers of a minimum length are eligible
