Hi

I'm working on a map editor thing, and keyboard input works great and is responsive, but the mouse input is quite delayed.

Here is the scenario: I have a screen and when I click it puts a white box where the user clicks. The problem being after I click the mouse, there is a ~1 second delay before the box shows up. If I click and drag the mouse, all the boxes show up, but again, there is a 1-3 second delay for all of them to show up. The weird thing is, if I click the mouse and rather than dragging the mouse i use the keyboard to "move" the drawing plane then everything is immediately.

so in short: mouse input slow, keyboard input perfect...

I'm using Allegro 5.0.7 md
with a core i7 quad core
8gb ram
nvidia gtx 660m fully updated.
I'm using opengl 3.0 though i doubt that makes any difference.

Any ideas on how to fix it?

thanks adam.

I couldn't understand what you wrote.

Are you using event queues, and letting the events pile up? Moving the mouse generates a lot more events than you would get with a keyboard.

Are you draining the message queue every time? If you are only taking one message out each time, the mouse moving could be causing a flood of messages that have to come through before it gets to processing the mouse click.

You are both right.

I was only taking out one message at a time from the event queue, and thus it was backing up.

So speaking of having a backup in the event queue, is there a proper way to handle it? Or is it safe (and practical) to just take the first event off the queue and ignore the rest?

Thanks for the responses.
Adam.

You don't want to miss an event, because then you're even worse off than with polling in A4. So you really have to parse every event in the queue before drawing a frame.

I have this in my code

@Arthur: that way, you'll be drawing at each timer event, and that'll cause your program to lag behind if the drawing takes too long.

Yeah, my event-fu is weak.

Here is how I now have it, so that there is not mouse lag, (or any other that i can notice.)

I is set up so that it does logic updates 45x per second, and draws as fast as the computer will let it.

What's the point of drawing if nothing has changed?

Don't you ever write code like this?

int x = 1;
x = 1;
x = 1; // make sure x REALLY is 1

In this case you are right; in the map editor I have no need to update the display any more than when something changes.

However in the game (where I copied this from) things are a little different. I originally had it update the logic at 25 or 30 times per second. So all movement and animations where only updated at 25-30fps. So if I were to update the display only 25-30 times per second there would be a noticeable jerkiness. Rather than objects smoothly moving across the screen they would appear to skip or jump across the screen.

So by not limiting the display rate, I can calculate an interpolation value (not used in the code I posted because there is no animation nor movement) and interpolate the rendering between the last update and the next expected update. This helps the animations and movements look a lot smoother.

Yeah, I don't have anything against updating at the refresh rate, but any more than that is pretty silly as the display won't show any of it. Interpolating between frames is a pretty good idea, can help smooth things out, even if it does sort of lie about where things are on screen.

Also updating as often as you can wastes power. People on a laptop will be unhappy with you. And people with loud GPUs will be as well.

I guess when I said: "as fast as the computer will let it" I was not very clear. I do have vsync turned on, so it will only redraw the screen at the vsync rate.

Though turning vsync on is more of a hint. Graphics drivers let you disable it system wide or individually per app/game.

I guess though that then its the users fault.

I guess when I said: "as fast as the computer will let it" I was not very clear. I do have vsync turned on, so it will only redraw the screen at the vsync rate.

Did you mean to double post that?

Woops sorry, having some internet problems here at the university.