   DirectInput Module Architecture for Engine
  Hey guys...I had some ideas which I wanted to get some comments on.I've implemented this class hierarchy for the input module of the engine in which there is an InputDevice class and three sub classes (keyboard, mouse, and joystick) which inherit from it. After implementing them though, I noticed that there where two ways in which I could present them to the user. It is these two methods on which I would like your comments. The first idea was to allow users to implement objects of the subclasses and use them directly as follows:Keyboard kb(hinstance, hwnd);if (kb.isPressed(DK_ESC)) // WhateverWhen creating an DirectInput interface and its devices, you need two main pieces of data: The HINSTANCE and the Window (HWND). What I did in this case was to make both of these variable static so that they could be shared amongst all subclasses and only one lpdi (pointer to direct input interface) was created.The problem is that it does not allow for input to be instantiated for more than one HWND. Would that even be a problem though?The second approach was to create an Input class which instatiated all input devices and provided access to them through public methods. The Input class would then store the lpdi. You could then instatiate one input class per window. The problem with this approach (at least for me) was that it felt to cumbersome and looks mildly sloppy.Anyways, which method would YOU use? Option one? Option two? Or something completely different?Your romments are appreciated :)   
Quote:Original post by TheWandererThe problem is that it does not allow for input to be instantiated for more than one HWND. Would that even be a problem though?It's only a problem in two situations:1. You and your program need to use multiple windows2. You're making a general engine where you don't know how/what it'll be used for.You could possibly create a pool of (non-exclusive) devices, one for each hwnd and then "create" them via a factory. That way you should only have as many devices as you need, yet you're not tied to one window.Quote:Original post by TheWandererAnyways, which method would YOU use? Option one? Option two? Or something completely different?The DInput engine I use is callback/message based. The kernel ticks over to make sure that it keeps getting polled and when the input engine finds some new messages on the queue it fires events/messages off to whomever is interested [grin] Although, I only ever have one window as part of my setup so I don't have the issue that you seem to have...hthJack;Quote:Original post by jollyjeffersIt's only a problem in two situations:1. You and your program need to use multiple windows2. You're making a general engine where you don't know how/what it'll be used for.The engine is for myself, but I guess I just want to cover all of my bases just in case ;) (Although from what I've seen, if you need more than one window you usually make your own GUI.)Quote:Original post by jollyjeffersThe DInput engine I use is callback/message based. The kernel ticks over to make sure that it keeps getting polled and when the input engine finds some new messages on the queue it fires events/messages off to whomever is interested [grin] Although, I only ever have one window as part of my setup so I don't have the issue that you seem to have...So what happens is that modules register devices with your engine and then get a message if an input occurs? Interesting. Are there any online resources describing this type of architecture? (It sounds like the same scheme that Java uses).;  I did pretty much the same thing as jollyjeffers above with the architecture on my input system.  I basically have an input system that allows for creation of devices such as keyboard, mouse, etc.  The input is checked every game loop update and if there is anything it fires an event so that anybody registered to that event will see what happened.  I register to these in my game state and from there map actions to those events (key presses, mouse clicks, etc).You could do it quite easily in C# actually, or if you are using C++ I used the boost::signals library for using the slots/signals pattern of events.   ;  Another method would be to provide create methods for the input devices within your Input class that would return pointers to keyboard, mouse, etc. That way, you could still use the device objects directly, and the Input class would associate them with whatever window the Input class was create with.;Quote:Original post by Dave HuntAnother method would be to provide create methods for the input devices within your Input class that would return pointers to keyboard, mouse, etc. That way, you could still use the device objects directly, and the Input class would associate them with whatever window the Input class was create with.This is basically what I do, I have a device creation factory from the input system where you can do something like:mInputSystem->CreateDevice( Keyboard );where Keyboard, Mouse, XBController are in a type enum.   ;  Since I did not want to restraing myself to one window, I initially went ahead and coded the second option. It looks something like this:Input main_window_input(hinstance, hwnd, KB | MS);main_window_input.kb->update;if(main_window_input.kb->isPressed(DIK_ESX)) // Do Somethingif(main_window_input.ms->isPressed(BTN_1) // Do Something ElseThe last argument to the constructor is a set of flags which specifies which devices you want active with that window. You can have another input system for another window simply by changing the HWND. (Perhaps I should add start/stop functions to these classes...)Input second_window_input(hinstance, hwnd2, KB | JYS);// etc...I might try implementing the messaging system since it sounds like a cleaner solution.I also do like your idea, Dave, where I return a pointer which can be used by the application programmer. Something like:Input input_sys(hinstance, hwnd);Keyboard *kb_main_window = input_system.create(KB);   