Okay I'm Really Stuck With This. It's Driving Me Crazy. Please Help

I have the most Simple Test Program with the game loop timed off VSYNC, and all it does is just move a square around the screen.

Here's what’s happening: When I rapidly press a mixture of the relevant keys to steer the square, a growing increase in delay occurs before the event generated by each key press, changes the direction of the square.

My if(trueevent) check on line: 53 I believe is the correct way to handle: al_get_next_event().

Now, just to stop my program cycle proceeding for when: trueevent == true, but the event isn't one I'm checking for, I've inserted the while loop at line: 50, but it's made no difference.

So I've also added: al_is_event_queue_empty() to stop the program updating the position of the square and drawing it. I've done this partly just to try and find out how things are working.

This still hasn't stopped the delay.

I can only assume I'm doing something fundamentally wrong. I wasn’t expecting to have to do anything additional to my: if(trueevent) check on line: 53

The Most Confusing Point For Me: After rapidly pressing keys for about 5 to 10 seconds and then stopping, the square keeps moving smoothly and changes direction a few times over the next 3 to 4 seconds. Now, surely then, there must be events moving up the queue during these 3 to 4 seconds. But, if this is true, then why does the program continue to update the position and draw the square, even though it’s restricted by: al_is_event_queue_empty

The program is 100% complete, so please try copy and pasting it.

So please can somebody explain what's going on here

EDIT: Just wanted to say that sometimes the problem barely occurs. Most times it's definitely noticeable. Stopping and starting the program seems it can cause this difference.

Also From Further Testing:

1) My trueevent variable only ever returns true when an intended event occurs such as pressing a key.

2) al_is_event_queue_empty() is returning true for every cycle, even when events seem that they must still be on the queue as previously described.

I haven't checked deeper but this

while(trueevent && ev.type != ALLEGRO_EVENT_DISPLAY_CLOSE && ev.type != ALLEGRO_EVENT_KEY_DOWN) // Added To Try And Fix Delay Problem !!!  
    trueevent = al_get_next_event(event_queue, &ev);

..did you put it in to try remove spurious events?

I wouldn't do that, and do the other way round: do not process spurious events and draw only if the scene need to be actually redrawn...you can achieve this using a bool like needsredraw that you set in your switch statement, and your drawing code shoudl be enclosed in an if(queue_empty && needsredraw)

Anyway, lemme check for the rest...I'm at work now and could not read further.

You say "while trueevent" and then after that say "if(trueevent)" which looks wrong to me...

Thanks pkrcel.

I know what you mean, but the: needsredraw part of: if(queue_empty && needsredraw) is typically, from examples I've seen, set to true in a timer event, which would then result in executing my block of code updating the position and screen.

Because I'm not using a timer, and the game loop FPS is determined by Vsync, then the: needsredraw part, seems perhaps not applicable in this circumstance.

Incidentally, I only found out by chance that setting Vsync to be on prior to creating the display, does in fact time the whole game loop in this simple way. Vsync definitely works in this way (try commenting out) but I'm not even sure if this is the proper way to do it. It probably is, but not totally sure.

Also this is exactly why I'm using al_get_next_event() instead of al_wait_for_event(), since: wait, so far seems to me, to only be able to update the object positions and display the screen, by using a timer. Whereas so far I've only understood it to be possible to use Vsync to time my game loop by using: al_get_next_event()

EDIT: I agree Dizzy Egg, my apologies for that while loop. It's rubbish, doesn't really make sense, and was just a desperate attempt to try and shake something up to help me see what was happening.

Please read from the start of this reply. I replied to: pkrcel before having a chance to read your reply

EDIT 2: The good news is for me, I've tried running the program on my other laptop which is very new and fast, fearing I wouldn't be able to reproduce the issue. Thankfully it's every bit as noticeable on that computer as well.

Important Note For Testing: Sometimes the program starts up and is perfectly okay forever, sometimes just a little bit bad, and sometimes quite naughty indeed. So keep restarting it if you don't experience the problem.

So, how can the event queue be empty if the square's position updates and the direction changes for a few seconds after you pressed the last key.

It's as if there's a build up of events on the queue, which would explain the delayed changes in direction after you stop pressing keys, but at the same time the check: al_is_event_queue_empty() is returning true. This seems to be a direct contradiction and is confusing the hell out of me.

EDIT 3: Just a thought: I suppose if there was some kind of keyboard buffer that was storing up key presses, and in a delayed manner, feeding them to the event queue, as opposed to the key presses being registered directly onto the queue instantly, that this might explain it. That can’t be right though can it. I've never heard of anything like that.

Uhm, no?

