In a nutshell, my goal is to create my own program for visually looking at game controller input.
However, it appears that once the unity application is in the background, ergo, once I switch to a different window to play a game, the controller input for my unity program is no longer read.
I've seen that the user Elringus had a project called UnityRawInput to help with this, but it only works for keyboard input. I've seen a lot of different responses related to this question that mention using native libraries to "hook" to get background input, but it apparently only works for keyboards.
What information is out there such that I can hook to game controllers themselves? I cannot seem to easily search for information pertaining to game controllers (and their various axis) themselves and not keyboards.
Why not a keyboard? Because I am very interested in a game controller's triggers in the way where, when pressed slightly, it can preform "weaker" actions rather than being pressed all the way, which a keyboard cannot discern as far as I can tell.
Though, wherever the solution might be, even outside of Unity, I'd like to know. Thanks! :D
Related
I'm building an openvr app for steamvr to assist with seated play (my room is small so my tracking area isn't ideal). My app pretty much just adjusts the play-area height when I hold the grip button and "scroll" on the touchpad so that I can reach objects that are too low/high at variable heights. (I tried "OpenVR Advanced Settings" but the options for keybinding with it is limited to simple button presses so I decided to make my own version).
I'd like to prevent touchpad input from being sent to the game while the grip button is being held, so that the moving on the touchpad doesn't cause movement in game, is this possible at all?
I'm assuming it's not possible, but wondering whether anyone has had any experience with this.
After your clarification in the comments the answer is no, you can not "eat up" device inputs in an application, I usually work on OpenVR drivers and there after you submit a device input and/or any other event its available to anything that expects pose update events, and event subscribers can not stop others from receiving the said events
However there might be a work around (if its still an issue) I know of at least 1 application that can do what you want and that application is OVR Toolkit (when the overlay is active and you try to click something in the overlay, the game running in parallel will not receive the input, however that will only happen if OVR Toolkit overlay surface receives input, it may be a built in OpenVR overlay feature and you don't have to do anything or it can be defined by the developer, I don't really have a want to test this right now)
Sadly though OVR Toolkit is not open source, but there is an open source toolkit for unity for making overlays, which is open source and might be the solution you're looking for, it can be found here
I'm working on a project and I've been asked to add a fairly detailed and nested menu system overtop pre-existing gameplay. I'm new to iphone programming in general, but have experience with other C languages on different platforms. I'm looking for an example of a good clean menu system architecture.
So far, I've gotten a little used to how the xib files interact with the code, but I still have a ways to go it seems. I have two UIViewControllers; lets call them UIViewControllerA and UIViewControllerB. I started with UIViewControllerA (the game's main view controller) and want to add UIViewControllerB as a menu to lay on top the game window. The only way I've found to get UIViewControllerB to render is to use it as a data member of UIViewControllerA and add it as a subview to UIViewControllerA.
This seems like a very unclean way to organize this system and introduces some bugs. IE - when I have UIViewControllerB showing, the touch events fall through to UIViewControllerA which I do not want.
Sorry this is long, but I'll get to the point. Does anyone have a good suggestion on how to create a clean and robust menu system? I feel as though I am way off the mark. I don't think I have enough experience to come up with a good system on this platform.
Thanks in advance!
EDIT:
I feel as perhaps I didn't specify that I'm seeking help for technical programming design rather than visual design. I'm seeking for a way to implement a state-machine type architecture for an iphone platform.
Check out this link - https://github.com/relikd/OGActionChooser
It's a nice-looking replacement for a UIActionSheet or UIAlertView - this could easily be customized to present a modal menu system.
A really easy way to have a clean menu page, simply take a picture of hardwood floor (or off the web) and add buttons. I would show an example but I need 10 points...
Take the pic, onto PS (photoshop) and add a box or square, add shadow and some cool special effects, upload it to xcode, but the buttons in the box.
I’m creating an application which will be used by visually impaired users using voiceover (in built screen reader in iPhone).
Certain group of visually impaired persons use external keyboard.
1)Is there any way to Control the reading order of controls in iPhone using xCode?
I want a particular control to be read after another. Similar functionality can be achieved via tabIndex property in other programing languages. Is there any similar property available in xCode with which we can control the reading/navigation order of controls?
2)Is it possible to shift focus from one element to another on any event? I tried working with "nextResponder",but it is not working.
3)If a regular user is using iPhone with an external keyboard, it becomes difficult to understand where the current keyboard focus is and thus makes the application difficult to use. Is it possible to provide focus caret (black border around the control which is currently focused?) When Voiceover is ON, a black border is shown around the items which are focused
1) Do you mean: this
2) There is a way to switch focus from one element to another after something changed
UIAccessibilityPostNotification(UIAccessibilityScreenChangedNotification, yourElementOfFocus);
or if it is an layout change
UIAccessibilityPostNotification(UIAccessibilityLayoutChangedNotification, yourElementOfFocus);
3) I don't quite understand your question... If voiceOver is turned on, doesn't it automatically shows a border around the element it is currently focussed on?
I have written code so that technically there should be two MPMoviePlayerControllers within the same view, both ready to play an audio file. What always happens is that one pops up and disappears, and the other comes up and stays, and is fully useable.
Any idea why one disappears? I'm not trying to play two at once, just want to give users the option to play from different sources.
There can only be one active MPMoviePlayerController, it won't mind if the user didn't play it yet. I do not know the technical reason, but I do know that this is the normal behavior when you do that.
My advice would be to use AVAudioPlayer to achieve what you want. The sad part if that you will have to implement the UI of the player.
When I've learned that I have to write some code to make the iphone keyboard go away. I was quite surprised. I was surprised even more when it become apperent that it is just the top of the iceberg.
What are the expected UI behaviors that aren't provided by system OOTB?
Is the list below complete?
The expected UI behaviors:
Focusing next text field when [done] is hit
Hiding the keyboard when background is hit
Using Touch Up Inside to fire a button action. (To give user opportunity to change his/her mind)
Supporting the screen rotation.
Some of that is silly, but some of it has uses as well.
Focusing next text field when [done] is hit
Which field is "next"? If you have a large form with fields both next to and above/below each other, next might not be so obvious. Even if they are in some linear layout, the iPhone would have to work to figure out which one is next. Do you want to wrap around at the end of the form, or dismiss the keyboard, or submit the form?
Hiding the keyboard when background is hit
I mostly agree with you here, though there are a few cases where this is useless. For example, adding a new phone number in the contact app.
Using Touch Up Inside to fire a button action
This one I really don't get. I can only guess that it's designed to allow you to use buttons instead of the touchesBegan/Moved/Ended methods. I guess it could be useful, but I've never used anything but Touch Up Inside.
Supporting the screen rotation
Many apps just don't work in any other orientation, such as games. If you want to use rotation, you only have to add two lines of code assuming you've done your layout well.
I hope this helps explain some of the strangeness. Aside from the keyboard dismissal, I've never really found anything too annoying. The one thing I wish they supported was using the highlight state of UIButtons for the set state. It would be a quick and easy toggle button, but I've taken to screenshotting a highlighted button and using that for the background image of a selected button.
Want a rounded rectangular button that isn't white? Since that one uses a background image, you can't just click something somewhere that makes it the color of your choice. You have to create your own image or you could even use CSS (WTF!?) to do it.
Unfortunately, the iPhone SDK lacks a lot of helpful things one would think would just be there. However, many people have taken the time to write wrappers for many of these kinds of things to help facilitate development - a quick google search into the functionality you are expecting may turn up a lot of useful answers!
For example, you could make the keyboard go away when you tap outside of it by creating a new view when it appears, and placing that view behind any user-interactable views on the screen. When that new view is tapped, it will become first responder and cause the keyboard to slide away (because the UITextField is no longer first responder).
Such a thing could be easily implemented as a drop-in fix for pretty much anything you'd need it for with very little code.
Still should have been included in the SDK in the first place, though!