Some assistance with event queues please?

grammerangel

I'm new to this event system, and nobody around me knows what I'm talking about. I'm about two weeks into Allegro, and this has been bugging me.

Here's a snatch of code I'm working on, everything is initialized;

#SelectExpand
  1
  2void input (ALLEGRO_DISPLAY *display, ALLEGRO_EVENT_QUEUE *eventqueue)
  3{
  4
  5      ALLEGRO_EVENT ev;
  6      ALLEGRO_TIMEOUT timeout;
  7      al_init_timeout(&timeout, .06);
  8      bool getevent = al_peek_next_event (eventqueue, &ev);
  9
 10  while (1)
 11    {
 12    cout << "Enter '1' to exit or '2' to draw a line." << endl;
 13    cin >> number;
 14    if (number==1)
 15    {
 16      al_destroy_display(display);
 17
 18    }
 19    if (number==2)
 20    {
 21      al_draw_line(250,0,250,500, al_map_rgb(255,0,0), 10);
 22      al_flip_display();
 23
 24    }
 25
 26
 27    if (getevent==true && ev.type == ALLEGRO_EVENT_DISPLAY_CLOSE)
 28    {
 29      cout << "Event" << endl;
 30        al_destroy_display(display);
 31        break;
 32
 33    }
 34
 35  }
 36}

Suppose I press the X button before I put in a number. I'm trying to get the third if, the getevent line, to understand that there is an event in the queue and act accordingly. This code serves no actual purpose, but I want to understand exactly how queues store data. I thought the queue would store the input, and then getevent would recognize that there's something in it and save the event in ev, which the next piece would pick up. But in practice, the line doesn't return true.

If somebody could explain this, rather than correct this, I'd appreciate it.

Trent Gamblin

You should have a single "message pump" loop something like this:

#SelectExpand
  1ALLEGRO_EVENT event;
  2redraw = true;
  3while (true) {
 while (!al_event_queue_is_empty(queue)) {
    al_get_next_event(&event);
    if (event.type == ALLEGRO_EVENT_TIMER) {
       input(&event);
       logic();
       redraw = true;
    }
 }
 if (redraw) {
    draw();
 }
 al_rest(0.001); // rest 1 millisecond to avoid frying the cpu
 16}

grammerangel

Alright, I was wondering if you could explain some things:

#SelectExpand
  1ALLEGRO_EVENT event; //Creates event
  2redraw = true; //Unsure of what the purpose of redraw is. I saw it in the
  3               //tutorial as well
  4
  5while (true) {
  6   while (!al_event_queue_is_empty(queue)) { //While the event queue is 
  7                                             //not empty...
  8
  9      al_get_next_event(&event); //So what does this line do differently?
 10                                 //It gets the next event, but how is that
 11                                 //different from what I did?
 12
 13      if (event.type == ALLEGRO_EVENT_TIMER) {//If the event is AET...
 14         input(&event); //It goes to input and passes the event's location...
 15         logic(); //What is this for?
 16         redraw = true; //and again redraw. But redraw was always true.
 17      }
 18   }
 19   if (redraw) {
 20      draw(); //Then what's this? If this is where the line is drawn,
 21              //what does logic or input do?
 22   }
 23   al_rest(0.001); // rest 1 millisecond to avoid frying the cpu
 24}

Trent Gamblin

