On 4/25/07, Luke Paireepinart <[EMAIL PROTECTED]> wrote:
Does anyone know how the mouse works in Pygame? how is it polled? I'd think the wiimote should be done in a similar manner.
Mice are usually interrupt driven, as opposed to polled. When the mouse moves or clicks it generates interrupts that the driver gets, and ultimately the driver queries the mouse's state and creates events that get shoved in some queue for some other layer of the system to read at it's leisure. Windows in particular though has pieces of the system that throw out what it considers extraneous movement events (it will try to replace the previous movement event instead of adding new ones if the application hasn't checked it's event queue), so even though the hardware & driver & OS take care of stuff so that you don't need to check for mouse events unless you want to read them, you do get more event data if your app checks it's events more often Because the bluetooth protocol is packet based, you don't necessarily need to worry about polling or interrupt stuff for device level information at all. Basically a bluetooth device could easily just send out n packets a second of device specific data, and it doesn't necessairly matter when some application reads that data, cause the bluetooth driver can store up some amount of packets, to be grabbed at the applications leisure. So again, the drivers and hardware do a fair bit of work so that the app doesn't have to ask for data until it's ready to do something with it. The point being it will really just depend on the specifics of the Wiimote what happens if the app doesn't talk to it for a given amount of time cause on the computer's side of things there is just a stream of data going out and a stream of data going in to some bluetooth device. I wouldn't assume that there is any necessity for an extra thread to do things at a given rate at all.