Actually you've seen those in a timer event BECAUSE the examples you've seen set the framerate through a timer (Mike Gieig's does this in his tutorial), but the idea is that you actually blit to the screen IF there is something NEW to draw (eg. the scene has effectively changed), whichever is the way you time your draw routines.

In your case I was suggesting that you could get off your (now definitely ruled out by your further debugging) spurious events simpy ignoring them AND not drawing when you intercept one of them.

Anyway that was not the case in the first place....shoulda look a bit into it (thou mostly for learning purposes, as I already said in a previous thread, I'm not qualified for good game-loop timing )

I'm drawing something new every frame since the square is moving 1 pixel per frame.

Anyway, it's all my remarks in my last entry that I would love some help with. In particular how it seems the event queue is registering as empty allowing the position and draw update to happen, when events are clearly taking affect/effect (not sure which) a few seconds after pressing the last key.

EDIT: Is there a keyboard buffer or something that could be storing key presses and feeding them slowly to the event queue. I guess probably not.

    trueevent = al_get_next_event(event_queue, &ev);

    while(trueevent && ev.type != ALLEGRO_EVENT_DISPLAY_CLOSE && ev.type != ALLEGRO_EVENT_KEY_DOWN) // Added To Try And Fix Delay Problem !!!  
      trueevent = al_get_next_event(event_queue, &ev);

    if(trueevent)
    {

If the first al_get_next_event returns true then you proceed to change the event as long as it is not a display close or a key down event.

So, say trueevent is true, and it is a key down event. Then you immediately replace it with the next event thereby missing one key down event. And if the second al_get_next_event was false the first event is still skipped. So you are skipping events.

Try this :

do {
while (!al_is_event_queue_empty(queue)) {
   ALLEGRO_EVENT ev;
   al_get_next_event(queue , &ev);// Guaranteed to work because al_is_event_queue_empty returned false.

   if (ev.type == ALLEGRO_EVENT_TIMER) {redraw = true;}
}
if (redraw) {
   Redraw();
}
} while (!quit);

However, you have to be aware the code I just posted will use up 100% cpu because you're not resting at all. That's why you want to use al_wait_for_event instead of al_get_next_event.

do {

do {
   ALLEGRO_EVENT ev;
   al_wait_for_event(queue , &ev);
   if (ev.type == ALLEGRO_EVENT_TIMER) {redraw = true;}
   if (ev.type == ALLEGRO_EVENT_KEY_DOWN) {
      // key pressed, do something
   }
} while (!al_is_event_queue_empty(queue));

} while (!quit);

That way you skip events you don't want by ignoring them, but you don't let them build up in the queue either.

Thanks Edgar.

I had previously criticised that while loop I put in, and to be honest it never really properly addressed the issue.

Just as a matter of observation though:

It is actually "not a display close && a key down event" so no events are missed here.

Anyway please read my remarks from my previous entries explaining how I'm using Vsync to time the game loop.

From my Example Test Program included in this thread, I'm not sure how I could use a timer as you've suggested, without overriding how Vsync takes control of timing the game loop.

Also please notice my explanation of why I use: al_get_next_event().

So another question is: How can al_wait_for_event() be used to determine the FPS at the same time as the FPS being set by the Vsync signal.

There was a similar question some days ago here....seems the solution goes right into managing input with the event system.

Anyway,

uhm, right...you're setting direction with a SINGLE keypress so you basically have almost always something that needs redraw....that could NOT be the general case in a game but whatever...here the problem is another one.

I'll be damned, lemme just try compile this thing and run it....more on this later.

EDIT: Okay, tried it quite some 20 times and never got your problem. My built-in gfx card is set to let the application decide for VSYNC, I removed the ill-conceived While loop and set a little thingy that display FPS in the upper left corner...it says consistently 60FPS (more or less...float/double approx )
I'm sorry but I ain't able to reproduce.

Thank you very much pkrcel for all your assistance

I feared because of the inconsistency of the issue, that other people might not be able to reproduce it. Because of this I tried it on my other new laptop and got the same issue.

I know you've tried it 20 times or so, so thanks for giving it a go.

Just to be absolutely sure, sometimes for me the program was running for up to about 10 seconds with me quite rapidly pressing the keys before the very noticeable delays started to show and increase.

Just to point out 1 quite literally insane observation, and that is whenever I have 3 to 4 calls to a draw function without changing anything else, this seems to stop the delay. Obviously not a consistent or controlled method I could rely on, but just adds to my confusion.

I still think I'm missing something fundamental in all this. Maybe some other Event Queue checking functions.

Anyway, I'll keep looking into it, and post a thread if/when I find out what's causing it.

EDIT: Thanks for that link as well.

EDIT 2: One last question: What version of Allegro5 are you using.

EDIT 3: I've just replaced al_get_next_event() with al_wait_for_event(), correctly set up a timer to handle update position and draw, and: OH blimey, it's still the same. I'll be back.

Riight, that should have been a concern all the way here, anyway It's a git revision I compiled myself...unfortunately now I cannot tell you WHICH revision since I'm not at that PC, but it's the 5.1 branch for sure.

Thanks for that info.

I'm using 5.0.8

I will try a later version tonight after I get back from work.

Also please see my last edit.

Cheers.

Well, then.

I tried on this PC (a Delll Vostro 3550 Laptop) the following codem which is just a minor modification of yours:

with freshly downloaded 5.0.8 binaries (BTW A.cc community...michal's usual link stopped working!), and for the life of me I am unable to reproduce your problem.

FPS is consistent with VSYNC rate, in fact on 60Hz I get 60FPS and if I switch to 40Hz i get 40FPS, and I experience no delay whatsoever in the inputs, the square does change direction only when I actually press a button (I changed yours to match my arrow keys, I am unable to find the slash and the tilde on Italian layout keyboard....well the slash is at its usual place above 7 but still...).

I tried both Release and Debug Builds, both STATIC and DYNAMIC liking....really sorry but I can't reproduce your problem.

Or it's simply me unable to notice the problem? I'm now starting to wonder...

I'm back from work, I'll test some more. Back again soon.

Update:

Well ok, I admit it, what a plonker I am.

Please see the revised list.

Well now, there is an improvement in Debug mode, but it ain’t perfect, there's still delays. That side effect I mentioned, well, I left a second call to a draw function in the program and didn't notice. This as I've said before somehow masks the delay problem I'm getting.

So I'll keep at it, but feel very beaten up right now. Thank you though pkrcel for your time and assistance.

Edgar: It's supposed to keep going after you let go of a key. That's not the problem.

The problem is this: After releasing the last key press of rapid pressing, the square doesn’t just keep moving, it sometimes changes direction a few times during the following few seconds. This happens on both my HP Laptop using Vista and my Samsung Laptop using Windows 7. So far not on my XP computer at work.

Points I've considered:

1) There are events on the queue during these few seconds. There has to be, else why does it change direction.

2) The code: if(al_is_event_queue_empty(event_queue)) means the square's position can only change and it be redrawn, if all events including key presses and releases have been removed from the queue by: al_get_next_event().

3) From points 1 and 2 then, it seems as if the only way events can be on the queue during these few seconds, and: al_is_event_queue_empty(event_queue) is returning true enabling the program to draw and move the square, is if this: Something equal to or equivalent to: A delayed process such as my imaginary idea of a slow keyboard buffer feeding the key presses to the queue during these few seconds.

4) From point 3 above, why don't all the key presses just enter onto the queue almost instantly. They should also be removed from the queue at the rate of 60 (i.e. my monitor is set to 60Hz) times per second. It's tempting to think the key presses do just enter onto the queue almost instantly, but if this is the case then back to this: why doesn't: if(al_is_event_queue_empty(event_queue)) stop the program updating the squares position and drawing it, then?

