0
\$\begingroup\$

When working with OpenGL or DirectX, should draw calls be done all at once, at the end of the update loop, or is it better to have draw calls occur during the update loop rather than just at the end?

\$\endgroup\$
  • 1
    \$\begingroup\$ gamedev.stackexchange.com/questions/69135/… This is not exactly the same question, but it has a good answer from which I think you will get the point. ;) \$\endgroup\$ – János Turánszki Jan 22 '14 at 14:37
  • \$\begingroup\$ I imagine draw calls would be easier, more consistent and probably more performant if you do them in a batch after the update. \$\endgroup\$ – Christian Jan 22 '14 at 14:39
  • 1
    \$\begingroup\$ This absolutely depends on your engine architecture and features. With that said the VAST majority of engines update everything, then render everything. (It might be obvious why if you think about dynamic shadows) \$\endgroup\$ – MickLH Jan 22 '14 at 15:08
4
\$\begingroup\$

You should strive to ensure your updating logic (that is, the logic of your actual game) is decoupled from your rendering logic. This is the single responsibility principle, a key tenet of good engineering design. This will make your interfaces more resilient to change and maintainable in the long run, and that should be a high priority.

That said, you can still keep to the SRP and have a system where you interleave update and render operations for your objects. At a very high-level, in pseudo-code, this might look like:

foreach(object in the game) {
  object->update();
  render_description = create_description_of(object);
  renderer->draw(render_description);
}

Now, whether or not you should do this is a different question. Certainly, if you game and its render needs are simple enough and you prefer this style for some reason, you can create a game that way. But as the complexity of a project scales, you can run into some issues:

  • Since you are performing heterogenous operations, this approach does not lend itself well to splitting across multiple threads to take advantage of the corewise-scaling that modern CPUs provide. Concurrency is the way of the future and you should design systems to at least allow for the possibility of utilizing it in the future.

  • While you are not tightly binding the update and render APIs, you are tightly binding their processing order. This can be problematic if your rendering needs are more complex, such as requiring multiple passes (where you generally would want everything rendered from pass one before you start on pass two), or simply different processing order for render objects (for example, transparent objects should be rendered after opaque ones and in depth-based order).

While you can work around the above (and the host of other smaller irritations, such as an increased difficult in keeping update and render timesteps distinct), it starts to make your code and the logical flow of your program more confusing, for a very minor potential benefit (it's possible you could achieve better CPU and GPU load balancing this way if you issue non-waiting render calls; but again, there are other solutions to that).

For this reason, most games prefer to do all their logic updates in one batch, followed by any and all rendering operations required.

\$\endgroup\$
  • 2
    \$\begingroup\$ Another important argument to decouple updating from rendering is that it is much easier to avoid your game mechanics to change depending on rendering performance. \$\endgroup\$ – Philipp Jan 22 '14 at 16:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.