#SelectExpand
  1ALLEGRO_EVENT event; //Creates event
  2redraw = true; //Unsure of what the purpose of redraw is. I saw it in the
  3               //tutorial as well
  4/* when redraw is true (which happens to be any time any logic is done), the scene is redrawn */
  5
  6while (true) {
  7   while (!al_event_queue_is_empty(queue)) { //While the event queue is 
  8                                             //empty...
  9
 10/* NOT empty */
 11
 12      al_get_next_event(&event); //So what does this line do differently?
 13                                 //It gets the next event, but how is that
 14                                 //different from what I did?
 15
 16/* You peeked at the event which does not remove it from the queue. Peek event should rarely be used. The major difference between my code and yours is that events are popped off the queue in only one place, which will make your code much more maintainable in the long run */
 17
 18      if (event.type == ALLEGRO_EVENT_TIMER) {//If the event is AET...
 19         input(&event); //It goes to input and passes the event's location...
 20
 21/* input() should handle your events. For example it could check if the escape key is pressed and quit the game if so. In a complicated game, you could make input(), logic(), and draw() all function pointers (or put them in a class) and then you could have different components that all use the same loop. For example, a menu loop and a game loop */
 22
 23         logic(); //What is this for?
 24
 25/* This updates all of your game objects. It would usually check what happened in input() and move the player etc according to input. You could get away with combining logic and input in many games. You would also update anything that moves or reacts to /time/ in logic(). No drawing should be done in logic(). */
 26
 27         redraw = true; //and again redraw. But redraw was always true.
 28
 29/* redraw should be set to false just before or after draw() in the if block. That was a mistake on my part */
 30
 31      }
 32   }
 33   if (redraw) {
 34      draw(); //Then what's this? If this is where the line is drawn,
 35              //what does logic or input do?
 36
 37/* This does nothing but draw the current state of the game. You should not update things relevant to time or input in here */
 38
 39   }
 40   al_rest(0.001); // rest 1 millisecond to avoid frying the cpu
 41}

grammerangel

Also, I'm confused how al_get_next_event can work with only one argument. I need to give the queue, right?

Trent Gamblin

http://www.allegro.cc/manual/

grammerangel

Yes, that's where I got this.

bool al_get_next_event(ALLEGRO_EVENT_QUEUE *queue, ALLEGRO_EVENT *ret_event)

Take the next event out of the event queue specified, and copy the contents into ret_event, returning
true. The original event will be removed from the queue. If the event queue is empty, return false and
the contents of ret_event are unspecified.

It still looks like it needs two parameters. Unless I'm misunderstanding something.

Matthew Leverton

Yes, it needs both arguments.

grammerangel

Okay, that makes sense.

Let me see if I get the gist here; the event queue almost always has something in it; a timer. Every tick kicks the previous event out of the queue, so that's why the program wouldn't just "remember" the close button. But then why do we keep checking if the event is ALLEGRO_EVENT_TIMER and passing the location based off of that? The timer is always ticking, so all the program would do is act off of the autonomous timer and wouldn't react to user input like DISPLAY_CLOSE, right? I know that's not how it works, but then where am I misunderstanding this?

Matthew Leverton

Queues can hold an infinite number of events. Nothing is removed from the queue until you take something out of it. Functions like al_get_next_event() and al_wait_for_event() removes the oldest element off the queue. You process that event. Then you wait for the next event, etc.

grammerangel

...Dammit, now I'm confused again.

Let me run this one by you; The al_get_next_event sees the timer's tick, then gets rid of it and copies it into event. Have I got it so far?

But the rest of the code only works if the event type is ALLEGRO_EVENT_TIMER. The event holder can only hold one event, right? So what is the point of repeatedly going through input if all you're passing is the location of event, which is holding a timer tick? Or is there an difference between an event queue and ALLEGRO_EVENT event?

Matthew Leverton

Normally the queue would hold a variety of event types: a timer tick, a mouse movement, a key press, a close window, etc. You can register one or many different sources to the same queue.

So you copy (move) the event out of the queue, check what type it is, and do something. Repeat.

grammerangel

Is it just implied that there's more than one source? Here's what I'm seeing:

