Bold words, but I challenge you to prove me wrong [grin]. I have finally made a SDL input library that wraps up a lot of the functionality of using input in SDL (of which I have numerous posts scattered about covering all of the various aspects). Anyways, here it is, it comes with the library header and cpp file as well as a complete demo cpp file showing how to use it all. I will be adding it to my web page eventually. If you have any questions or comments about it, feel free to share! If you find any bugs, annoyances, or anything that you'd like to see changed, I'm open to all suggestions as well. I will be working with this a bit as part of my SDL engine I am working on, so I will be adding fixes and updates here and there. I will also make some more advanced demos of showing what you can do with this as well for those looking for some neat things to do with it. Enjoy! [smile] Download Input Library + Demo (7.98kb) Now for some quick FAQs: Q - How do I integrate it into my current SDL project A - Integrating the library into your current project is very simple. Here are the steps: 1. #include "Input.h" 2. Add Input.cpp to the project work space so it is compiled 3. Create a derived class from the Input class 4. Overload the member functions you will want to use (OnKeyDown, OnKeyUp, OnMouseMove, OnMouseButtonDown, OnMouseButtonUp, OnMouseWheelUp, and OnMouseWheelDown) 5. In your event polling loop, call the Poll function, passing in each event. 6. After the polling has been completed, call the Update function. 7. Now you are ready to use the class and its functions! Q - What license is this released under A- The good ole' ZLib license, which means you can use this in your [4E4] entry without any problems if you take the SDL approach. Still note that SDL is released under the LPGL license and you must link dynamically to it. Q - Do I have to derive from the Input class? A - No. The functions are non-pure virtuals, so it is optional if you want to use that functionality. Q - Speaking of functionality, what does this input library provide A - Right now it has complete functionality for the mouse and keyboard. Joystick functionality will be added later. Keyboard Functions: IsKeyDown, SetKeyUp, SetKeyDown, OnKeyDown, OnKeyUp Mouse Functions: GetMouseX, GetMouseY, SetMouseX, SetMouseY, SetMouseXY, IsButtonDown, SetButtonUp, SetButtonDown, OnMouseMove, OnMouseButtonDown, OnMouseButtonUp, OnMouseWheelUp, OnMouseWheelDown Q - So how does it all work? A - This input system works to be as accurate as possible, which is why the Poll method has to be called. The library uses a buffered input style of processing. As events are sent into the Poll function, if they are input events, they are send to the input buffer vector. After all have been collected, the Update function then goes though and processes all of the data. It will call the On_XXX functions when necessary for each event and then remove the events from the buffer. The system is made for advance users as well, so if events need to not be removed from the buffer, that too is possible with the design (return false instead of true in the On_XXX function). Q - Any other extras? A - Yes! Each event comes with a time stamp if you want to use that for input tracking for use in a replay system or whatever you want to do. That information is avaliable in the On_XXX functions. Next is the way the SetMouseX/Y/XY functions work. It is known that when you simply call SDL_WarpMouse events are generated which throw off your camera looking in FPS games. I have come up with a little way of taking care of that so that problem is no longer and issue. Finally the library is made so it is very clean, easy to use, and well documented. Perhaps a little over commented, but there is no way anyone reading it will have no idea of what is going on. [edit]Updated link to my UTD space...I really need to fix all my links on GD [Edited by - Drew_Benton on December 13, 2005 3:39:07 PM]

Anyone? [sad]

Looks nice and clean, if I use it I'll be sure to tell you about any bugs.

All in all, looks like a handy little class. :)

I have one too http://svn.dsource.org/projects/warbots/trunk/current/core/input.d , but it is written in the D language. You still should be able to understand it, to a certain degree. It doesn't only handle all mouse/input, it handles screen resizing (using input to resize the screen), to test against keyHit (one action per key) vs KeyDown (for machine gun effect), mouseHit, mouseDown, keeping track of 2D coordinates vs 3D ones for the mouse and keeping 2D mouse coordinates relitive to screen size, and the handling of all modifiers plus support for typing, returning the character of the last key you hit, so that you can type in an input box.

edit: forgot to mention, handles wheelUp and wheelDown

Quote:Original post by Endogenous
Looks nice and clean, if I use it I'll be sure to tell you about any bugs.
All in all, looks like a handy little class. :)

Thanks, if you do use it tell me how it works for you. [wink]

Quote:Original post by Ademan555
Very cool Drew, i'll be sure to check it out when i get done with this yard work im avoiding :-) But out of curiousity, have sdl's events been deemed reliable enough for game use?

With the default SDL event processing, probabally not for high event games. However, someone has made a little LPGL library that makes SDL process more events, so it is much faster. What I am talking about is FastEvents. At first I thought it didn't do much, but I just tried it out, and wow, it works great. Without the library on the thread4.c program (with SDL_net removed) the app was processing 20,178.346496 events a second. However, when the library was used, the events processed a second rocketed to 54067.893211. And that test was the app just running without any events being sent! When I sent in a lot of events though mouse and keyboard, the numbers were a little lower, but it ended up around 19k vs 53k. Now there's a big difference between those two numbers, so I can say at least, I am not worried about not being able to handle SDL events anymore [smile].

Quote:Original post by clayasaurus
I have one too, but it is written in the D language. You still should be able to understand it, to a certain degree.

Cool! D looks really similar to C [lol]. Not too bad of a library either [wink]

Anyways, if anyone uses this and finds it useful, I'd love to hear about it. I have not update anything yet officially, but I have added in joystick support. I'm still testing that out and debugging it, but when I get that done I will put the complete library here. I'm also working on a SDL game engine (which is why I made this input library) so I'll just tack on that project if it's done to this thread and add it my sig.

Quote:Original post by Promit
I use the asynchronous input system, and read the entire keyboard once per frame. Buffer the results one frame, and you can determine if a key was just pressed/unpressed, and whether it's down right now or not. No callbacks, those things are damned annoying. So if you want to know what's going on, instantiate a keyboard and a mouse and just read from them.

Thanks! [wink] My old methods of input worked in a similar way, but I did not think about simply buffering those results - I just used them as they came. Hmmmm, that's a good idea [lol]. What I've read though is that it's possible that you end up missing events with though functions though (something from Sam on the mailing list) when you just use the data as is, but your buffering idea should take away that disadvantage. I have not had a project that I've used any of this stuff in yet to compare the two, so I will see about that. Promit, kudos for the good ideas as always [grin].

This is kinda like my input system for my upcoming 4E4 game, except I'm using GLFW and mine is waaaaaay cooler :P (tehe).

Quote:Original post by evolutional
This is kinda like my input system for my upcoming 4E4 game, except I'm using GLFW and mine is waaaaaay cooler :P (tehe).

Shush you! [grin] I remember last time I used GLFW, basically all the input functions are there right? You just gotta wrap them up into a nice neat class, correct? I think in those little learn GLFW examples I've seen, the input can get quite klunky if it's not wrapped up. I'll have to take a look at your libary sometime later to see just how cool it is [wink] Are you gonna make your code avaliable later on? (And I have still not looked that the old messaging code you sent me like 4 months ago [headshake])