Thanks again and I hope somebody can shed some light on this.

I’m off to work now. I’ll check back here when I get home. Cheers.

Okay, well I looked over your program again, and for what you are doing, it should work, except for the fact you don't track key up events. That is the reason it 'keeps going' after you let go of the key. I will test it more when I get home tonight. Actually, this is a slightly modified version of yours with key releases added, and it works just fine for me. :/

Please See My Revised Content In My Previous Entry.

Also please see the keyboard or mouse examples on the wiki.

You DO NOT want to skip arbitrary events. And using a timer to handle drawing is a much better solution than what you've got so far. The loop on the wiki is a decent starting point. After you can add interpolation later if you find your game stutters too much.

Basically what the examples do is force all events to be handled before drawing, and drawing will happen a maximum of N times per second based on the timer rate (which in the examples is 60). It automatically handles frame skipping, and making sure the event queue is drained fully so there is no "delay problem" which is caused by the event queue getting backed up.

Okay I tried it without the key releases, and there is a delay at times if you jam on the keys and then try to change direction. It can be a noticeable pause, and it seems like it is way more than 1/60 sec.

Your way is unconventional, but I guess it should work, and not the way it is right now.

Edit - Look at the way SiegeLord does it

That's what I was replying to. your code just doesn't work as is.

I am seeing the same behavior, the events are getting backed up in the queue, but it is still returning empty otherwise it couldn't draw.

This is an equivalent event processing to yours, and it has the same problems :

You can replace that with :

    if(gotevent)
    {
      // set motion / close / whatever
    }
    else 
    {
      // process one logic and one drawing frame
    }

because al_get_next_event returns false if the queue is empty.

Here is the code for al_is_event_queue_empty, get_next_event_if_any, and al_get_next_event :

I don't see anything wrong with these functions so far. So IDK what to tell you.

I tried adding in some text display, the delta time and the fps. dt is around 0.016 and fps is around 60. But now that I added that in, the delay disappeared. I don't know what is going on. :/ Working in debug mode right now. Added in number of events processed and it did it again. Added in max number of events processed and it stopped doing it again.

Remember the input events are added to the queue by a background thread. You should check that it's actually doing that in a timely manner (I can't remember how the Windows port works right now).

Thank you both.

Right then, I've just downloaded Microsoft Visual C++ 2010 Express on my other Laptop, The newest one, which uses Windows 7.

I've simply created the same file path from c: to where my pre-built binary needs to be, and freshly downloaded the correct binary to this folder.

Now, I've copied my program project folder to the other computer, Windows 7 . I've compiled it as usual and: Exactly the same delay as my Vista Laptop, perhaps slightly worse. I've checked the .exe size and is exactly the same, what I'd expect.

Yes this might be an unusual thing to suspect, but I wanted to be sure that it wasn't anything to do with my Vista computer. Incidentally on my XP computer, which I tested the .exe on yesterday, there's no delay whatsoever.

So it seems the way I'm doing it just doesn't work the way it looks like it should do. Again please read through my points 1, 2, 3 and 4 in my previous entry. I think they’re valid, and if al_get_next_event() was removing events each cycle, then at 60 FPS I don't see how the queue could GET BACKED UP. But perhaps I'm missing something. Please explain.

Thomas: You said "force all events to be handled before drawing" I thought that's what my: if(al_is_event_queue_empty(event_queue)) is supposed to do.

Anyway, it doesn't work properly, so I have to change the way I'm doing it. I CONCEDE. Edgar: Yes my way is unconventional, and I also guess it should work, but unless there's something I'm missing, Allegro it seems is just not supposed to be used this way. Damn!

Everybody: I don't want to time my game loop using a timer. I want it to be timed by the Vsync signal. That's why I've set Vsync to be on and I'm not using a timer.

