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 ...
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
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 ...
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
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 ...
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 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
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
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) {
...
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
You can fix this problem by averaging the initial and final velocity:
velocityOld = velocityX
velocityX += acceleration * delta;
posX += (velocityX + velocityOld)/2 * delta;
In this particular example it will completely remove dependancy on delta. In general this solution will reduce the effect of delta.
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 ...
4
requestAnimationFrame implementation depends on browser solely. Browser will try to reduce framing if it "believes" that it will be better for user, and usually does it "smoothly" from 60 to 30. But that shift is obviously easy to see. As well once it is some time in 30fps state, it then usually shifts back to 60. The problem here is that this shifting is ...
4
First, your timeElapsed absolutely should not be fixed. Measure the actual frame time. Plenty of articles on it. Even with things like a setFramerateLimit call, the game loop might not run at that exact time every frame.
#define FRAME_DURATION (1.0f / FPS_LIMIT)
#define RUNNING_SPEED 42 * FRAME_DURATION
#define GRAVITY 42 * FRAME_DURATION
This part ...
4
As usual with performance questions, the answer is "it depends."
We certainly wouldn't expect a moving object to be cheaper than a stationary one, so in most cases it's a safe bet that idle FPS will be at least as good as moving FPS.
So, what might make moving FPS lower?
Physics calculations. In most physics engines, objects that aren't
moving are put to "...
4
I see one huge mistake here not handled by any of the answers. Of course you should never draw and iterate over more tiles then you need too. What's less obviously is how you actually define the tiles. As i can see you made a tile class, i always used to do that too but it's a huge mistake. You probably have all sorts of functions in that class and that ...
Only top voted, non community-wiki answers of a minimum length are eligible
