   Any reason not to use an event-based input handling system?
  So I've been refactoring a whole lot of old code to use with a new project and I'm pretty happy with the results, but one of the things that's really driving me crazy is the way I dealt with input handling. My old code had a simple wrapper around DirectInput that I polled once per frame to check on the state of the input devices. It works fine, but I got to thinking than an event-based system might work even better. Last night I spent a little time messing around with the code and I implemented something that I think works pretty well, but I'm looking for criticism before I get too comfortable.First of all, the new system ditches DirectInput and just grabs WM_ input messages directly. I have a simple "translator" class that's called from the application message procedure whenever a message of interest comes up. It fills out a custom message struct and then passes the struct along to a MessageHandler object. The translator also keeps some state information so it can properly differentiate between input events (ie, between pressing a key and holding a key).Meanwhile, the MessageHandler keeps a list of registered observer objects and queues up the message structs it receives. It ticks once per frame, going through its registered observer lists and passing out messages until they've all been consumed or there aren't any more messages to process. Observers each implement a RcvMsg method that takes my custom message struct, so objects that need to receive input just need to pull whatever information they need out of the struct and do the appropriate thing.It seems like this kind of system has a ton of advantages, so I'm wondering if there are any major downsides I'm not seeing. It's certainly more expensive than just polling a keyboard/mouse object once per frame, but I'm guessing the performance impact is pretty trivial compared to something like an AI or rendering subsystem. I'm also loving the fact that it took me all of five minutes to implement a "dummy" input generator that recorded key inputs and then played them back once the system was up and running.So... what do you guys think? Decent way of doing input handling or terrible for some blindingly obvious reason that I've missed?   
  Very reasonable. Most well-written codebases' input handling code is along these lines. Consider using a signal/slot library like boost::signal or (cough) my thing to implement the observer pattern; it can really make things nicer-looking.   ;Quote:Original post by Sneftel(cough) my thing to implement the observer pattern; it can really make things nicer-looking.Awesome, I'm checking this out now. I'm actually already making pretty heavy use of boost libraries in my code, so I'm a little bit disappointed to hear that signals is so slow. I'm not too familiar with it, but it looked interesting and I was planning on reading up on it later tonight.   ;  For your purposes (one signal invocation per input event) boost's invocation time would be negligible. It's slow, but it isn't that slow.   