What's the correct/proper way to do this. Please help me with this. Please!

Please address this point as well: I've been setting Vsync on to time my game loop off the Vsync signal. As soon as a timer is used in the conventional way, but at the same time as Vsync being used like I'm trying to use it, the timer then determines the FPS, which isn't surprising, but not what I want.

Thank you Edgar for the link. I've had a look and I'm trying to understand how the "FPS is limited by the vsync". I can’t see any call to Vsync, so I'm struggling to understand this aspect. Please explain.

Anyway, I've tried the method of completely draining the event queue using a while loop and I still get the same delay issue.

It seems to me that it's extremely likely to do with Vsync. When I turn it off, although there's an increase in cpu usage (not as much as I was expecting though) there's clearly no delay.

So I'm still feeling a bit beaten up.

EDIT: Peter Wang, that's the most reassuring reply I've had so far. I've noticed you are on the development team, but unfortunately for me I'm still a beginner.

Anyway, there's no chance I could understand the depths of your suspicion any time soon, but it exactly falls in line with the behaviour I'm getting and my imaginary idea of a keyboard buffer (that I previously mentioned in this thread) feeding the key presses into the queue slowly at times.

Well I'll wait for further replies. Thank You Peter.

I'm late for work. I'll check here tonight.

The implication is that the display was created with the ALLEGRO_VSYNC option set to ALLEGRO_REQUIRE/ALLEGRO_SUGGEST. I know it doesn't work on some platforms, but that's a bug to be fixed in Allegro.

Thank you again SiegeLord

I'm starting to feel much better now having received Peter's and your replies

I'll look at your example a bit more when I get home. Cheers.

When you press a key Windows sends an WM_KEYDOWN message which we duly process. But when you hold it long enough for the auto-repeat to kick in, Windows seems to send repeated WM_KEYDOWN messages at a lower rate (probably the repeat rate) and, bizarrely, blocks other WM_KEYDOWN messages from getting through. I'll try to investigate further later, but maybe some Windows experts can chime in. (edit: probably Wine-specific bug)

I wasn't able to reproduce in Windows XP.

I'm only getting the problem on Windows Vista and Windows 7. Not on XP.

Just to emphasize something once more for anybody testing this out: Very strangely I appreciate, but when having more that one call to a draw function, then for most runs of the program the delay largely disappears.

For example take the test program in pkrcel’s last entry: If I comment out the call to al_draw_textf() line 108, it makes the difference (most of the time on my two laptops anyway) of the delay being quite noticeable most of the time, and not noticeable at all. Just a very strange oddity I know, which somehow interrupts the true cause of the problem, but thought it very important to point out for anybody else trying to reproduce the delay issue.

Also, when using al_wait_for_event and using a timer (But No Vsync) there is absolutely no delay. So then, since my approach with using Vsync in the way I am doing is perhaps non conventional, then maybe this is why nobody else is noticing the delay issue. BUT if I enable Vsync with: al_set_new_display_option(ALLEGRO_VSYNC, 1, ALLEGRO_REQUIRE/ALLEGRO_SUGGEST) the problem's every bit as bad with al_wait_for_event and using a timer, as compared to the way I'm doing it.

So having said all that. It seems something is definitely buggy about Vsync which is affecting at least the Event Queue, specifically KeyDown events and probably others.

Also from Peter Wang's 1st reply, it seems it's very likely to do with: "input events are added to the queue by a background thread" as this explains perfectly the behaviour. That is the ALLEGRO logic of the loop is working correctly, but there's a definite delay from pressing a key to the events entering the queue.

Until this problem is officially recognised and fixed, I'm considering not using the event queue for just the key down events that control my characters when the game state is in play. I'm going to replace these particular key down events with checking the keyboard state instead. This way I can still time my game as I've been going on and on about, using the Vsync signal as I've previously mentioned.

I've heard Allegro4 doesn't have the events system and uses the keyboard state as I've suggested above. Also I've heard about key presses being missed, which I can understand why, but is it really that bad. If Allegro4 has been working great for all these years, surely it can't be that bad.

I'm going out to the pub now. See you later and Thank You.

I tried again, and I can't reproduce it anymore. :/
(MinGW 4.5.0, A5.1.6 binaries, Vista, debug/release)

No, that's not true. Vsync works just fine and that has no bearing on the event queue. If the event queue is both simultaneously empty and backed up that means that its event source is not feeding it fast enough or perhaps on time, but I don't know what the delay would be.

i should have mentioned I am using VS2012, alas MSCV11...I think with last November's CTS update....I could try also with MingW and VS2010.

Given all of the answers here, and the fact that XP seems to be NOT showing the problem whatsoever something may be fishy in the backgournd thread not filling up the queue....but this MAY depend on some Windoes interface?

Gary woud you care to attach here your VS10 solution?

You can't possibly know that Vsync works just fine on every system on all Windows versions. Also it's unlikely that it's only my two Laptops that are showing the problem. Having said that, both my Laptops are using the same MSCV 2010 and VS10 solution. So perhaps it could be settings within my solution properties settings that are the problem. I'm wondering now from pkrcels's last reply.

What does this mean. I've never believed this to be true. How can it be. The queue or anything else can't be empty and have something in it at the same time. The whole point here as Peter pointed out and now pkrcel is considering, is that it might be the background thread is for some reason on perhaps only some systems and on only some windows versions, feeding the events to the queue with a varying time delay.

