|
|
|
This thread is locked; no one can reply to it.
|
| A5 Event Queue |
|
Otto Borden
Member #12,058
June 2010
|
Running through some tutorials and I'm wondering if a single event queue can have multiple sources? Can I store events from the keyboard and the display in the same event queue? |
|
Mark Oates
Member #1,146
March 2001
 |
Absolutely. For most applications, I recommend putting all your events into one queue. -- |
|
Otto Borden
Member #12,058
June 2010
|
Sweet! Thanks |
|
Dario ff
Member #10,065
August 2008
 |
Actually, I would try splitting different events in different queues to avoid delay. To sum up what SiegeLord said there, you should have one queue simply for timer events, and another one for whatever you need(input). The reason is that some input events(for example, quit button on window) might get delayed because of the timer events. TranslatorHack 2010, a human translation chain in a.cc. |
|
Evert
Member #794
November 2000
 |
On the other hand, you don't want input events to pile up either. |
|
Thomas Fjellstrom
Member #476
June 2000
 |
Evert said: Typically, I collect all events into a single thread, but drain the queue completely whenever any one event occurs. Same here. It simplifies things a lot, and gets rid of any delay issues. -- |
|
Mark Oates
Member #1,146
March 2001
|
Dario ff said: To sum up what SiegeLord said there, you should have one queue simply for timer events, and another one for whatever you need(input). That doesn't actually solve the problem, though. It just puts the 'trouble kid' in a different room so he doesn't bother anybody else. You'll want to do something more like Evert suggested. -- |
|
Otto Borden
Member #12,058
June 2010
|
So I should call pop on the event queue after performing the actions the event called for? |
|
Thomas Fjellstrom
Member #476
June 2000
|
Otto Borden said: So I should call pop on the event queue after performing the actions the event called for? What I do is use al_wait_for_event, which automatically always pops the event off the queue. And handle the event right away. and run in a loop waiting for the event queue to be empty. see here for a simple example of what I mean. -- |
|
Otto Borden
Member #12,058
June 2010
|
So as long as I use al_wait_for_event the queue will be automatically cleared? |
|
Mark Oates
Member #1,146
March 2001
|
Here's how I do it: Let's say you have a keyboard event source and display event source going into your event_queue: 1while(!game_over)
2{
3 ALLEGRO_EVENT al_event;
4 al_wait_for_event(event_queue, &al_event);
5
6 switch(al_event.type)
7 {
8 case ALLEGRO_EVENT_KEYBOARD:
9 if (al_event.keyboard.key == ALLEGRO_KEY_ESCAPE) game_over = true;
10 else if (al_event.keyboard.key == ALLEGRO_KEY_R) { ... };
11 break;
12 case ALLEGRO_EVENT_TIMER:
13 {
14 al_clear_to_color(al_map_rgb(0,0,0));
15 // do stuff
16 al_flip_display();
17
18 // other stuff...
19
20 // at the very end of this event:
21 // if the next event is another timer click, flush it out.
22 while (al_peek_next_event(event_queue, &al_event) && al_event.type == ALLEGRO_EVENT_TIMER) 23 al_drop_next_event(event_queue); 24 }
25 break;
26 default:
27 break;
28 }
29}
This assumes you're using only one timer. The key is line 22-23. -- |
|
Thomas Fjellstrom
Member #476
June 2000
|
Otto Borden said: So as long as I use al_wait_for_event the queue will be automatically cleared? If you always drain all the events yes. If you aren't always fetching all events, then no. -- |
|
|
