- Online Community Forums » Programming Questions » Allegro5: Event Queue Delay Problem

This thread is locked; no one can reply to it. rss feed Print
 1   2   3   4 
Allegro5: Event Queue Delay Problem
Member #14,875
January 2013

Good morning and thank you everybody.

I sincerely appreciate all your expertise in this matter.

I'll keep following this post, just in case in continues and there's some solution that I'm able to use. It would need to be relatively simple though :D

Seriously though, I desperately want to continue using ALLEGRO5, so do you think if I check the keyboard state for the main character control keyboard presses, that this is a good approach for me considering my beginner status.

I can't live with the delay obviously, and because it seems potentially anyone might or might not experience this delay issue depending on the various aspects investigated so far, I don't want to use the event queue and vsync like I have been. I mean, I like the idea that any game I create has the potential to run on other computers, but if it doesn't even work properly with respect to the key down events, on my own two laptops, then at least for now it seems, I have to do something differently.

I can't quite believe that I'm being forced to go down this route. :'(

Thank you again everyone, and I'll frequently check in here over the next few days like I said, just in case. :)

Edgar Reynaldo
Major Reynaldo
May 2007

It would help most if you could get allegro from git and build it with SiegeLord's patch then recompile your program and link to the modified allegro. Then we could examine your output. It seems to be the worst for you.

As far as using state routines go ahead but you will just kick yourself and go back to events later.

Member #14,875
January 2013

Thank You Edgar. :)

I read somewhere that ALLEGRO4 doesn't use the event queue system.

Please let me know if this is accurate or not.

Thanks again.

Edgar Reynaldo
Major Reynaldo
May 2007

No, it doesn't, but you're still better off with A5. It can do everything A4 did except for a debatably crappy gui and paletted graphics modes. But it can also do video with the video addon and shaders are now part of the core, which is where lots of people end up eventually, writing some shader code to get that effect right in their game. And then theres physfs and ogg support too.

Member #14,875
January 2013

So if I don't use the event queue then, I still have as much functionality using ALLEGRO5 as there is in ALLEGRO4 for keyboard input.

