Previous Blog Next Blog
Prev/Next Blog
by date

Inputs, Inputs everywhere...

Inputs, Inputs everywhere...
Name:Frank Carney
Date Posted:Apr 07, 2007
Rating:Not Rated
Public:YES
Comments:YES
RSS Feed:GarageGames Blog feedor Subscribe with .
Profile Page:View profile page for Frank Carney

Blog post
This is a status blog related to fixing some stuff in the engine that has to do with analog inputs not being mappable in stock Torque. Right now I have added a function in the ActionMap class that will allow for analog mapping inputs. I modified the function in the class that does the mapping to use this function for analog inputs. Then I modified getMapDisplayName in optionsDlg.cs to recognize those mappings by name. This is just for fixing the mapping related to the sim side. What I describe next is for mapping arbitrary inputs for the GUI side.

I have been working on getting a joystick to work with the GUI and have come to the conclusion that GUI input in general needs work. So I came up with some ways to fix this:
1. Add a function to the base platform code that provides a function to identify the joystick using the text the driver gives you. I have done this under Linux, but I have not looked at Mac or Windows platforms yet. If someone who is familiar with those can either implement those or test those that would be great. The console call in script looks like this:

"getJoystickName(%index)"


Next I am working on adding functions for mapping the inputs in GuiCanvas to allow inputs to be tied to mapped inputs just like an actionmap. I thought about using the actionmap class, but there are some issues with it. I may derive from that later, but for now I am adding functions to the actionmap class that I will use to provide functionality like looking up device text or event codes. When I get it done there will be another cs file that will map gui inputs to gui functions. I am most likely going to provide a legacy mode that does not allow remapping of mouse and keyboard functions that are tied to predefined functions. This mode will be controlled through script calls.

One problem I found was that the tab code did not work. I made some adjustments and fixed some bugs and now I got that working. The main problem I found was there seemed to be a concept problem where it was designed to step through widgets by referencing itself to those widgets. However, canvas kept getting referenced and the make first responder call on canvas is a big no no.

I expect to turn this into a resource at some point. Right now I am trying to get the basics in place. I expect there will be a lot of widget code adjustments to make this work correctly.

Thanks,
Frank Carney

Recent Blog Posts
List:12/25/07 - Milestone Reached: Mission Launched from Database
12/24/07 - Creating Objects Without Creating Them
12/24/07 - Another Sqlite Blog
09/03/07 - SQLite is Fun!
08/20/07 - Playing House
07/05/07 - Getting burned out and coming back, again...
04/07/07 - Inputs, Inputs everywhere...
04/01/07 - RPG, what does it mean?

Submit ResourceSubmit your own resources!

Stephen Sinclair   (May 07, 2007 at 16:45 GMT)
So far this is a great start. I have been wondering how to get the "Start" button on my main (mainMenuGUI) to actually work. Can I reset actionMaps during game play? Maybe reset the action map for the controller when a GUI is displayed? Ie. The "A" button the XBOX controller would mean something else when a specific gui is on the canvas...Any thoughts on this?

Thanks,
Steve

Frank Carney   (Jul 05, 2007 at 23:06 GMT)
I am sorry I have been gone a while. I am not sure how this would work. Don't the dialogs take precedence and "eat" events when a take focus version pops up? I will have to work on that if it does not. Thanks for the heads up.

You must be a member and be logged in to either append comments or rate this resource.