Jump to content
  • Advertisement
Sign in to follow this  
TheWanderer

DirectInput Module Architecture for Engine

This topic is 4878 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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)) // Whatever When 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 :)

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by TheWanderer
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?

It's only a problem in two situations:

1. You and your program need to use multiple windows
2. 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 TheWanderer
Anyways, 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...

hth
Jack

Share this post


Link to post
Share on other sites
Quote:
Original post by jollyjeffers
It's only a problem in two situations:

1. You and your program need to use multiple windows
2. 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 jollyjeffers
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...


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).

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by Dave Hunt
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.

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.

Share this post


Link to post
Share on other sites
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 Something
if(main_window_input.ms->isPressed(BTN_1)
// Do Something Else

The 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);

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!