Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » Is drawing to the buffer still part of game logic?

This thread is locked; no one can reply to it. rss feed Print
Is drawing to the buffer still part of game logic?
armond
Member #8,282
January 2007

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

1 volatile int speed_counter = 0;
2 
3 void increment_speed_counter()
4 {
5 speed_counter++;
6 }
7 
8 END_OF_FUNCTION(increment_speed_counter)
9 
10 void play_the_game()
11 {
12 LOCK_VARIABLE(speed_counter);
13 LOCK_FUNCTION(increment_speed_counter);
14 
15 install_int_ex(increment_speed_counter, BPS_TO_TIMER(60));
16 
17 while (!game_over) {
18 while (speed_counter > 0) {
19 update_game_logic();
20 speed_counter--;
21 }
22 
23 update_display();
24 }
25 }

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!

kazzmir
Member #1,786
December 2001
avatar

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.

bamccaig
Member #7,536
July 2006
avatar

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?

armond
Member #8,282
January 2007

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!

tobing
Member #5,213
November 2004
avatar

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.

Tobias Dammers
Member #2,604
August 2002
avatar

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.

---
Me make music: Triofobie
---
"We need Tobias and his awesome trombone, too." - Johan Halmén

Onewing
Member #6,152
August 2005
avatar

Quote:

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.

------------
Solo-Games.org | My Tech Blog: The Digital Helm

Archon
Member #4,195
January 2004
avatar

Quote:

You obviously can't test collision detection until all objects are in their new position.

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.

Dustin Dettmer
Member #3,935
October 2003
avatar

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

armond
Member #8,282
January 2007

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

Go to: