Tag Info

Hot answers tagged

94

There are two issues related to the question. Should physics step rate be tied to frame rate? Should physics be stepped with constant deltas? In Glen fielder's Fix your time step he says to "Free the Physics". That means your physics update rate should not be tied to your frame rate. For example, if the display framerate is 50fps and the ...


46

Are you looping through all 500,000 tiles when you're rendering? If so, that's likely going to cause part of your problems. If you loop through half a million tiles when rendering, and half a million tiles when performing the 'update' ticks on them, then you're looping though a million tiles each frame. Obviously, there's ways around this. You could ...


39

I think there are really 3 options, but you're listing them as only 2: Option 1 Do nothing. Attempt to update and render at a certain interval, e.g. 60 times per second. If it falls behind, let it and don't worry. The games will slow down into jerky slow motion if the CPU can't keep up with your game. This option won't work at all for real-time multi-user ...


38

"Frame rate" and "FPS" (frames per second) are usually the same thing. A "frame" is usually a single image in the series of images presented to your screen rapidly so as to give the illusion of motion in your game, and so the terms generally refer to how many of those images your game can simulate and produce within one second. FPS is often used as a crude ...


19

I really like the way the XNA Framework implements fixed time step. If a given draw call takes a bit too long, it will call update repeatedly until it "catches up". Shawn Hargreaves describes it here: http://blogs.msdn.com/b/shawnhar/archive/2007/11/23/game-timing-in-xna-game-studio-2-0.aspx In 2.0, the Draw behavior has changed: Call Update as ...


19

Sounds like you're looking to learn about Trees! And I'm being serious, if you're currently looping over an array of all your cubes, then you really should look into various spatial data structures. For this case, the best way to re-imagine your cube world is as a tree. Before we go into the reasons as to why, lets think about our problem. We're looking ...


14

One of the most important skills to learn as a programmer is how to locate and fix performance problems. The good news is that this process is easier today than it has ever been in the past. As mentioned in the comments, a frame rate stutter of 0.5 seconds is completely unacceptable for any game which demands reflexes from the player, so this is a great ...


14

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

What you should do: Lock game logic to a fixed framerate Render graphics as fast as possible That way, if the framerate drops you don't get input lag (I'm looking at you, Just Cause 2), and if the framerate becomes too high (think games from the 90's) the game doesn't become unplayable. Here's how I do it: s_PhysicsCurrent = GetTickCount(); float delta ...


13

No, frame rate should not affect the speed - the gameplay will hinge entirely on their video performance, which is disastrous (even if you limit the speed, you can't control people whose systems will run the game at half speed). You're experiencing this problem because you did something wrong: Your update/render routines run one after the other as fast as ...


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

I agree with Daniels answer, in that iterating through large amounts of boxes is the most likely cause, and that by using spacial partitioning you could speed the game up a lot - but the problem could also be elsewhere, and you could be wasting your time. In order to increase the speed of your game significantly you need to profile your code. Identify where ...


12

The movement of your ball varies from platform to platform because you're not using the delta-time at all for your movement calculation. First of all you should convert your ticks to seconds in your update loop and then call the Move functions with the delta-time in seconds.. otherwise you'll have to convert to seconds in every Move function. All your ...


11

If you're running in full-screen mode, you can use the pygame.HWSURFACE flag when you initialise the display to tell pygame to try to use a hardware surface. I believe that if a hardware surface can't be used, pygame will silently use a software surface. If you're not using a hardware surface, consider using pygame.display.update(rectangle) rather than ...


11

It may be more useful to create a diagram showing frames per second over a period of time. Ideally this diagram contains annotations about what happened in the world, for example changes of areas, starting and ending of fights. In the sample diagram it is easy to see that the frame rate is a lot better in the home town than in the dungeon. And there seems ...


11

You will end up using a lot less CPU (multi taskers will thank you) and people on mobile devices will appreciate this, too.


10

This is subjective, of course, but I think that consistency is much more important to game play than speed. Basically, players will put up with a slower frame-rate if the game is consistent, fun to play and not jarring. However, even if the game totally rocks, if it gives people headaches to look at because it bursts, and/or they can't control things, they ...


10

The best way to make your game run the same speed on all systems is to use a Fixed Timestep. With a fixed timestep, the game will always update at the same rate, no matter what the render rate is, and when using interpolation, it will look smooth even when the render rate is much higher than the update rate. Here is an answer with resources on how to ...


10

if Game.IsFixedTimeStep is true the update method will be called every 1/60 seconds http://msdn.microsoft.com/en-us/library/microsoft.xna.framework.game.isfixedtimestep.aspx "The default value for IsFixedTimeStep is true."


10

I have a damage system is my game and I would really love to stay away from float damage values, both for memory and game design reasons. My first instinct is to question your assumptions. It's extremely unlikely that using floats rather than ints for something like this is going to affect your memory usage in any noticeable way. On most systems, they ...


9

Seems almost as useful as a speed limit saying "2400 km/day" or "614400 km/year". Both are the same as "100 km/hour". From the mathematical standpoint it makes no difference, but we humans have a narrow perception and we can deal much better with smaller numbers and time-frames. If you throw 216,000+ FPH at me, I had no idea how long a frame is. If ...


9

You're probably thinking of motion blur. Edit for more content: Here's a bit from GPU gems on motion blur: http://http.developer.nvidia.com/GPUGems3/gpugems3_ch27.html One of the best ways to simulate speed in a video game is to use motion blur. Motion blur can be one of the most important effects to add to games, especially racing games, because it ...


8

There's another option - decouple Game update and physics update. Trying to tailor the physics engine to the game timestep leads to problem if you fix your timestep (the problem of spinning out of control because integration needs more timesteps which take more time which needs more timesteps), or make it variable and get wonky physics. The solution that I ...


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 ...


8

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 ...


7

Personally, I use a variation of variable time-step (which is sort of a hybrid of fixed and variable I think). I stress tested this timing system in several ways, and I find myself using it for many projects. Do I recommend it for everything? Probably not. My game loops calculate the amount of frames to update by (let's call this F), and then perform F ...


7

NOTE: All fractions are meant to be floats. Frame independent movement works by basing movement off of time. You get the amount of time that is spend since the last frame (so if there are 60 frames in one second, each frame takes 1.0/60.0 seconds, if all the frames took the same amount of time) and find out how much movement that translates into. If you ...


7

First off, you shouldn't be using GLUT for anything but testing. As far as I know, GLUT was never meant for application development. I recommend picking up SDL or SFML instead. That said, implementing framerate-independent rendering is relatively simple. // global gLastTick contains the last processed tick (ms) // game loop int tick = ...


7

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 ...


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 ...



Only top voted, non community-wiki answers of a minimum length are eligible