Sign in to follow this  
Drew_Benton

Unity SDL Input Library & Input Discussion [renamed]

Recommended Posts

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]

Share this post


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

cheers
-Dan

Share this post


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

Share this post


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

Share this post


Link to post
Share on other sites
Not bad, not bad, but...[grin]

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.

I've been meaning to write a layer that abstracts away the keyboard and mouse and joysticks, haven't gotten around to it yet.

Share this post


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

Share this post


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

Share this post


Link to post
Share on other sites
Quote:
Original post by evolutional
provide async input.


Since you are the second one to mention that in this thread, is async input the most preferred method for games? Is it because it's more on demand or what?

While I am at it, I was also going to ask what you guys think aout joystick support? I mean it's always there, but rarely do I see people use it. Is it good to just have it there in case, or should developers not bother and let the user add it in if they wanted to? For my engine at least, joystick support is already there and all, so I've decided to add it in.

Share this post


Link to post
Share on other sites
I don't know if I'm a special case, but I've found it useful to have both.

For example, my game input is managed with IInputHandlers, which are registered to receive input events. This is all well and good when it comes to checking for 'up, down, left, right, etc' presses and releases, but short of buffering the events locally for each object, how will you say "three keys are pressed at once"?

Share this post


Link to post
Share on other sites
The thing is though, by doing it event based, as long as you track it that is, you will achieve the same thing. Right now, as my input system is, the On_XXX are for those events that happen the first time, so they are like callbacks as Promit mentioned, but they aren't themsevles callbacks. They are functions that are just called on an event (which is done though the update function after all the events have been buffered). Basically, that is for functionality that the WM_CHAR provides. You can just process key by key if you need to. Otherwise, everything is as what the so called async functions provide, even though my system is event based. So I can have something like:

if( inputClass->IsKeyDown( SDLK_a ) && inputClass->IsKeyDown( SDLK_s ) && inputClass->IsKeyDown( SDLK_d ) )
abort();

And it works as expected. Does the fact that I store all the buffered input and process thatt way, to which I have a means similar to async input make those functions async? Not that it matters, just something to think about [wink]. In the class I do have:

std::vector<bool> mouseButtonStates;
std::vector<bool> keyStates;

that store the information so I guess I do have both means employed in my system, just though buffered events.

Share this post


Link to post
Share on other sites
Hey guys, I'm writing the input class for an open source game I'm working on called Epiar ( www.epiar.net ) and I'm looking for your input on my methods for handling the whole input system. I'm attaching the same cInput class proposal that I sent to the other developers.

Because the current cInput needs to be reworked to make more extensible and easier to add actions, etc. My newly proposed cInput class I think does the job and also gets rid of keys.cpp. It uses Drew Benton's SDL Input Library found at http://www.gamedev.net/community/forums/topic.asp?topic_id=328994

Now I want your comments and feedback on how you think it will work and don't be nice. I'm just figuring this stuff out as I go so I'm sure theres room for improvement. Since I'm a bit of a programming n00b theres probably a bunch of syntactical errors and I'm not totally sure if I used enum right, but those are minor details that I can work out when I get the compile errors. I'm really interested in the over all method of doing this.



keys.xml has declarations like:
<controlsFlyMode>
<fire1>
<device>mou</device>
<value>1</value>
</fire1>
<orbit>
<device>key</device>
<value>9</device>
</orbit>
</controlsFlyMode>

<controlsSelectMode>
<select>
<device>mou</device>
<value>1</value>
</select>
<fire1>
<device>key</device>
<value>64</value>
</fire1>
</controlsSelectMode>

There are two different control modes because we (or at least I?) were/was talking
about being able to toggle between flying mode where you'd use the mouse to point
the ship and the mouse1 button would be fire, etc. But then you could hit tab to
select other ships, interact with the HUD, open the right click menu, etc. Many of
the controls would be the same,but it can pretty easily be taken out.

The value for the keyboard is the int value of SDL_a or KMOD_CTRL or whatever.
They're just plain and simple ints. The SDL documentation has these values in a
table somewhere. The values for the mouse are simply the button numbers.



LoadConfig() fills the following arrays with values from the keys config file. Of
course the index matches the enumed action values like ACT_FIRE1 and ACT_ORBIT.
int flyModeDevices[numberOfKeys];
int flyModeValues[numberOfKeys];
int selectModeDevices[numberOfKeys];
int selectModeValues[numberOfKeys];


Problems to solve that I can think of off the top of my head:
* We should figure out an easy way to make it case insensetive. It's also probably
not terribly hard and could be done either in LoadConfig() or in GetActionValue(),
so SDLK_a and SDLK_A return the same int.
* I don't show anything for setting and getting new keys or input, but thats fairly
trivial.
* Alternatively the XML doc could be laid out like <fire1>mou1</fire1><orbit>key9</orbit>
depending on how cConfig works, I can't remember at the moment. And then you could
just chop it up in LoadConfig or something.
* This input library doesn't currently support joystick functions, but the developer
said he was going to add it and even if it doesn't finish it in time, we could do
it ourselves.

