10/15 keyboard input, from host events through to window messages - #11
Conversation
| } | ||
|
|
||
| /// Byte offset of a mouse object within the standard c_dfDIMouse data format: | ||
| /// lX@0, lY@4, lZ@8, then one byte per button from 12. |
There was a problem hiding this comment.
I don't follow this, why not use a regular struct?
| }; | ||
| // Games poll for messages every frame; keep the audio mixer fed from here | ||
| // too, in case the app renders without flipping. | ||
| crate::dsound::pump(ctx); |
There was a problem hiding this comment.
I like this solution, but I wonder what the more principled thing is, like what does Windows itself do? Are we missing a thread that causes dsound to pump or something? (I don't think we need to add one, I am just trying to understand.)
5eecfa3 to
aec9844
Compare
|
The mouse offsets are a On pumping from the message loop: I do not think we are missing a thread, and I think Windows genuinely has no equivalent of one. On real hardware the sound card DMAs straight out of the DirectSound buffer, so mixing happens below the app entirely and nothing in its process has to run for playback to advance. There is no thread to reproduce, so the choice is between a mixer thread of our own and advancing the mixer from somewhere the app passes through anyway. I went with the second because a thread would have to read guest memory while the guest writes it, and the only place the two are ordered against each other is the message pump. It is a stand-in rather than the principled thing, and if the mixer ever moves into the host (see #10) the question goes away. |
9de52f7 to
831337a
Compare
2 participants
Part 10 of 15, splitting up #1. Needs 2, 5 and 9 merged first; on its own it does not compile.