How to handle keyboard repeat counts?

[robfinch]

Does anybody bother with key repeat counts in messages? Windows has a repeat count field in the key message. I am pondering how to modify the keyboard message that has already been sent to adjust the repeat count. Every time a key repeats without a keyup it should increment the key’s repeat count in the message as long as the message has not been processed yet. The key message that was sent could be made available by returning the message handle from SendMsg(). But then there is no guarantee that the handle is still valid by the time processing occurs on it; it may have been dequeued and processed already by the receiving mailbox thread. Worse yet, the message may have been reused. To get around this, the keyboard mailbox could be locked and a search take place for the message in the mailbox queue. But this seems like a lot just to support a repeat count.

[robfinch]

I implemented a repeat count for *all* duplicated messages. If the last message queued at a mailbox is exactly the same as an incoming message, its repeat count is incremented and the new message discarded.

[eekee]

What would use a key repeat count? Maybe something wants to go faster or futher the longer a key is held down, but I'd implement that by noting the time the key-down message was received. I might instead want the key-down message to have a timestamp; this may be better in high-latency conditions. I can't see a use for keyboard repeat count.

I woud never modify an event if there was any chance it had been received, and I'd prefer not to even check; I want to put it in a queue and forget about it, but I've just thought why Microsoft may have done it this way. If an event is queued but not received, it uses less RAM to increment a counter in the event rather than queue another event. This made sense in the 80s when Windows was operating in excruciatingly small amounts of RAM. It made far less sense in the 90s already.

Do duplicate messages ever come fast? Mouse movement makes the most event spam in my experience, but those events are never the same twice. You might get redraw message spam if something's being dragged over your window if you don't have a back buffer, but that would also never be the same twice, and the code which increments a repeat count should also merge the redraw regions. Given that a complete absense of redraw clipping -- simply drawing whole windows from lowest to highest -- was good enough for Plan 9 in the 90s, I wouldn't bother. Key repeats are pretty slow compared to mouse messages.

[robfinch]

but I've just thought why Microsoft may have done it this way. If an event is queued but not received, it uses less RAM to increment a counter in the event rather than queue another event. This made sense in the 80s when Windows was operating in excruciatingly small amounts of RAM. It made far less sense in the 90s already.

Yes, that was the only reason I could think of too. The only other thing is if the keyboard controller reported back a repeat count and it was simply copied to the message.

It was only a few LOC to add a check for the last message queued versus the incoming message to increment a repeat count. My system has a very limited number of messages.

I noticed Windows includes the graphics co-ordinate in messages. My OS was not doing that. I added it, but am wondering what to use for the type for a co-ordinate. Using doubles or floats instead of 32-bit ints had crossed my mind. I am not sure if using doubles would be useful for some games. I also added a 'Z' coordinate, thinking of cursor positions in a 3-D map.

[eekee]

I noticed Windows includes the graphics co-ordinate in messages. My OS was not doing that. I added it, but am wondering what to use for the type for a co-ordinate. Using doubles or floats instead of 32-bit ints had crossed my mind. I am not sure if using doubles would be useful for some games. I also added a 'Z' coordinate, thinking of cursor positions in a 3-D map.

There's talk of 32k screens maybe within 10 years, with some mention of 64k. If you're giving pixel coordinates, 16-bit ints may become obsolete in the next 20 years. If you're going into 3D space though, I don't know. As far as I understand, the precision of floats in 3D is mostly for making adjacent surfaces look connected. They went to doubles as screen resolution grew. Does a pointer need that level of precision? Maybe not, but if you're plotting positions in a 3D scene, you probably have floats or doubles you might as well pass on. If you have a cursor in 3D space, that cursor can get lost in the distance or behind things. There are ways around that, maybe a pointing line and a beacon, but it doesn't seem as practical as mapping a 2D cursor position into 3D space in userspace. The userspace program which generated the scene may want to register clicks on hit-box, hit-sphere, or exact surfaces. It may want many objects to be ignored to make other obects easier to click. And, of course, it may want to map a pointer position or have a cursor in 3D space. All that is fairly easy to design in userspace, but would complexify an OS interface. So I guess I've talked myself out of passing a Z coordinate, but what you do is of course up to you. If you've still got reasons to include a Z coordinate, I'd be interested to hear them. I particularly have no experience with 6DOF controllers; haven't even done thought experiements there.