-----------------------------------------------------------------------------------

// The following uses Drew Benton's "SDL input library" found at
// http://www.gamedev.net/community/forums/topic.asp?topic_id=328994

enum actions {
ACT_FIRE1,
ACT_ORBIT
//etc,etc
}

cInput::cInput() {
SDL_Event Event;
LoadConfig("keys.xml") //see note above
Input inputClass; //Drew Benton's SDL Input Library
//I'm sure there will be more to add here
}

void cInput::LoadConfig(string configFile) {
//see note above
}

int cInput::GetActionDevice(int action) {
if (flyMode == true) {
return flyModeDevice[action];
}
else {
return selectModeDevice[action];
}
}

int cInput::GetActionValue(int action) {
if (flyMode == true) {
return flyModeValue[action];
}
else {
return selectModeValue[action];
}
}

bool cInput::testAction (int thisAction) {
switch( GetActionDevice(thisAction) ) {
case 1:
if (inputClass.isKeyPressed( GetActionValue(thisAction) ) ) {
return true;
}
case 2:
if (inputClass.isButtonPressed( GetActionValue(thisAction) ) ) {
return true;
}
break;
case 3:
//no joystick support in inputClass yet, but its going to be added
break;
}
return false;
}

void cInput::resetKey (int thisAction) {
// works much the same way as testAction, but it uses setKeyUp() or setButtonUp()
// so the action happens only once.
}



