Lots of internal discussion over this topic!
We really appreciate the input from this thread :)
Wonderful! I agree with GodlyPerfection, in that just having the team's ear on issues like this is a show of how open and engaged OUYA is, and how hard …
Okay, how about this:
Single press = game-specific pause menu
Double press = OUYA menu
Surely a software-only solution can be devised where the call for the game menu on "key up" can be delayed by enough time to reasonably allow for the button to …
I suspect the controllers themselves are programmed directly with this functionality and can't be changed (i.e. there's no way of shutting it off without completely recalling and re-programming the controller. Which is probably not a realistic or c…
+1 For press and hold, despite the controller pairing concerns it may be the best solution short of an extra button. We need a standard pause menu button which doesn't break game immersion.
If defined like any other button in the odk, a later contr…
Using a long-press of the controller's system button is problematic, because that button already has several overloaded behaviors.
I understand that there may be technical hurtles to the "press/hold" solution, but it's the *only* thing that makes se…
That's no bug. The "A" button is mapped to the Android BACK key (unless it is assigned to something else using the ODK, which is unavailable to AIR without a native extension).
Likewise, the "U" button is assigned by default to the Android MENU key…
This is my first priority when our dev kit arrives. [...] I'll gladly share with the community once I have something working.
Yay! Thanks for taking it on.
I have experience with AIR Native Extentions and unfortunately Air for mobile doesn't support Native Extensions :(
That doesn't make any sense. While it's possible to create extensions for desktop OSes, Native Extentions for AIR was designed by …
Fair enough, but I just listing potential examples. My point was to discourage any practice which would make it harder for devs to get creative with the control inputs available to them.
But maybe a lot of you are intending to use it for other things, I've always just seen it as something that was thrown in to make it easier to port smartphone games.
I get where you're coming from, and I'm sure a majority of games will not use the …
the Native Extension is really the biggest remaining hurdle, but that one seems eminently solvable
I think you may be a bit optimistic on that score, but I agree that it will eventually get solved.
Keep in mind that OUYA technically already has support for AIR apps, in that it can run them just like it can run any other Android app. And because some of the controller's face buttons and its d-pad default to native Android hardware keyboard inpu…
By the way, this is what I asked Julie in August via email:
Will Ouya support "AIR for Android" development? My thinking is that I would use AIR's Captive Runtime feature to package the AIR runtime within the app (like how it's implemented in iOS wi…
I hadn't considered that, but ideally, yes, it would be easiest (and probably best for all involved) if OUYA created and maintained an Native Extension themselves. I figured that it would be outside thier wheelhouse, but you reminded me that there a…
I don't think it's necessary (or wise) to keep the system in active memory, although perhaps disk caching (or "page filing," whatever) would be required in order to allow apps to use all available memory *and* allow the system menu to be accessible …
The only reason they suggest using x86/Intel emulation is because ARM emulation on PCs is as slow as molasses, and you won't get anywhere near real-world performance, especially for things like 3D games. The OUYA itself has an ARM processor, so your…
You could also try wrapping the ODK classes and methods with a java class you create that implements the required interface that AIR is expecting. Then just pass through calls to your class to the equivalent/underlying calls to the ODK.
That's more…
Okay. I put a little time into this just now and immediately came upon some roadblocks.
The way that native extensions are designed, it's not a matter of simply passing arguments or variables from an ActionScript class into an existing Java class a…
I'm seriously considering tackling this, but I really have no experience with native extensions, so I can't guarantee that I'll know what I'm doing. :-)
If we were to do this, the easiest way to have that happen is with something called "fallbacks". I can declare in our keychar map file that if a menu button press isn't consumed, that it will do a secondary action (in this case, the home or OUYA men…
I would also point out that making it use Android's menu key (rather than just defining another arbitrary controller button) would give some standardization to developers, and generally discourage them from using the button as another action button.…
How about:
home button press = pause
home button hold = OUYA menu
Add me to the agree pile on this one, but at a system level, it should actually be:
home button press = Android menu key
home button hold = OUYA menu
This would make porting easier,…
