Inputs, Inputs everywhere...
by Frank Carney · 04/07/2007 (9:51 am) · 2 comments
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
About the author
I Started programming in HS and have never stopped. Now an 18 year vet of programming anything from assembler on a NES console to a nuclear waste processing system. If it can be programmed I may have tried to program it!
#2
07/05/2007 (4:06 pm)
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.
Torque Owner Stephen Sinclair
Thanks,
Steve