Yes pkrcel, I'm very happy for you to take a look at my VS10 solution.

I've uploaded the complete project folder to my sky drive, it's a zip file of about 10.8MB

I'm off to work now, but I'll check in from time to time.

Do you have an email I can send you a shared link to for my Sky drive.

Alternatively I can provide an email address for you to send me your email address for confidentiality.

Addition: I've increased the speed to 5 pixels because it's easier to notice. I've found the best thing to do to notice the delay is let the square move across the screen and tap the up and down keys about 1/3 second apart repeatedly. This way even if the delay is minimal, it's very easy to notice when the direction doesn't change immediately.

Please let me know and thank you.

If you re-read peter's post, you'll see what he was seeing was likely a bug in wine. Nothing to do with windows.

Probably Likely

I don't really care either way.

I just want to know how to fix the problem I'm getting.

I really haven't properly read all of your points. Mainly because the few I read made no sense to me. Same with the code.

Can you post a very minimal example that shows the problem reliably, and isn't broken like your original code?

What do you mean broken.

Besides the first While loop within the main loop which I put in, and have already criticized declaring it to be rubbish, the program couldn't be more simple. That's it's purpose, it's a test program of the simplest kind. Smiley Face. (I'm at work on XP and I can't add the little pics.

Thank you Thomas.

I tried the code in the OP and pkrcel's post, and I could not reproduce the issue on Windows 7 with the git version of Allegro.

It looks like people who can reproduce this will need to hack away at Allegro's source and put some debugging output inside the keyboard routines. I could try producing one-off binaries to help, but I only have MinGW 4.7 installed.

Thank you SiegeLord.

If pkrcel doesn't manage to reproduce it from my VS10 Solution after receiving it, then I might try a compiler other than MSVC or a later version than MSVC10.

At least for now I might also just try reading the keyboard state for the main character control keys. At least this way I won't have come to a complete stop, and could attempt to sort what ever this issue is, out later.

Just a quick question about this control panel window I'm typing in: Is there an attachment feature for attaching files and zip's. On my Laptops I'm using explorer 9 and I don't know if the icons at the top of this window are supposed to display text when hovering over them. On XP using explorer 8 I can't even add the small pics(Sad Face). Might it be I should be using explorer 10.

If not then hopefully I'll be able to provide it to pkrcel and anybody else via email. Cheers(Smiley Face)

EDIT: When I get more experience I might also try building an ALLEGRO Package such as the new 5.0.9 version. But have no clue how to do that yet.

EDIT 2: Also anybody who receives my VS10 Solution (includes the whole project folder) will at that point have a copy of the .exe I've generated. You could copy it somewhere else before recompiling so you don't write over it. You could run this .exe to see if you can see the delay.

EDIT 3: And, you could compile the source code yourself using any compiler, and let me have a copy of your .exe. I would love to know the results of all this. (Smiley Face x 2)

I still don't get your original code; if I press up start moving up, and don't stop until I press down, at which point keep moving down. If I press left it'll keep moving down but left as well.

I suspect buffoonery.

Gary, feel free to send me the link at pkrcel(whackyroundsymbolusedforelectronicmail)gmailDOTcom

Yeah I know I am truly paranoic.

<= NOT paranoic.

Anyway you could also have uploaded just the solution (.sln) file to your post, it woudl suffice just for now.

But, just to clear all out, when I asked you for your MSV Csolution I've been thinking along the lines of Siegelord's post...IF there is a backgorund thread and Windows messaging system is involved, some security features may get in the way (namely to avoid someone log your keypresses).

Just a random though since Xp seems not to generate any problem and IIRC Vista/7 do habdle a little bit deeper the matter.

But as said, these are really random toughts.

That's correct. The square just keeps moving. It's a very basic test program.

The problem is a delay in processing key presses as described throughout this thread.

The logic of the programs loop is working correctly. It seems that I'm sometimes getting a delay before the event key presses are entering the queue.

This has already been suggested and described in this thread (Smiley Face)

EDIT: I've sent the link pkrcel. Please let me know if you receive it ok.

As in my last reply to SiegeLord, I don't know how to attach files in this forum. I might be using the wrong version of explorer. Many Thanks.

Got it....I need to install the MSVC10 redistributable since you deploy DINAMICALLY linking to the C runtime libs....I strongly suggest to use the /MT option of all the available libraries...

EDIT: ....aand indeed the VC2010 redistributable package does NOT contain DEBUG libraries.....

I have been Static Linking as per the Wiki tutorial.

Obviously I don't understand the complexities of all this, but the .exe runs on my XP computer which has no software on it in connection to any of this.

Yesterday I just downloaded Microsoft Visual C++ 2010 Express from their site on my other laptop, freshly downloaded the ALLEGRO 5.0.8 pre-built binary, and that was it. I then copied my solutions over, and I can now use this second Laptop I have, exactly the same as I've been doing so on my first Laptop.

My sincere apologies if I am completely missing the point. I probably am.

Please let me know if there's anything else you suspect I might be doing which might help.

Thank You Again. (Smiley Face)

And that's also what's your project setup, I see in the Debug Properties that you have specified "MT (Multi Threaded)"....so I am unclear as to why it's asking me the MSVCR100D.dll

But, as I said (actually I forgot to update my previous post, so nvm), the executable does not match the source code...this is what I see when running it.

{"name":"607396","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/8\/98586135d057555bce4545a509f831a8.png","w":656,"h":518,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/8\/98586135d057555bce4545a509f831a8"}

(so similar to Mike Geig's tutorial output )

...so it's entirely possible that this exe is comopiled with MD option...since there's also Allegro monolith DLL in the exe folder.

I see nothing fishy in your solution's option and such, i'll try my last resource, using the same compiler as yours (I'm runnig with MSVC11, namely Visual Studio 2012).

EDIT: just a stypEd question...in VS2010, which kind of project you selected when doing "new project"?

Damn, What A Plonker I Am.

Sorry I forgot to sort this out. Shouldn’t be a problem though.

I modified an old Project folder deleting that .cpp file.

I accidentally forgot to recompile in debug mode.

The correct .cpp file is in there.

If you look in the release folder the correct .exe will be in there.

Also if you open the solution folder it should open in MSVC 2010 with the correct .cpp and in the project settings you should be able to see all the Static Link setting up as per the Wiki.

Again sorry for the miss communication on my part. (Very Naughty Face To Me)

EDIT: Windows application. Not console application.

Release Mode, yeah right.

Okay I tried your original EXE file and....tah-dah I can experience you problem as well!

the "cube" has a VERY noticeable delay and -some-everytimes it changes direction way after the keypress.

THIS has surely something to do with the kind of project you've setup...could those be "CLR console application" or "Win32 application"?

Would you try this with an "Empty Project" template, please?

I'm EXSTATIC. Let me calm down for a minute.

Edit Yes I believe I've been selecting: Win32 application. There might have been other settings as well but I can't remember.

Anyway I'm at work and will have to wait until I get home in about 2.5 to 3 hours from now.

If your experiencing the same thing though and from what you've said, it's looking very exciting for me.

I'll report back when I get home.

I'm still feeling a bit queasy. Yippy. (A Face You've Never Seen Before)

Well, I tried to hack down a Win32 app template with my version of the code and in VS2012 it does NOT (It DOES, dumb me) replicate the exe behaviour.

Awesome. Thanks so much for all this.

NOW I'm confused....after dablling with the win32app template and replication your problem with MY code (namely commenting out al_draw_textf does indeed show the delay in response)

...also MY ORIGINAL project shows the same behaviour!

I can swear for the life of me that this did not happen EVER in that project before trying this out.

Also: you can add a second and a THIRD call to al_draw_rectangle..this does NOT eliminate the lag as instead al_draw_textf does.

What the HELL is going on here?

I'm in tears with laughter, hang on a minute I can't breath.

EDIT: I don't know what to say except: Thank God I'm not on my own.

I'll await your response and just don't know what's happening next. (That Simple Looking Face I Like To Pull)

Well, I could just go on and kill you on laugthers then.

Wanna know the better part of it? I did a clean reboot of the system, tried out my original code and....the problem persist, can't get rid of it EVER w/o resorting to the al_draw_textf.

Saying that I'm amazed is a serious understatement.

Well I'm glad your on the case and thank you.

I'm still crying a bit though, but starting to calm down.

Well, I seriously thought I simply did not notice this before but....I would have if the problem showed itself, it's simply impossible not to spot it.

There's surely something happening in between the threads that are filling up and draining the Queue.

Dunno why actually, this is far beyond my means right now (and for the foreseeable future)

Sorry for the delay. Hadn't spotted this went onto page 3

Just to confirm: Are you getting the same results whichever version of the compiler you use, and no matter what you change, the problem still shows itself.

Oh, I was just trying it out with TDM-GCC 4.7.1 and I run into exactly the same problem, go figure.

I now seriously think that I were drunk in my previous trials and didn't notice the problem, 'cause I'm damn sure I tried with and without the al_draw_textf call.

Actually it DOES matter what I change, meaning that the aforementioned call to al_draw_textf solves the problem.

But I can't be sure on WHY it does indeed.

And I can't try this on an XP machine....

EDIT: weird typos

EDIT2: putting an al_rest(0.000001) solves the issue as well on my machine with both MSVC11 and TDM-GCC 4.7.1</code>

EDIT3: I've also setup a Timer, and used it to time the event_queue drain, with al_wait_for_event, and...well the problem persists IF I keep al_set_new_display_option(ALLEGRO_VSYNC, 1, ALLEGRO_REQUIRE), while if I comment out the VSYNC request it all works okay (input-wise, of course display is a bit jerky not being synched with vsync nor with the timer itself).

I'll stop for now, but MAYBE I'll be able to dabble a bit more into it.

pkrcel, are you capable of building your own Allegro binaries?

I did, on my own PC, this one is my company's one and I used precompiled binaries.

EDIT: well okay, I mean this one I'm using right now....

Well I can say for my XP computer at work after testing again this afternoon, it definitely has Never Ever displayed this problem at all.

Well if this isn't some kind of ALLEGRO glitch then I don't know what is.

I'm probably going to try reading the keyboard state for the most important keyboard presses, or just use a small al_rest() like you have found out.

Incidentally and I wasn't going to mention it in this thread: But I had another issue over a week ago using the mouse, and within my loop it was possible to end up in a situation where al_flip_display() was called, without having drawn anything new to the screen at all, and it caused a very similar unexpected delay.

It took me ages to find out this was the cause, and I ended up trying al_rest(0.001) which fixed the problem. The only thing is though I suppose using al_rest() for any very small amount of time, could cause issues on old computers which have relatively poor timers if they were to wait for say 0.010 as a minimum. I ended up just avoiding the possibility of the loop calling al_flip_display(), without drawing something first.

From your Edit3: Yes definitely, disabling Vsync stops any issues, but I want to use it though. (Some Face Not Been Invented Yet)

EDIT: Also yes, I found out that behaviour with al_wait_for_event() a timer and Vsync as well. I think I described it in an earlier entry in this thread. I bravely declared I believed there was a BUG with using Vsync in various ways. Perhaps there is. What do you think.

I'm leaving for home now. I'll refresh in 30 minutes. Edit

EDIT 2: I've just created a new Empty Project i.e. not CLR or Win32 just to be sure, but as you've already said, it makes no difference.

I didn't mean that vsync was guaranteed to work on all platforms, because it is not, and that is another reason you don't want to rely on it. What I meant was that vsync has no bearing on the event queue.

Don't be so literal. I meant that the queue is being simultaneously reported as empty yet its sources are backed up, hence it is backed up as well. It's obvious there are events not being processed in a timely manner.

@GaryT - why don't you attach your exe that exhibits this behaviour so others can run it. There's a really big attachment button above the post editor body.

Like I said, I can't reproduce this anymore. And the behaviour changed if I added or removed code, like an al_draw_textf call.

Edit

Vsync shouldn't have anything to do with it, yet I replaced vsync with al_rest(0.16) and it doesn't lag anymore. The lag is still really hard to reproduce, and it only comes with a totally bare example. However, I added in a call to al_wait_for_vsync() and then the delay is gone.

If there is a difference between A5's auto vsync and al_wait_for_vsync that might account for it but the auto vsync likely uses al_wait_for_vsync. IDK, but I'll look at it more later.

That's typically caused by a memory/buffer under/overflow bug.

@Thomas - if that was the case, where to even look for it?

http://en.wikipedia.org/wiki/Memory_debugger

Guys, I've just rebuilt Allegro with MSVC11 to the last git.

Where to look for checking if the background thread is properly backing up the queue?

Actually I have his executable, he just shared it on a skydrive, you should be able to find it attached(....If I don't screw things up...are executables accepted as attachments?)

On my Win7 rigs the exe file shows lot of lag in input.

Okay, I tried the exe you attached, and it does it for me too. It is very noticeable. Whoever built it shouldn't use such a large window though, it overflowed my screen and I couldn't touch the title bar. Kind of annoying.

I'm getting the latest git setup to build, and I've downloaded a few memory debuggers that Arthur pointed out.

I concur.

I'll be damned but I have a further problme building ith the vorbisfile library....grrrr

EDIT: well, I'll just skip the examples and getback on them later....

Nobody ever passed this through gdb / dbx / whatsoever debugger ?

Define "this"

That exe does not lag for me on Windows 7... what sort of graphics cards do you people have?

I mean, you have a problem with some code, it's clearly not easily visible.

Anytime I have that kind of problem I shoot them with a debugger.

gdb, dbx, dbx -check all should have been tried a long time ago, seeing the amount of post in the thread.

What Thomas said is also right: when I hencountered a problem where a textprintf or debug release fixed it, it was memory corruption or pointer mess that I could kill with the debugger. Note that the app itself was not crashing.

I don't say the problem will be evident, but being sure of the state of your pointers / memory is a good start to kill funky behavior.

Edit: and with what SiegeLord says: what kind of video driver you also have with it ?

I don't know what I would do with the debugger - it doesn't crash and I don't know what to inspect.

Specs - Vista, ATI Radeon X1270 (built in)

This made me curious, so I tried running it with the built-in intel graphics adapter and....it does NOT lag!

While running with the (defualt) NVIDIA GEFORCE 610M does indeed lag.

Then again, my work laptop has a built-in Intel graphics card as well, and DOES lag.

Sensible advice, but please apply it to the actual case, because the User code showed no "hot" code whatoever, so we were trying to nail down the thing on an upper layer of abstraction, meaning we even questioned about allegro itself...

Edgar:

For the 'why' a debugger, thought the topic isn't directly related, I quote one from stackoverflow:

Attached is a diff to Allegro source to stick a printf inside the place that first receives Windows keyboard events... also attached is a modified test file from earlier in the thread (also with a corresponding printf). Try running that, I guess, and see if there's an obvious discrepancy between the Windows event and Allegro event arrival times. Additionally, it may show that the delay happens before Windows events even arrive, which limits the number of things that can be done from Allegro's side of things...

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

Well, I know for sure that I have different Intel drivers on my laptops (since work's one is Dell and does not allow me to download generic GFX driver from Intel...even thou the chipset is the same), so that seems something very likely (and maybe corrected in a more recent version of the driver?)

I am able to reproduce the problem with my build of allegro 5 and the OP code.

Trying to see what I can shotdebug.

Here Winx64 Intel + Ati 5500 , gcc version 4.6.1 (GCC), latest mobility drivers, all up to date.

It's not saying so much so far, even when I play with the code. I'm as you with it for now.

Edit:
Wow, I didn't saw allegro uses a tons of threads / mutexes for a single loop.

All my projects are still linked to a4. There was at least half less threads / locks with it.

In case your curious I spoiled what it looks like in gdb.

Allegro 5 does not, itself, use significantly more threads than Allegro 4. I don't know where those are coming from, but they're not ours.

Well then, I newly compiled Allegro with Siegelord's patch, while updating my GFX drivers....and the provided example with printf as well.

I am unable to get again the unresponsive inputs whichever GFX adapter I choose, confirmed by the printf logs:

Win Event: 83 0.631955
Allegro Event 83 0.648214
Win Event: 82 0.732805
Allegro Event 82 0.748350
Win Event: 83 0.833111
Allegro Event 83 0.848606
Win Event: 84 0.850112
Allegro Event 84 0.865288
Win Event: 82 0.951312
Allegro Event 82 0.965720
Win Event: 83 1.050036
Allegro Event 83 1.066165
Win Event: 84 1.099826
Allegro Event 84 1.116000
Win Event: 82 1.132794
Allegro Event 82 1.149312
Win Event: 83 1.316879
Allegro Event 83 1.333064
Win Event: 85 1.333785
Allegro Event 85 1.349995
Win Event: 82 1.416838
Allegro Event 82 1.433294
Win Event: 83 1.600825
Allegro Event 83 1.617229
Win Event: 85 1.617944
Allegro Event 85 1.633851
Win Event: 82 1.717805
Allegro Event 82 1.734039
Win Event: 83 1.818855
Allegro Event 83 1.834302
Win Event: 85 1.834871
Allegro Event 85 1.850994
Win Event: 82 1.952021
Allegro Event 82 1.967972
Win Event: 83 2.051822
Allegro Event 83 2.068397
Win Event: 84 2.135885
Allegro Event 84 2.151752
Win Event: 82 2.369903
Allegro Event 82 2.385716
Win Event: 83 2.469870
Allegro Event 83 2.485830
Win Event: 84 2.552880
Allegro Event 84 2.569364
Win Event: 82 2.587620
Allegro Event 82 2.602811
Win Event: 83 2.836985
Allegro Event 83 2.853360
Win Event: 82 2.853887
Allegro Event 82 2.870102
Win Event: 83 2.920896
Allegro Event 83 2.937080
Win Event: 85 3.070914
Allegro Event 85 3.087349
Win Event: 82 3.121911
Allegro Event 82 3.137384
Win Event: 83 3.222006
Allegro Event 83 3.237620
Win Event: 85 3.238071
Allegro Event 85 3.254403
Win Event: 82 3.306905
Allegro Event 82 3.321270
Win Event: 85 3.405924
Allegro Event 85 3.421426
Win Event: 83 3.471902
Allegro Event 83 3.488242
Win Event: 82 3.521884
Allegro Event 82 3.538340
Win Event: 83 3.706044
Allegro Event 83 3.722122
Win Event: 84 3.723106
Allegro Event 84 3.738826
Win Event: 82 3.873242
Allegro Event 82 3.889200
Win Event: 83 3.906942
Allegro Event 83 3.922599
Win Event: 82 4.207265
Allegro Event 82 4.223381
Win Event: 83 4.290994
Allegro Event 83 4.308944
Win Event: 82 4.425650
Allegro Event 82 4.440520
Win Event: 83 4.592243
Allegro Event 83 4.607661
Win Event: 85 4.608001
Allegro Event 85 4.624279
Win Event: 82 4.742402
Allegro Event 82 4.758023
Win Event: 85 4.859051
Allegro Event 85 4.874878
Win Event: 82 4.942985
Allegro Event 82 4.958534
Win Event: 83 5.108969
Allegro Event 83 5.125586
Win Event: 84 5.125958
Allegro Event 84 5.142174
Win Event: 82 5.243130
Allegro Event 82 5.259198
Win Event: 83 5.292998
Allegro Event 83 5.311233
Win Event: 85 5.494492
Allegro Event 85 5.509707
Win Event: 82 5.509974
Allegro Event 82 5.526480
Win Event: 85 5.577616
Allegro Event 85 5.593233
Win Event: 83 5.594764
Allegro Event 83 5.609959
Win Event: 82 5.710989
Allegro Event 82 5.726949
Win Event: 83 5.828702
Allegro Event 83 5.843872
Win Event: 85 5.845399
Allegro Event 85 5.860559
Win Event: 82 6.012011
Allegro Event 82 6.027609
Win Event: 83 6.129025
Allegro Event 83 6.145101
Win Event: 84 6.196034
Allegro Event 84 6.211404
Win Event: 82 6.361971
Allegro Event 82 6.378481
Win Event: 83 6.580532
Allegro Event 83 6.595614
Win Event: 82 6.697039
Allegro Event 82 6.712635
Win Event: 85 6.713115
Allegro Event 85 6.729426
Win Event: 83 6.730178
Allegro Event 83 6.746063
Win Event: 82 6.980547
Allegro Event 82 6.996772
Win Event: 85 6.997067
Allegro Event 85 7.013363
Win Event: 82 7.081048
Allegro Event 82 7.096853
Win Event: 82 7.265169
Allegro Event 82 7.280588
Win Event: 84 7.348078
Allegro Event 84 7.364206

BUT, the original GaryT example still lags in inputs as before....with some inconsistency...sometimes it just runs okay with both GFX cards, but it's really really rare (I think I tried some 40 times already).

Going to sleep now....

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

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.

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.

al_get_keyboard_state(/*...*/);
al_get_mouse_state(/*....*/);
al_wait_for_vsync();

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.

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.

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"

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

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?

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

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.

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.

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.

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.

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.

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?

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 .

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

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.