I was wondering for quite sometime if I've been doing it wrong. The standard way of timing your game according to the FAQ is

but with update_game_logic() for example. I have to iterate through a List of enemies. Obviously, they all have a draw method which draws to the buffer so when I terate through the list I would also immedtiately call their draw method.

pseudocode 1

for (i = 0; i < enemy.size; i++)
{
    enemy<i>.update();
    enemy<i>.draw(); //draw to buffer
}

speed_counter--;

update_display();

then eventually, the inner while loop would exit and render everything to the screen. I did this so I wouldn't have to make another iteration such as

pseudocode 2

for (i = 0; i < enemy.size; i++)
{
    enemy<i>.update();
}

speed_counter--;

for (i = 0; i < enemy.size; i++)
{
    enemy<i>.draw();
}

update_display();

which do you think is the right way? Pseudocode1 is working just fine with me but working doesn't mean it's right, right? Thanks!

Do it the second way. Queue long rambling advice on why its better, suffice to say its better to separate logic and drawing. Or you can find out the hard way I suppose.

I'm not very experienced, but my tired mind is giving me only one explanation for the rule. Consider collision detection. You obviously can't test collision detection until all objects are in their new position. If you simply move one and draw it, move another one, draw it, etc., you could end up drawing an object and re-moving it because of collision and having to re-draw it the entire buffer. So doing game logic before drawing could theoretically eliminate redundant operations.

It's also probably more maintainable if game logic and drawing are separate. Code to draw everything is in one place so if changes are being implemented for many objects' drawing the code is all located nearby so you can easily fix them, etc... I think.

Make sense?

Hi guys! Thanks for your advices! I followed your suggestions and I'm getting the feeling that my game would actually run faster now when I test it on slower machines. Thanks!

The main point for separating logic from drawing is (imo) that you can skip frames (i.e. drawing) if drawing is slow, so you do logic twice before drawing again. On slow drawing machines of course, and dynamically when your framerate would drop otherwise.

Separating logic from drawing is the most basic thing you can do to bring structure to your spaghetti code. It is not only better for technical reasons, but also because it makes you think in a certain way that has proven to work and help you understand things more clearly.

Seconded and Thirded by me and myself.

Maybe for getting 'hurt' or for colleting items, but not for actually colliding with impassible objects - else you might have to backtrack and that'll add overhead. Then objects may backtrack onto objects that have now taken its spot.

You may want to also subdivide the operations further:

player: player_input();
all ai: object_ai_logic_and_stuff();
all objects: object_update();
all objects: check_delete();
controller: check_game_state();

etc.

I get lazy sometimes and implement more things in the drawing code (usually animation type stuff, but sometimes stuff that is really pure logic ). This is bad because you're hurting your ability to run the game on slower computers.

Hi guys! It worked! It does drop some frames(the game would lag) but then it's better than being able to display everything smoothly but slow.