Sign in to follow this  
skwee

Wrapping SDL Input in higher level library.

Recommended Posts

Hello I'm writing my own game engine, but I can't think of abstract way to realize Input System. For now I use SDL for pretty much everything (window creation, timer, input, almost for sure it also will be the font, sound, and image libraries) but I try to abstract things so it won't be depend on particular library. I did it with Window creation, I have an abstract interface that creates window depending on the rendering API (either software, Direct3D9 or OpenGL). The interface it self is abstract (RenderWindow) and I have and SDLRenderWindow that inherited from RenderWindow and implements the interface. However with Input its a bit problem. Many will say that its not that bad to have native SDL calls in the final code, and Ill agree, I'm almost sure I wont ever implement some other ways of handling Window creation or input, except SDL, but still I want to make a higher level InputSystem interface and to inherit SDLInputSystem from it, but I don't know how. Edit: I probably didn't explain it well, so think of the following: I want to write abstract InputSystem interface and to be able to create different ways of input handling, for example SDLInputSystem, or Win32InputSystem and etc, but I don't want to mess with the code it self, I mean I want to make so abstract that changing between them will cost me only the time Ill spent to implement the Input System without changing any other code! So if in my game/3d simulation I had something like:
while(inputSystemInstance->haveEvent()){
MyEvent e = inputSystemInstance->getEventType();
//handl event here
}
And I can do one of the following:
InputSystem* inputSystemInstance = new SDLInputSystem();
//OR//
InputSystem* inputSystemInstance = new Win32InputSystem();
//OR//
InputSystem* inputSystemInstance = new SomeOtherInputSystem();
The first code wont change. I hope you got me. The language is C++ ofcourse. I would like to hear your ideas and solutions. Thanks a lot.

Share this post


Link to post
Share on other sites
I'm not totally sure why you want to do this, since SDL is already a cross-platform abstraction. I think your life will be easier if you just embrace SDL. But anyway..

One thing you should be aware of, is that on Windows, your input system is linked to your window creation. (This might be true on other OSes but I'm not sure). The way you get input events is through WndProc, and that's also the function where you get window-related events, so your window creation code probably already implements that function. So it would be tricky to mix-and-match by having one kind of input system and another kind of window system.

*Note that the above paragraph is not true if you get keyboard/mouse events through DirectInput. But that is deprecated.

If you figure out a solution for that, then abstracting away SDL is not that hard. You can create your own KeyEvent and MouseEvent classes and convert from SDL to them. The biggest pain will be creating a constant for every virtual key code, and converting those.

Share this post


Link to post
Share on other sites
Quote:

If you figure out a solution for that, then abstracting away SDL is not that hard. You can create your own KeyEvent and MouseEvent classes and convert from SDL to them. The biggest pain will be creating a constant for every virtual key code, and converting those.

Exactly! Its a very big switch-case for about 150-200 cases. This is what I wanted to do, but as you said its a big pain, and I can't think about any other way to do.
I think Ill leave SDL as it, without wrapping it.

Other suggestions would be appreciated.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this