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: | or 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:
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
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 your own resources!| Stephen Sinclair (May 07, 2007 at 16:45 GMT) |
Thanks,
Steve
| Frank Carney (Jul 05, 2007 at 23:06 GMT) |
You must be a member and be logged in to either append comments or rate this resource.



Not Rated