//this function is called in Epiar's update cycle
void cInput::Update() {

//this chunk of code is from Drew Benton's demo included with the library
while ( SDL_PollEvent(&Event) )
{
if ( Event.type == SDL_QUIT ){
//do whatever we have to do to tell Epiar to quit
}

// Here we first call the Poll function with the current event
// inside our polling loop
InputClass.Poll(Event);
}

// Then we just have to call the update function to take the data
// from the Poll event and update the class
InputClass.Update();




//Now test each game action.
if (testAction(ACT_FIRE1)) {
player->fireWeapon(1);
}

if (testAction(ACT_ORBIT)) {
player->orbit(target);
resetKey(ACT_ORBIT); //for one time "toggle" type actions
}

if (testAction(ACT_SELECT)) {
//get the target by looking at whatever is at the current mouse location.
//get the mouse location using InputClass.GetMouseX() and InputClass.GetMouseY()
player->setTarget(something);
resetKey(ACT_SELECT);

}




[Edited by - TheMoebius on July 31, 2005 2:22:34 PM]

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  

  • Announcements

  • Forum Statistics

    • Total Topics
      628403
    • Total Posts
      2982477
  • Similar Content

    • By JM-KinematicSoup
      Unity has put up an official release of EditorXR (formerly EditorVR). 
      https://labs.unity.com/article/editorxr-and-scenefusion-update
      If you haven't tried it lately, you should. This release is actually very good,
       
    • By JM-KinematicSoup
      Hello everyone,
      I'm looking for some input. We created a tool called Scene Fusion to enable real-time collaboration while doing gamedev in Unity. In effect, it will replicate any scene changes one person performs for everyone else connected to the session. It works well, and we as well as our customers using it notice a drastic speedup getting work done, especially when building large complex levels.
      One limitation we have is that we can't support every single plugin and asset out there, so what we opted to do is provide an API that allows game developers to do that work as required.
      My question is: How many if you out there actually end up having to modify an external plugin/tool in order to get it to work with your project?
    • By toadvine
      I'd like to start building a 2D game, very small, just pixel art. I know python/javascript/tiny bit of HTML and I've started learning C++. I'm a long way from starting officially, I've just been making mini-projects to practice & drawing up concept art/gameplay storyboards. I'm just wondering if I'm off with the C++ for the game's programming, or if I should know certain things before starting.
      The game would be very small, I just want to get started trying out some actual work before college.
      Some other info: I'm working by myself on this, and going into game design/programming next year for college. I'm a high school student with a few years of experience just working by myself making small projects, drawing up stuff, so I really don't know much and I'd appreciate any tips.
      Thanks a bunch!
    • By Daerst

      SWARMED is a Zombie-themed RPG / RTS currently in development using Unity 3D. We love Dwarf Fortress (though we have no illusions that SWARMED will reach the same level of complexity), roguelikes, old-school point & click RPGs and real-time strategy games. We aim to cross genre-borders here and there and give some twists to the old Martinis every gamer has been drinking since the 1980s, metaphorically.
      Single player, 3D graphics and adjustable top-down camera - old-school RPG / RTS feeling Take control of a core group of survivors after the outbreak Encounter Zombies that are a real threat, no machine-gun massacre. Don't get swarmed! Build a safe zone anywhere with a highly flexible build system: campsite, lighthouse, school, or fence a whole village Grant asylum to other survivors that you meet and make them a part of your community Achieve sustainability in your safe zone and go on supply runs with your survivors
      Development
      The core team of recently founded indie studio Three Eyed Games currently consists of one writer, two artists and two programmers, based in Germany. We are in our mid-20s with professional experience in developing interactive 3D applications with Unity.
      SWARMED will feature both a 'free-play mode' and a campaign with mid-sized maps that leads the player through a story while explaining the gameplay and introducing him / her to the survivors: a core group a few 'hero' characters the player starts with (each one a detailed character with backstory, hopes and dreams), and more 'heroes' (total not more than 20, probably less) that the player can meet on the journey. In addition, randomly generated NPCs (less detailed and not directly controllable, similar to the way Dwarf Fortress handles its dwarves) can join your safe zone – if you let them.
      We plan to release a few 'Origin' prototypes that showcase individual gameplay systems and meanwhile give a gentle introduction to the characters you will meet in the game. Origin I, showcasing the build system and many fundamental elements like character controls and interactions, is finished and will be released soon. Next up, we're working on the dialog system to be presented in Origin II. Get in touch and we will provide more details and a playable version.
      We want you!
      We seriously think you should join the fun! We are looking for:
      Level Designers / Environment Artists, preferably with experience in Unity and procedural asset creation. Design and build maps with interesting visuals and proper pacing. 3D Artists. Our shacks, items and the dead guys' faces could use some plastic surgery. Can you do that? Writers. We have a bunch of characters to detail and a story to write ahead of us. Game Designers. We have a rough game design sketched out that needs improvement and completion. We need a balanced combat system, trees for constructions, workshops and character skills etc. PR & Community Managers, preferably with web development experience. We want to build a community around the game, and we need you to plan and manage this (with the help of the rest of the team, of course). 2D Artists / UX Designers, preferably with Unity UI experience. Our menus still look pretty dull, and we don't like that. We also need concept art for characters and iconic game moments to define their look and feel. Coders. If you know your way around Unity and C#, there are lots of challenging things to be done. You will work closely together with the two programmers already on the team to get going quickly. Please drop me a message or contact info@three-eyed-games.com
    • By sveta_itseez3D
      itSeez3D, a leading developer of mobile 3d scanning software, announced today a new SDK for its automatic 3D avatar generation technology, Avatar SDK for Unity. The Avatar SDK for Unity is a robust plug-n-play toolset which enables developers and creatives to integrate realistic user-generated 3D avatars into their Unity-based applications. SDK users can allow players to create their own avatars in the application or integrate the SDK into their own production processes for character design and animation.
      “Virtual avatars have recently become increasingly popular, especially in sports games and social VR apps. With the advance of VR and AR, the demand to get humans into the digital world is only increasing”, said Victor Erukhimov, itSeez3D CEO. “Our new Avatar SDK for Unity makes it super-easy to bring the avatar technology into any Unity-based game or VR/AR experience. With the Avatar SDK for Unity now every developer can bring face scanning technology into their games and allow players to create their own personalized in-game avatars, making the gameplay much more exciting and immersive.”
      Key features of the Avatar SDK for Unity:
      Automatic generation of a color 3D face model from a single selfie photo in 5-10 seconds (!). Works best with selfies, but can be used with any portrait photo.
      Shape and texture of the head model are unique for each person, synthesized with a deep learning algorithm crafted by computer vision experts
      Head models support runtime blendshape facial animations (45 different expressions)
      Generated 3D heads include eyes, mouth, and teeth
      Algorithms synthesize 3D meshes in mid-poly resolution, ~12k vertices, and ~24k triangles
      Six predefined hairstyles with hair-recoloring feature (many more available on request)
      Avatar generation API can be used in design-time and in run-time, which means you can allow users to create their own avatars in your game
      Cloud version is cross-platform, and offline version currently works on PCs with 64-bit Windows (support for more platforms is coming soon)
      Well-documented samples showcasing the functionality.
       
      Availability
      The Avatar SDK for Unity is offered in two modes - “Cloud” and “Offline”. The “Cloud” version is available at http://avatarsdk.com/ and the “Offline” version is available by request at support@itseez3d.com.
      ###
      About itSeez3D
      At itSeez3D, we are working on the computer vision technology that turns mobile devices into powerful 3D scanners. itSeez3D has developed the world's first mobile 3D scanning application that allows to create high-resolution photorealistic 3D models of people's' faces, bodies and objects. The application is available for iOS and Windows OS mobile devices powered with 3D cameras. In 2016 the company introduced Avatar SDK that creates a realistic 3D model of a face from a single selfie photo. To learn more about itSeez3D scanning software and 3D avatar creation technology, please visit www.itseez3d.com and www.avatarsdk.com.

      View full story
  • Popular Now