Implementing a new input device.
by Lukas Joergensen · in Torque 3D Professional · 02/26/2014 (1:16 pm) · 11 replies
Hey guys, I'm in the midst of implementing a new next-gen input device, however I'm running into a few issues.
First of all, I'm sorry for the secrecy but I can't tell you much about it yet, I'm under a NDA for a while. I can speak more openly about it when the developer kits are released to the general public sometime later this year. (And not just the exclusive group that I'm a part of apparently hue hue)
So this device seems to be a breeze to implement, however I'm running into the following issue:
It's not continuously picking up data, you have to explicitly tell it to listen for an amount of milliseconds like this:
Do you have any good idea of how to handle this? I guess it would make sense to simply put it into a thread and run the "listen" command untill the next time the "process" method is called.
First of all, I'm sorry for the secrecy but I can't tell you much about it yet, I'm under a NDA for a while. I can speak more openly about it when the developer kits are released to the general public sometime later this year. (And not just the exclusive group that I'm a part of apparently hue hue)
So this device seems to be a breeze to implement, however I'm running into the following issue:
It's not continuously picking up data, you have to explicitly tell it to listen for an amount of milliseconds like this:
mListenerCentral.listen(1000/60); // Listen for 1/60th of a second // Alternatively mListenerCentral.listenOnce(1000/60); // Listen for 1/60th of a second or untill it picks up some data
Do you have any good idea of how to handle this? I guess it would make sense to simply put it into a thread and run the "listen" command untill the next time the "process" method is called.
About the author
IPS Bundle available at: https://www.winterleafentertainment.com/Products/IPS.aspx
#2
02/26/2014 (2:32 pm)
Isn't it possible to just listen for < 32 ms and pick up whatever has accumulated since you last called it?
#4
02/26/2014 (3:16 pm)
Better than what? Threads aren't exactly free. 
#5
(Also if you have a multicore CPU then a thread is basically free :P.)
02/27/2014 (4:26 am)
How often do you need to listen to the controller? I.e. what portion of the total time spent in your app? If you need to listen for any significant amount of time (like, even 1/60th of the time) and the listen call blocks then a thread is pretty much your only option.(Also if you have a multicore CPU then a thread is basically free :P.)
#6
Haven't recieved any yet, so for now I think I'll be rolling with the threads, I'm not sure if it's blocking, but I'm assuming that it is.
I'll tune back in if I get some responses on the private thread.
Edit: I was thinking of simply making a thread that continuously tells it to listen, assuming there is no issues with that approach.
Thanks for all the replies.
02/27/2014 (5:07 am)
Sorry that I haven't responded earlier, I was waiting for responses on another thread in the private forum for the device.Haven't recieved any yet, so for now I think I'll be rolling with the threads, I'm not sure if it's blocking, but I'm assuming that it is.
I'll tune back in if I get some responses on the private thread.
Edit: I was thinking of simply making a thread that continuously tells it to listen, assuming there is no issues with that approach.
Thanks for all the replies.
#7
To create a hardware thread might be as close as free as you can get, but it's definatly not free to maintain. Your processor will context switch, restore the cache and maintain time slicing each time the thread wakes up. You're gonna degrade performance sooner rather than later if you're using a thread for every small subsystem (like the one mentioned) you can find.
If they're blocking while waiting for input then it's going to be fast as the processor can take shortcuts and not assign the thread any time slices, but in any other case you should be careful.
I would check to see if they're accumulating events (like for example ENet does) and if so you'd just call the function with 0 ms as the argument.
02/27/2014 (2:00 pm)
Quote:
(Also if you have a multicore CPU then a thread is basically free :P.)
To create a hardware thread might be as close as free as you can get, but it's definatly not free to maintain. Your processor will context switch, restore the cache and maintain time slicing each time the thread wakes up. You're gonna degrade performance sooner rather than later if you're using a thread for every small subsystem (like the one mentioned) you can find.
If they're blocking while waiting for input then it's going to be fast as the processor can take shortcuts and not assign the thread any time slices, but in any other case you should be careful.
I would check to see if they're accumulating events (like for example ENet does) and if so you'd just call the function with 0 ms as the argument.
#8
Anw this brings up another issue, it seems that because all the input is stacked up it plays "catch-up" if you remove focus from the window and then re-enables focus, i.e. all the input is fired at once, which makes looks a bit weird..
So any ideas on how to disable the listener while the window loses focus? Can I hook into a "focus lost" event or something like that?
03/03/2014 (6:16 am)
I just recieved the device today, so I've been able to do some testing and I've found that it stacks up all the events so just calling this:mListenerCentral.listenOnce(0);Before I need the data will still retrieve all the input made between the listens.. Weird shit.
Anw this brings up another issue, it seems that because all the input is stacked up it plays "catch-up" if you remove focus from the window and then re-enables focus, i.e. all the input is fired at once, which makes looks a bit weird..
So any ideas on how to disable the listener while the window loses focus? Can I hook into a "focus lost" event or something like that?
#9
<edit>
It's in app/mainLoop.cpp line 578 (inside StandardMainLoop::doMainLoop()) - so perhaps add a call here to suspend (and in the else to restart) it.
03/03/2014 (6:20 am)
When you lose focus the game switches to "background mode" - just watch the console when you do it and you'll see the message. Just do it in that function - can probably find it by searching for that text from the console....<edit>
It's in app/mainLoop.cpp line 578 (inside StandardMainLoop::doMainLoop()) - so perhaps add a call here to suspend (and in the else to restart) it.
#10
This is normal.
Clean up the move data and push the actionmap on focus return and pop the input on focus lost.
You can do better if you adjust the input cooperative levels.
03/05/2014 (12:55 am)
"if you remove focus from the window and then re-enables focus, i.e. all the input is fired at once, which makes looks a bit weird.."This is normal.
Clean up the move data and push the actionmap on focus return and pop the input on focus lost.
You can do better if you adjust the input cooperative levels.
#11
03/05/2014 (1:09 pm)
@Ivan thats a good idea just need to detect the change of focus then in a way that doesn't modify the existing code such that the existing code depends on the device. 
Associate Tim Newell
Max Gaming Technologies