I know the event queue system is a modern development, and also used in Pygame for Python (sort of ALLEGRO's equivalent), and that one of the advantages is to never miss a key press, but as I and several others now have already experienced, it's quite possible for there to be this delay we've all been examining.

Based on me not yet having (or soon to have) the technical capability of producing a GIT build used with SiegeLord's patch, it seems then at least for the near future, that reading the keyboard state like when using ALLEGRO4, is probably a reasonable solution for me.

EDIT: I'm just trying to be helpful here, sorry if I'm wrong Edgar, but should your "In the in the event" read "In the event" also "without" :D

I'm just curious how bad are games created using ALLEGRO4, specifically addressing the point about key presses being missed? :)

Massive Edit: This is unbelievable: It's still the same :o

1 2#include <allegro5\allegro.h> 3#include <allegro5\allegro_primitives.h> 4 5const int WIDTH = 800; 6const int HEIGHT = 600; 7 8bool moveup = false; 9bool movedown = false; 10bool moveleft = false; 11bool moveright = false; 12 13int x = 300; 14int y = 300; 15 16bool done = false; 17 18int speed = 5; 19 20int main(void) 21{ 22 //Allegro variables 23 ALLEGRO_DISPLAY *display = NULL; 24 ALLEGRO_KEYBOARD_STATE keypress; 25 26 //Initialization Functions 27 if(!al_init()) 28 return -1; 29 30 al_set_new_display_option(ALLEGRO_VSYNC, 1, ALLEGRO_REQUIRE); // Disable and enable al_rest() at the bottom please 31 32 display = al_create_display(WIDTH, HEIGHT); 33 34 if(!display) 35 return - 1; 36 37 al_init_primitives_addon(); 38 al_install_keyboard(); 39 40 while(!done) 41 { 42 al_get_keyboard_state(&keypress); 43 44 if(al_key_down(&keypress, ALLEGRO_KEY_ESCAPE)) 45 done = true; 46 47 if(al_key_down(&keypress, ALLEGRO_KEY_Z)) 48 { 49 moveleft = true; 50 moveright = false; 51 } 52 53 if(al_key_down(&keypress, ALLEGRO_KEY_X)) 54 { 55 moveright = true; 56 moveleft = false; 57 } 58 59 if(al_key_down(&keypress, ALLEGRO_KEY_TILDE)) 60 { 61 moveup = true; 62 movedown = false; 63 } 64 65 if(al_key_down(&keypress, ALLEGRO_KEY_SLASH)) 66 { 67 movedown = true; 68 moveup = false; 69 } 70 71 if(moveup && y > 0) 72 y -= speed; 73 if(movedown && y < HEIGHT-50) 74 y += speed; 75 if(moveleft && x > 0) 76 x -= speed; 77 if(moveright && x < WIDTH-50) 78 x += speed; 79 80 al_draw_filled_rectangle(x, y, x + 50, y + 50, al_map_rgb(0, 200, 0)); 81 82 al_flip_display(); 83 al_clear_to_color(al_map_rgb(0,0,0)); 84 85 //al_rest(0.016); 86 } 87 88 al_destroy_display(display); 89 90 return 0; 91}

Please try disabling Vsync and enabling al_rest() at the bottom. You get a stutter of course but as before, absolutely no delay whatsoever with Vsync disabled. It's that flipping Vsync. >:( I can feel a conventional game loop being thrown in my face using a timer. But I still want to time the game loop using vsync. It's looking pretty grim for me now.

I'll send pkrcel an email with the .exe. Hopefully he will attach it. I'm going to upgrade this laptop to explorer10 later today, to see if that attachment button appears.

So it really is Vsync causing me the problem.

This program doesn't even use the event queue. So Vsync is somehow related to the delay of all my key presses regardless of whether an event queue is being used.

I'm going out for a few hours and will check here later.

Any more ideas about this anybody? :-[

Dizzy Egg
Member #10,824
March 2009

Just for fun, have you tried init'ing the primitives add-on before setting display options etc?

Please check out my songs:

Member #14,875
January 2013

Edit: I've just tried it, but still the same. Thanks for the suggestion.

I'm about to add another edit with very positive news for me. Please read back here in about 10 to 15 minutes. :)

Nice Edit: Well things are looking very up indeed. I've been reading that simply using a higher logic rate is a solution to smooth movement. I already knew about this, but thought everybody was against it because it meant drawing to the screen more times than the screen is updated to achieve the smooth movement, and that it wastes cpu. I've been checking, and at 300 FPS (yes me using a timer to time my game loop) it's pretty damn smooth and still only uses about 4 to 5 percent cpu as opposed to the 1 to 2 percent at 60 FPS, when testing on my old Vista laptop. Even at 1000 FPS it only uses about 12 to 14 percent, 1/2 that on my newest Windows 7 laptop. :D

So I'm going down this route now. The other up side is I won't need to use variable time steps, which as some people have pointed out, doesn't always turn out to be a good choice.

I'm still going to investigate if there's another way to switch on/use vsync whatever that's supposed to mean, so it don't cause this ridiculous delay issue. :P

Anyway, any comments now it turns out that the delay issue isn't even specific to events entering the event queue, but to my (and no doubt some of yours) keyboard presses regardless of whether using the queue or the keyboard state, when that wicked vsync is enabled the way I've been doing it.

Finally please comment on what you think to using a higher logic rate. Even a very high rate (multiples of 60 seem best for me, obviously due to the monitor being set at 60Hz) such as 300, 480 or dare I even say it, yes the maximum: 1000 FPS (with a timer), surely 1000 has got to be really silly even for a very basic 2d game, surely don't you think so? :)

Nice Edit 2: That once every 2 to 3 second stutter that I'm at war with which I see when a sprite is moving fast at say 10 pixels per frame at 60 FPS, due to my 60Hz monitor not exactly matching the 60 FPS game loop, is actually difficult to even see at 300FPS moving 2 pixels per frame. :D

Member #7,827
October 2006

GaryT said:

This program doesn't even use the event queue. So Vsync is somehow related to the delay of all my key presses regardless of whether an event queue is being used.

This is not surprising. Allegro gets keyboard input using Windows events, and if the delay happens before the events even get to Allegro, then any input mechanism you use to get input from Allegro will be delayed, events or not.

Allegro4 uses a different source of events than Allegro5, so it might not have this same issue... but the Allegro4 method is not recommended by Microsoft, so it won't be used in Allegro5.

Anyway, attached is that same thing pkrcel ran, so try it on your computer I guess. I bet you'll see that Windows events are just as lagged as Allegro events.

This really seems like a driver bug... I'm not 100% sure how to approach it then (plus I can't really, as I can't repoduce it). I think the al_rest() solution might be the best, frankly. If Allegro had an al_yield() that'd be something to try. Also, if somehow we could raise the priority of the Windows event thread it might help things.

GaryT said:

I've been checking, and at 300 FPS (yes me using a timer to time my game loop) it's pretty damn smooth and still only uses about 4 to 5 percent cpu as opposed to the 1 to 2 percent at 60 FPS, when testing on my old Vista laptop. Even at 1000 FPS it only uses about 12 to 14 percent, 1/2 that on my newest Windows 7 laptop. :D

Try having a logic loop that does more than absolutely nothing and draws more than a single square. Boosting FPS that much is just not viable for anything non-trivial.

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

Member #14,001
February 2012

what baffles me is that I'm still experiencing the problem with the original exe from GaryT, while the freshly compiled Allegro I'm not.

is there anything between 5.0 bramch and 5.1 that may justify it?

It is unlikely that Google shares your distaste for capitalism. - Derezo
If one had the eternity of time, one would do things later. - Johan Halmén

Member #14,875
January 2013

Good Morning,

Thank you both.

I've downloaded your attachment for future use, for when I attempt to build a binary, as opposed to using the 5.0.8 pre-built one I'm using now.

Yes that must be it then, on my two laptops it's definitely behaving like "the delay happens before the events even get to Allegro".

For now I'm going to continue either still using Vsync with an al_rest() as you've suggested (or the delay might just disappear due to me having at least one printf() in the game loop anyway), or using a timer. :)

Boosting the logic rate excessively seems to me to be a crude way of dealing with my stutter issue, respectfully I appreciate that. Even so if 300FPS does the job, then maybe this is still viable for a very basic 2d game.

Anyway, I'm now wondering what the answer to pkrcel's last question is.

Just to refer back to one of your previous entries:

"Frankly, this seems like a case of the driver implementing vsync via a busy loop that blocks whatever thread generates Windows keyboard events."

Even for me with my very limited experience, this seems to best describe the delay I'm experiencing :). It also would explain why the problem only ever shows when Vsync is turned on.

In your opinion do you think it might be possible that something in ALLEGRO 5.1 is different to 5.0 which eliminates this Vsync/delay issue. Basically pkrcel's question, I think :D.

Edit: Anyway it's thumbs up for the event queue. I'll obviously be using it now. ;D

Edit 2: I've decided (as you've both suggested) to use al_rest(0.001). I cannot ever see the delay anymore, even if it's (0.000001) as pkrcel suggested. This is proving to be an excellent solution for me. So I'm sticking with Vsync for now which is ultimately getting me the thing I want the most.

Thank You pkrcel and SiegeLord very much indeed. ;)

 1   2   3   4 

Go to: