> prevent performance collapse by just not processing more than N message queue events per frame. N=5
Why is this an issue? Your mouse is sending raw input 80,000 times per second to a screen that can only display 120 pictures per second.
Kinda sounds like an arbitrary problem that people who believe 8k mouses are necessary would worry about.
Also they probably ended up where they were because if I remember correctly windows will 'smash' mouse move events together for you in some cases. This will look like 'lost messages' (I recognized the peek loop as I have done that same thing once). This is is for two reasons one old not needed as much any more, and the one they found out the hard way. Memory as just scrubbing the mouse around would create a ton of memory objects that need to be pretty much cleaned up right away. The second is performance. As that is a ton of little messages that need to be picked up looked at and something done with. Which zorches your CPU.
The core of the issue is trying to wrap polling style of logic into an event based system (which windows is at its heart). There is no real pretty way to fix it.
That would take care of the memory issue. It would need a way to tell the kernel to not send wm_* messages about it and a way to give the kernel a buffer to hold that data. However, you still have the overhead of processing the 'events' though or keeping up with the buffer.
It occurs to me that it may be possible to disable the wm messages. There is probably a callback hook location. Set that to 0 and it would probably not send anything. But that is just a guess and I would have to dig around in the docs to see if it is there. This indicates it is possible https://stackoverflow.com/questions/57008742/how-to-discard-... Then it would be up to you to use one of the other raw APIs to find out what is going on. https://learn.microsoft.com/en-us/windows/win32/winmsg/mouse... https://learn.microsoft.com/en-us/windows/win32/winmsg/about...
yeah. I would be the old win3.x/2.x code probably just hung out on the ps2/serial bus interrupt waiting for junk to show up. Then sending a messages along when it happened. That 'behavior' would have to stick around for MS to hit its backwards compatibility goals. Either sampling or event spamming with a debounce buffer.
Simulation resolution needs to be higher than display resolution. Simulating physics at only 120Hz can lead to jank. This is similarly true in the spacial dimensions, where even old games would run the game simulation at more than 640x480 for fidelity.
> Your mouse is sending raw input 80,000 times per second to a screen that can only display 120 pictures per second.
8 thousand, not 80 thousand. Many screens can display (much more) than 120 frames per second - My monitor goes to 240hz, there are 300hz displays available.
Rendering rate is very often not tied to game update rates - games can update their state at significantly higher rates than they display. A decent number of games have a "high level" skill of doing things like "pre-shooting" where the winner of a fight is done by figuring out "who realistically did it first".
Assuming that you can poll at 125hz is wrong.
> Why is this an issue? ... Kinda sounds like an arbitrary problem that people who believe 8k mouses are necessary would worry about.
People have these devices and run our games. We (unfortunately) need to handle them, just like a website needs to handle a poorly behaved client. Also depending on _when_ you sample, (i.e. which 5 messages you handle), you can get incorrect information from the device.