SDL mouse events

Lucas wrote:

Note that the SDL_Get*MouseState API functions don’t help since these
still query the SDL event queue. It would be nice if these calls simply
passed through to the platform specific mouse query functions directly.
Obviously this approach is mutually exclusive with handling mouse events
on the SDL queue, so it would need to be disabled. I think this is what
is required to placate the twitch-shooter brigade :frowning:

However, I was under the impression (without actually looking at the
evidence) that 1.3 had fixed this issue with ManyMouse stuff? Is this
not the case?

&&
Sam Lantinga wrote:

Yes, you’re always welcome to ignore the events using SDL_EventState()
and they won’t fill the queue, but you’ll still be able to poll the
current
position.

Aren’t these two statements contradicting?

Is it possible that I’ve completely missed a big chunk of functionality
here? Yes. I’ll experiment later tonight.

Hmmm. Does this mean that in 1.3 the mouse input is still gathered using
a thread? This is one of my biggest gripes with 1.2. The problem is that
if your input gathering rate differs from your game’s framerate (which
it almost always will), you get beats in the mouse input.

SDL doesn’t have an event thred by default. I think what you’re seeing
is Windows collapsing mouse motion events in the event queue if you don’t
process them fast enough.

SDL 1.2 uses the non-DirectX code by default, for the best compatibility,
but you’re welcome to try out the DirectX driver (putenv(“SDL_VIDEODRIVER=directx”)),
which uses DirectInput, and see if that improves things.

See ya!
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment

Thanks, that did the job.

At 5Fps, I get 96-102 mouse events when moving the mouse, meaning a razor
mouse would fill the queue.
I don’t understand why key events did queue up properly without
SDL_PumpEvents() as I read it they shouldn’t.
Windows XP btw.

Also, my mouse only has a 500Hz sample rate(just checked it and it seems
consistent with the 96-102 at 5fps).
1000Hz is quite common under FPS gamers.

As I see it now its like this on WinXP
Mouse motion events are put on the queue at a maximum rate of the rate you
call SDL_PumpEvents().
I expect relative mouse events to be relative to the last mouse event on the
queue (and not relative to the last ‘hardware’ sample)
but I haven’t tested this yet.
So calling SLD_PumpEvents() at the rate of your framerate or disabling mouse
events and calling SDL_GetMouseState should keep the queue from filling up.

Did I understand this correctly?

I don’t know why key events can exceed the max rate.

“Sam Lantinga” wrote in message
news:E1JbHi4-0000dP-2j at seras.devolution.com…>> Hmmm. Does this mean that in 1.3 the mouse input is still gathered using

a thread? This is one of my biggest gripes with 1.2. The problem is that
if your input gathering rate differs from your game’s framerate (which
it almost always will), you get beats in the mouse input.

SDL doesn’t have an event thred by default. I think what you’re seeing
is Windows collapsing mouse motion events in the event queue if you don’t
process them fast enough.

SDL 1.2 uses the non-DirectX code by default, for the best compatibility,
but you’re welcome to try out the DirectX driver
(putenv(“SDL_VIDEODRIVER=directx”)),
which uses DirectInput, and see if that improves things.

See ya!
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment

As I see it now its like this on WinXP
Mouse motion events are put on the queue at a maximum rate of the rate you
call SDL_PumpEvents().
I expect relative mouse events to be relative to the last mouse event on the
queue (and not relative to the last ‘hardware’ sample)
but I haven’t tested this yet.
So calling SLD_PumpEvents() at the rate of your framerate or disabling mouse
events and calling SDL_GetMouseState should keep the queue from filling up.

Did I understand this correctly?

Yep. :slight_smile:
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment