Should I put the game logic inside the draw loop? [closed] - c

Question

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I'm making a simple game using CSFML and am wondering if I can make my code more efficient.
Right now the code looks like this inside the main function's game loop:
// game logic
for (int i = 0; i <= perf.arramount; i++)
{
UpdateBody(&body[i]);
}
// clear
sfRenderWindow_clear(window.window, window.bg);
// draw
for (int i = 0; i <= perf.arramount; i++)
{
sfRenderWindow_drawRectangleShape(window.window, body[i].rect, NULL);
}
// display
sfRenderWindow_display(window.window);
I was told to do things in the order: logic, clear, draw, display. However, would there be any issues with me putting the logic inside the draw loop like this?
// clear
sfRenderWindow_clear(window.window, window.bg);
// draw
for (int i = 0; i <= perf.arramount; i++)
{
UpdateBody(&body[i]);
sfRenderWindow_drawRectangleShape(window.window, body[i].rect, NULL);
}
// display
sfRenderWindow_display(window.window);
Would it slow down the draw calls or make the code more efficient?
I'm not sure if this specific library may be different from others, so even a general answer is appreciated.

Answer 1

How to structure your game is your design decision.
You will be the first to notice problems with it.
But here is my experience. I learned that in the game logic loop you have calculations which are definitly needed, they also tend to need information on how much time has passed. In the drawing loop you just need to visualise the result of the calculations. As soon as you are going to split into threads, the timing of the need to calculate and to visualise will change. You are likely to want to calculate more often than you draw, while you want to draw always completly (except for more advanced FPS-based level of detail rendering....).
So there are multiple aspects which might make you want to keep those two things apart.
What I did was having a calculation step (which by my design gets real time information as a parameter of elapsed seconds) and a separate drawing step. That way you can have them in one parent loop, but you are free to move them at any point AND you are protecting yourself from confusing those two steps.