>> I probably have this wrong, but this is how I see it:
>> You would want to be able to measure mouse motion of only one pixel.
>> A sample rate of 1000, constant mouse movement and a high screen
>> this would amount to 1000 events per second on the queue.
>> Lets say that some part of your 3d game runs slow on that computer (lets
>> 5 fps), that would lead to event loss.
> That's correct using those numbers, however I've never actually seen mouse
> events that always only have 1 pixel delta. Usually it's in the 3-10
> range, and depends on speed of mouse movement.
> If you think about the way a mouse actually works, it's translating some
> physical movement into screen coordinate motion, and I think you would
> a very hard time moving the mouse at exactly the right rate of speed to
> generate exactly one pixel of motion at the hardware update rate. :)
I didn't say the motion would always be 1 px/mouseSample, I just said you
would want to be able to measure a movement of one pixel (when they occur).
If you constantly move the mouse, all 1000 samples would be used regardless
of the speed.
Btw. I've seen a razor mouse which has a 1200Hz sample rate which would fill
the queue at ~10fps, which isn't unheard of.
Maybe it would be a nice addition to make the pollrate adjustible?
>> I'd rather set the sample rate of SDL to a lower frequency or
>> not let mouse events flood the queue by only accepting key events and use
>> GetRelativeMouseState for mouse movement.
> 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
Somehow I missed that one.
> See ya,
> -Sam Lantinga, Lead Software Engineer, Blizzard Entertainment
SDL mailing list