If you've ever actually tried organizing this inside of a message handler in the scheme of what seems like a "Good Design," then I'm sure you understand the problem here. The problem being that, at least in my case, the actual code which processed (relied on, dealt with, so on) was not, in fact, in the message handler. So there was this flood of input being gathered and the app had nothing much to do with it. It was around this point, which took far longer than it really should have to arrive at, that I realized I might have to violate the original design a bit to include some functionality for capturing the mouse in a window and holding the cursor to the center of the screen. I ended up with a "fake capture" -- so I'll still send the framework-wide flag that the mouse had been captured and various components could do their thing, the cursor graphic would be hidden by the OS, and the cursor position would continually be set to the center of the window after I nabbed the delta position from the frame prior.
I know I've done all this stuff before. At least, I think I have. In retrospect, I may have just looked at example programs and thought "Oh. Hey. This works. I'll just liberate this snippet." Such a course of action is, of course, not acceptable under my current coding laws for Rawr.
None of this stuff makes for a good screenshot and the camera code I'm working on isn't to the point where I can actually move around a scene in a "correct" free-fly first-person camera fashion, so here's a comparison shot between an MD5 mesh from DOOM 3 being lit by vertex normals (on the left) and by a normal map (on the non-left):
