Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I think the question reveals a bit of misunderstanding of how game engines should be designed. Which is perfectly ok, because they are damn complex things that are difficult to get right ;)</p> <p>You are under the correct impression that you want what is called Frame Rate Independence. But this does not only refer to Rendering Frames.</p> <p>A Frame in single threaded game engines is commonly referred to as a Tick. Every Tick you process input, process game logic, and render a frame based off of the results of the processing.</p> <p>What you want to do is be able to process your game logic at any FPS (Frames Per Second) and have a deterministic result.</p> <p>This becomes a problem in the following case:</p> <p>Check input: - Input is key: 'W' which means we move the player character forward 10 units:</p> <blockquote> <p>playerPosition += 10;</p> </blockquote> <p>Now since you are doing this every frame, if you are running at 30 FPS you will move 300 units per second.</p> <p>But if you are instead running at 10 FPS, you will only move 100 units per second. And thus your game logic is <em>not</em> Frame Rate Independent.</p> <p>Happily, to solve this problem and make your game play logic Frame Rate Independent is a rather simple task.</p> <p>First, you need a timer which will count the time each frame takes to render. This number in terms of seconds (so 0.001 seconds to complete a Tick) is then multiplied by what ever it is that you want to be Frame Rate Independent. So in this case:</p> <p>When holding 'W'</p> <blockquote> <p>playerPosition += 10 * frameTimeDelta;</p> </blockquote> <p><em>(Delta is a fancy word for "Change In Something")</em></p> <p>So your player will move some fraction of 10 in a single Tick, and after a full second of Ticks, you will have moved the full 10 units.</p> <p>However, this will fall down when it comes to properties where the rate of change also changes over time, for example an accelerating vehicle. This can be resolved by using a more advanced integrator, such as "Verlet".</p> <h2><strong>Multithreaded Approach</strong></h2> <p>If you are still interested in an answer to your question (since I didn't answer it but presented an alternative), here it is. Separating Game Logic and Rendering into different threads. It has it's draw backs though. Enough so that the vast majority of Game Engines remain single threaded.</p> <p>That's not to say there is only ever one thread running in so called single threaded engines. But all significant tasks are usually in one central thread. Some things like Collision Detection may be multithreaded, but generally the Collision phase of a Tick blocks until all the threads have returned, and the engine is back to a single thread of execution.</p> <p>Multithreading presents a whole, very large class of issues, even some performance ones since everything, even containers, must be thread safe. And Game Engines are very complex programs to begin with, so it is rarely worth the added complication of multithreading them.</p> <h2><strong>Fixed Time Step Approach</strong></h2> <p>Lastly, as another commenter noted, having a Fixed size time step, and controlling how often you "step" the game logic can also be a very effective way of handling this with many benefits.</p> <p>Linked here for completeness, but the other commenter also links to it: <a href="http://gafferongames.com/game-physics/fix-your-timestep/" rel="noreferrer">Fix Your Time Step</a></p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload