One if condition is wrecking my game loop
Doctor Cop

I try different things in my game loop to test them while I was trying to optimize my previous loop something happened.

1 while(main_loop) 2 { 3 ALLEGRO_EVENT event; 4 5 //if(al_is_event_queue_empty(queue)) 6 al_wait_for_event(queue, &event); 7 8 if(event.type == ALLEGRO_EVENT_DISPLAY_CLOSE) 9 main_loop = false; 10 11 if(event.type == ALLEGRO_EVENT_TIMER) 12 { 13 al_clear_to_color(al_map_rgb(255, 255, 255)); 14 15 al_draw_rounded_rectangle(400-100 + x, 300-20, 400+100 + x, 300+20, 20, 20, al_map_rgb(70, 60 , 100), 2); 16 17 if(y) 18 { 19 if(x>=-400) 20 x+=-5; 21 else 22 y = 0; 23 } 24 if(!y) 25 { 26 if(x<=400) 27 x+=5; 28 else 29 y = 1; 30 } 31 32 al_flip_display(); 33 al_rest(0.02); 34 } 35 36 if(event.type == ALLEGRO_EVENT_KEY_DOWN) 37 { 38 switch(event.keyboard.keycode) 39 { 40 case ALLEGRO_KEY_ESCAPE : 41 exit(1); 42 break; 43 } 44 } 45 46 }

the if condition I commented out is causing any event other than the timer event from happening.

If anybody can tell me why is this happening?

also, what is the difference between a line and a soft line?


al_is_event_queue_empty should not change anything, it is just to tell you if the queue is empty or not. So your problem has to be something else.


    ALLEGRO_EVENT event;

        al_wait_for_event(queue, &event);

    if(event.type == ALLEGRO_EVENT_DISPLAY_CLOSE)

If the event queue is NOT empty then the event object is uninitialized (or maybe has garbage or maybe has last iteration's value). I don't think that this is a good construct. Surely, Allegro is going to know how to check that faster than you can. I think you should always call al_wait_for_event.

Doctor Cop

I changed this line:-

        al_wait_for_event(queue, &event);

with this one:-

        al_wait_for_event(queue, &event);

and it worked. I don't know, why? isn't al_is_event_queue_empty() supposed to return 1 if the queue is empty?

The most fascinating thing I find in this is how it even gets the first event when the event queue is empty, it shouldn't even pass the first iteration.

I can't confirm, the allegro docs are not loading. The whole site is not working. :(

Now is working and I just checked, it says what it should say.

Edgar Reynaldo

When the line checking for an empty event queue is skipped, then allegro will always wait for an event. This means your event is guaranteed to be initialized. If you uncomment it, it won't always wait for an event, which means your event is uninitialized.

The basic game loop is like this :

while (!quit) {
   if (redraw) {Redraw();redraw = false;}
   do {
      al_wait_for_event(queue , &ev);

      if (ev.type == ...) {...}

   } while (!al_is_event_queue_empty(queue));

Doctor Cop


That's why!!!
Now I get it. I'll study more about game loops. Is making an general application loop different than a game loop? I wonder.

Edgar Reynaldo

Game loops and app loops are pretty much the same. You want to deal with events as long as there are any in the queue, and then redraw. Rinse, repeat.


Is making an general application loop different than a game loop?

It depends on the application. Some apps don't have a loop at all, others have but don't wait for events, others do it...

Doctor Cop

Niunio : Is it really possible? How can an application be anything more than a program if it doesn't have a loop?

How and what it can be? What would be its purpose?


  • And for the problem I did this :

ALLEGRO_TIMER *timer = al_create_timer(2.0/60.0);

  • It was set to al_create_timer(1.0/60.0);


I think you're giving magical status to "apps". All programs are applications. All applications are programs. "Apps" is just a short-form for applications. They're really just synonyms.

There are straight-forward programs that just do one thing and exit. Then there are interactive programs that loop until some condition is met to exit (or forever). GUI programs, games, and services/daemons (background programs that often have no user interface at all) generally loop indefinitely unless some exit condition is met (or until they're killed). :-X

A loop in a program that runs indefinitely is generally the same as a game loop, except that typically the UI is abstracted through a framework, and the event processing is also often handled automatically through the framework. The application programmer generally doesn't see the loop in GUI programs (though they can choose to implement it themselves if they wish, but they're so standardized that there's generally no need to do this unless you need to do additional processing while handling events). Instead, they often register callbacks/event handlers to process events instead, and then just tell the framework to start the loop.

Doctor Cop

I haven't given any merit or class to programmes. I studied it in school and it was written in my book that a single page program is a program and a multifile systematic structure of programs is called a software.

maybe that author was shady but I think it is a common misconception, every website I found on ducking had a different definition.

OK, So GUI frameworks work that way. Which framework do you use? What are its merits?

I'm just curious cause I haven't used any official GUI framework yet, they all seem to be ugly so I avoided them.

Edgar Reynaldo

I'll take this opportunity to plug EAGLE. See my signature.

Doctor Cop

Thanks, Edgar but I already know about EAGLE and it's great but I was talking about those ugly frameworks who usually have an XML based language attached and sometimes they have their own IDE.


Which framework do you use? What are its merits?

Just to satisfy your curiosity, I use LCL. Also, I'm developing a game engine that is component based and is quite similar than LCL/VCL: you just need to create some "components" that implement callbacks/event handlers.

Doctor Cop

Cool Nuino, I just watched a tutorial on Pascal, it was good!
You have great stuff going on.


Thanks. ^_^)

Thread #617809. Printed from