if (event.type == ALLEGRO_EVENT_TIMER) {
input(&event);

The first line checks if the event holder is a timer tick, and the second line uses the event, that tick in input. All that is being used in this example is the ticks. Nothing but. There is no check if the event is a mouse input, or a display close. Why would the input be concerned with the timer? What purpose is there to carrying the timer tick to input? Or am I supposed to just use this as a template and add my own checks for events? Something like:

#SelectExpand
  1al_get_next_event(&event);
  2
  3//This gets the tick from the timer. If the user gave an event beforehand, //then that event is stored just before the tick.
  4
  5if (event.type == ALLEGRO_EVENT_TIMER)
  6
  7//This checks if the event was a tick. Which means it's going to be checking //and triggering almost constantly.
  8
  9{
 10al_get_next_event(&event);
 11
 12//this gets the event next in the queue, which is the user's event because the //newest event was copied then destroyed by the last al_get_next_event.
 13
 14input(&event);
 15
 16//And this handles the user's event that was obtained in the last function.
 17}

Does this even make sense? Are my thoughts coming through at all?

Matthew Leverton

I don't understand Trent's example either. Perhaps he assumes you aren't going to use events to process input, and instead are just going to poll keyboard/mouse states and look at the event's timestamp.

For games it's easiest to process everything all at once per timer tick. While using events for input guarantees you won't lose any data, it means you have to somehow work that into your timer logic.

So some people take the lazy approach because it usually works without any problems: just check for timer ticks, and then use al_get_keyboard_state() to check if a certain key is pressed at that moment in time.

grammerangel

...and then react to it, right? The poling method just checks over and over if a key is pressed, then performs some action based on the poll results?

That kind of makes sense... I'm away from my Visual Studio at the moment, let me get back to you tomorrow.

Matthew Leverton

If you use input polling, you would still wait for a timer tick. Once you get a tick, you poll the keyboard state once and then check to see if whatever keys you are interested in were pressed.

The whole point of the timer tick is to make sure your game runs at a constant speed. If you know you are always checking 60 times per second, then you can simplify the rest of the logic. e.g., If the LEFT key is pressed during that tick, you might move your character over by exactly four pixels.

Thomas Fjellstrom

Maybe it'll help if I explain the event loop from the wiki:

#SelectExpand
  1while(1) // loop till we 'break' out.
 {
    ALLEGRO_EVENT ev;
    al_wait_for_event(event_queue, &ev); // wait for an event to come in. Forever if need be.

    if(ev.type == ALLEGRO_EVENT_TIMER) { // We got a timer event, do some logic!
       if(bouncer_x < 0 || bouncer_x > SCREEN_W - BOUNCER_SIZE) {
          bouncer_dx = -bouncer_dx;
       }

       if(bouncer_y < 0 || bouncer_y > SCREEN_H - BOUNCER_SIZE) {
          bouncer_dy = -bouncer_dy;
       }

       bouncer_x += bouncer_dx;
       bouncer_y += bouncer_dy;

       redraw = true; // things changed, so tell the drawing code it should run
    }
    else if(ev.type == ALLEGRO_EVENT_DISPLAY_CLOSE) { // user clicked the X button on the window, break out of event loop and exit.
       break;
    }

 24
    // if something changed and we want to redraw, do that, but only once the event queue has been completely drained.
    // In case things bogged down for a bit and we have multiple timer events in the queue,
    // this makes sure we only draw once for ALL timer events in the queue, which will help us catch up.
    // Also, it makes sure all input in the queue is taken care of before we draw.
    if(redraw && al_is_event_queue_empty(event_queue)) {
       redraw = false; // obviously we don't want to draw right away again, so clear redraw flag.

       // drawing!
       al_clear_to_color(al_map_rgb(0,0,0));

       al_draw_bitmap(bouncer, bouncer_x, bouncer_y, 0);

       al_flip_display(); // flip backbuffer to screen.
    }
 }

Hope this helps.

AMCerasoli

Before I take the time to write something, have you read the tutorial on the wiki? you know those which says events and input?

grammerangel

I followed the tutorials, and I get the individual examples, but the tutorials don't cover anything other than that specific example.

Anyway, I tried building a routine that checks whether there's input on the display, and passes the event to another function that deals with the event. Suppose I click on the X button;

#SelectExpand
  1
  2while (1)
{
  if (!al_is_event_queue_empty(eventqueue)) //If there is something in the event queue...
  {
    
  
    al_get_next_event(eventqueue, &ev); //Get the event
  9
    if (ev.type==ALLEGRO_EVENT_TIMER) //This catches the tick right after the X button...
    {
      
      al_get_next_event (eventqueue, &ev); //So this one should get the X button, the event just before the tick, right?
      
      input (display, ev); //And then you send the event that should be the display close.
 16
  
    }
  }
 20
}

Of course, this doesn't work. The input doesn't doesn't recognize that the event coming in is the display close.

I know that there are easier ways to pull this off, but I want to makes sure I can use this kind of setup to receive mouse or keyboard input. I still don't think I'm understanding the queue thing, or I'm not thinking properly. Sorry for sticking with this problem, but I'm going to have to learn this if I'm going to get close to designing my own game.

Edgar Reynaldo

I think you're thinking about this the wrong way. Just because there is a timer event in the queue doesn't mean there is another event in the queue, so you may be waiting a while until that event comes.

The event queue will give you the oldest event first, and the rest in ascending order of time received. You could get a key / mouse click event at anytime, and it has nothing to do with a timer event or with a display close event. Don't expect events in any certain order, or you will be disappointed. They will be in the order they happened, but that is all you can expect.

1) When you get a timer event, you should probably set a redraw flag, and you need to update any objects that you have by the amount of time passed.

2) When you get a display close event, then break out of your program loop.

3) When you get other events, send them to each of your objects so they can deal with them as that is the input in your program.

So something like this might work better for you :

#SelectExpand
 while (!quit) {
    if (redraw) {
       redraw = false;
       al_clear_to_color(al_map_rgb(0,0,0));
       for (int i = 0 ; i < (int)objects.size() ; ++i) {
          objects[i]->Display;
       }
       al_flip_display();
    }
    do {
       ALLEGRO_EVENT ev;
       al_wait_for_event(event_queue , &ev);
       if (ev.type == ALLEGRO_EVENT_TIMER) {
          redraw = true;
          for (int i = 0 ; i < (int)objects.size() ; ++i) {
             objects[i]->Update(1.0/FramesPerSecond);
          }
       }
       else if (ev.type == ALLEGRO_EVENT_DISPLAY_CLOSE) {
          quit = true;
          break;
       }
       else {
          for (int i = 0 ; i < (int)objects.size() ; ++i) {
             objects[i]->ProcessEvent(&ev);
          }
       }
    } while (!al_is_event_queue_empty());
 }

This kind of event loop only draws when the timer ticks, will wait for the next event before continuing on, and will process all events that are in the queue before redrawing again.

Thomas Fjellstrom

Edgar Reynaldo said:

So something like this might work better for you :

Which seems to be functionally equivalent to the one in the tutorial.

Edgar Reynaldo

Eh...

Repetition helps reinforce memory?

grammerangel

Okay, I think I get it now... kind of... I see the problem with the code. I have other problems with this, but this is all I have on the subject of event queues.

Thank you so much, everyone. I appreciate it.

Edgar Reynaldo

Actually, the loop I posted should be using al_wait_for_event, not al_get_next_event. I edited it to fix that, and made the drawing code clearer as well.

It's not quite the same as the wiki because of the explicit calls to Update, ProcessEvent, and Display, but the principle is the same.

Thomas Fjellstrom

Edgar Reynaldo said:

It's not quite the same as the wiki because of the explicit calls to Update, ProcessEvent, and Display, but the principle is the same.

The only difference is that the wiki example is so simple it doesn't use separate functions to handle updates, events, or displays. Otherwise its functionally identical.

grammerangel

Reynaldo is right, though, I like seeing the same thing done different ways.It makes it a bit easier to understand what does what.

Thomas Fjellstrom

The major difference is that his nests an extra loop, which isn't really necessary, since we can just skip over the drawing if the queue isn't empty. But I suppose it might be a little easier to follow.

Thread #607821. Printed from Allegro.cc