|
XboxPants posted:Yeah, that's weird, but he's running that program on a PC so I'm not sure what you're trying to say. In the video he says "If I switch to the OUYA" but I guess he's on a PC for recording and he meant virtual OUYA?  I don't even know what's going on here anymore. I guess he's running a PC bechmark with the OUYA controller, but then... well, I guess he meant his virtual OUYA test program.Suspicious Dish posted:That's the code for his test app, not the code for the SDK. Given how this is working, I'm suspecting it's a hardware bug, given that the OUYA Controller SDK is a simple wrapper around the Android Joypad API, and the OUYA joypad is simply a standard Bluetooth HID controller device. If it IS a hardware issue, they're seriously hosed. Zaphod42 fucked around with this message at 20:43 on May 7, 2013 |
#
?
May 7, 2013 20:39
|
|
|
|
| # ? Jun 6, 2024 21:37 |
|
|
Dear OUYA: How do I roms? OUYA: https://twitter.com/OUYASupport/status/331846984803696640 Ahahahahaha Zaphod42 posted:In the video he says "If I switch to the OUYA" but I don't know I guess he's on a PC for recording and he meant virtual OUYA? Apparently there's also some level of bluetooth latency just inherent to Android. From what people are saying, it could be fixed with software, but it'd be a pretty big undertaking. More than OUYA is capable of handling right now, anyway.
|
|
#
?
May 7, 2013 20:42
|
|
|
That review posted earlier mentioned a table getting in the way of the controller & OUYA being related to the lag. Software isn't really the issue if that's the case.
|
|
#
?
May 7, 2013 20:43
|
|
|
XboxPants posted:Apparently there's also some level of bluetooth latency just inherent to Android. From what people are saying, it could be fixed with software, but it'd be a pretty big undertaking. More than OUYA is capable of handling right now, anyway. I guess you mean OUYA the company, not OUYA the product. Man, I hate when companies do that. zylche posted:That review posted earlier mentioned a table getting in the way of the controller & OUYA being related to the lag. Software isn't really the issue if that's the case. Well, we were talking about the buttons killing the trigger input bug. Pants is right about that, there could be a software workaround, but who knows if OUYA the company will manage to get it done with their crack team of 3 CS interns. That said, you're right as well that the OUYA controller's problems are many.
|
|
#
?
May 7, 2013 20:44
|
|
|
Suspicious Dish posted:Wait, if you hold down the trigger button and press an OUYA face button, the trigger gets reset? Did they test this thing in the slightest bit? Test? The kickstarter backers are the testers!
|
|
#
?
May 7, 2013 20:49
|
|
|
Swilo posted:I think these are interesting points: Yeah, the email did say that the second controller was shipping separately, but I think given that my shipment was handled by folk higher up that they threw in the second one just to close the case out entirely. It was certainly appreciated, as my "I bought this but it's ok because..." was based around "...we can play it together and not go out drinking every night." The faceplate on the second controller was taped on, which I guess explains why it didn't come off in transit. The one that was in the actual OUYA box was not taped in any way, so I guess it was done specifically because it was being shipped inside the large cardboard box but outside of the OUYA box and without its own box. The two Duracell batteries that you see in the pictures are from inside the OUYA box. The two loose Maxwell ones were just inside the shipping box with the second controller, floating around with the bubble wrap. Again, batteries at all were appreciated anyway. Both controllers show no sign of wear or use, they both look brand new - they may have grabbed one from another OUYA box though just to include it in my package. Of course, I have no idea if any of it works, but I'll find out tonight.
|
|
#
?
May 7, 2013 21:02
|
|
|
XboxPants posted:It really seems to depend on the software, not the hardware, just like the analog deadzone issues. Deep Dungeons of Doom is a timing-based game and I haven't noticed any input latency issues there. You're never pressing more than one button at once, though, so if button mashing causes more lag, you'd never notice.
|
|
#
?
May 7, 2013 21:09
|
|
|
quote:Buttons, that was interesting. Didn't realize it until you told us about that -- great to have a preview period. We went about increasing the size of the opening for the buttons so no more sticking under the faceplates. What? What?
|
|
#
?
May 7, 2013 21:14
|
|
|
theflyingorc posted:I know you don't know anything about programming (that's OK!) but there's really no reason multiple buttons should cause lag issues that single button pushes shouldn't also cause. Luckily that's been fixed, but they still have to send the input data from Java to Unity as they receive it. Aweful Dreams fucked around with this message at 21:23 on May 7, 2013 |
|
#
?
May 7, 2013 21:20
|
|
|
OatmealRaisin posted:What? What? Did you think I was joking when I said kickstarter backers were unwitting beta testers?
|
|
#
?
May 7, 2013 21:23
|
|
|
Aweful Dreams posted:Well, it kinda depends. Normally you're correct, but if the developer is using Unity for their game engine, the controller input actually has to get passed from Android's Java code to Unity. And the more buttons/axis data that has to get sent at one time, the more time it will take to send it, thus adding a tad more lag (not much, but some). That was actually one of the initial reasons for the reported input lag, because the first version of the Unity package from the OUYA Dev Kit did a very slow job of serializing the input data, sending it to Unity, and then deserializing it. And worse, the way it worked was if any input was sent (ie, one button pressed), it would serialize and send across a chunk of data large enough to hold all possible input from all possible controllers, rather than just that one button or even splitting it up to just the buttons rather than buttons and joystick axes. You might just be talking about separate steps, let's break it down and see if I understand you: Step 1: You press a button, the controller sends a signal to the console Step 2: The console decodes the input it receives Step 3: It passes this to Unity for use At each of these points, the possibility exists that the controller either sends a full controller state, or it just sends anything that has changed. At any point where you normally send a full state, multiple button presses aren't going to increase your overhead one lick.
|
|
#
?
May 7, 2013 21:30
|
|
|
theflyingorc posted:At each of these points, the possibility exists that the controller either sends a full controller state, or it just sends anything that has changed. At any point where you normally send a full state, multiple button presses aren't going to increase your overhead one lick. To speak to Xboxpants earlier point, yes, you do need controller input concurrency because it's rarely going to be a time when you're pressing a single button, 'mashing' aside. It's one of the selling points of the higher end gaming keyboards that there's no input ghosting or lag. Half a second of lag in a control system is going to be a huge dealbreaker if it's connected with something daft like bluetooth bandwidth. How many channels is this thing working with on the controllers?
|
|
#
?
May 7, 2013 21:38
|
|
|
theflyingorc posted:Errr...don't these two points contradict each other? If you're sending the full controller state every time, then pressing one button repeatedly shouldn't be any different from hitting A and then the right trigger, right? Yeah, it's because there's the old method, and the new method. The old super-slow method serialized and sent the full potential controller state for all potential controllers from Java to Unity, which then deserialized them. And you're right, using that method more controllers wouldn't really add to the lag, except for the fact that more controllers in use means more potential input triggering this data passing (one controller isn't sending any data, but the other controller is). But the new method only passes each individual input as it gets detected rather than the whole thing (and doesn't do any extra serializing/deserializing). So the new method would still add slightly more lag with multiple inputs sent at once than if there was just one.
|
|
#
?
May 7, 2013 21:41
|
|
|
I love how haphazardly taped up that first shot of the package looks. When you order something from an upstart company it shouldn't look like you just bought it off eBay. -on second look the shipping label is a sheet of paper. That had to be some complete system they had lying around the office that they simply packed up otherwise they don't even own proper label printers. cronox2 fucked around with this message at 22:05 on May 7, 2013 |
|
#
?
May 7, 2013 22:03
|
|
|
Couldn't dotalchemy or me runs some latency tests? How do you test controller latency? I feel like there's gotta be some kind of Android app that would work for this. If there's no Android app, we should also be able to bluetooth up the gamepads to a PC and use something there, right? My desktop doesn't have bluetooth but I bet I have a laptop around here somewhere that does. Or is it possible that the OUYA pads may not work properly with a PC for some reason?
|
|
#
?
May 7, 2013 22:16
|
|
|
 vvv good idea! vvv limaCAT fucked around with this message at 22:33 on May 7, 2013 |
|
#
?
May 7, 2013 22:22
|
|
|
That is glorious. I don't see a Lots! Lots! in there unless I missed it though.
|
|
#
?
May 7, 2013 22:29
|
|
|
XboxPants posted:Couldn't dotalchemy or me runs some latency tests? The Android java code necessary to read in inputs from Android's Gamepad SDK or Ouya's SDK and map it to some sort of UI indicator shouldn't be difficult or take a long time to write. I imagine using Unity to create something integrating with Unity's SDK shouldn't be that hard either. What you essentially need is an application that you can use to display when you've pressed your button and when a light shows up on the TV that you can film at a high FPS and analyze how many frames it takes to register. Bearing in mind that display latency will also have an effect. My (very) quick search on the Play store led to no useful results and I'm not going to write something unless I actually get an OUYA to gently caress around with. Ben Heck provides a very expensive rig that helps in measuring controller latency in 360 Games as detailed on his blog: http://benheck.com/xbox-360-controller-monitor
|
|
#
?
May 7, 2013 22:32
|
|
|
Aweful Dreams posted:Yeah, it's because there's the old method, and the new method. The old super-slow method serialized and sent the full potential controller state for all potential controllers from Java to Unity, which then deserialized them. And you're right, using that method more controllers wouldn't really add to the lag, except for the fact that more controllers in use means more potential input triggering this data passing (one controller isn't sending any data, but the other controller is). But the new method only passes each individual input as it gets detected rather than the whole thing (and doesn't do any extra serializing/deserializing). So the new method would still add slightly more lag with multiple inputs sent at once than if there was just one. Huh? I wasn't aware that controllers transmitted their state automatically, or that you could get the state of just one control directly from hardware. From what I've seen, a program usually polls the controller for its entire state once per frame, then tests an individual control's state against the controller data you now have. Serialization seems really pointless here - unless the controller's state and the console have completely different definitions of what booleans and floating-point values are, there's no need to encode and decode raw information like that. You probably are right about the entire state taking a while to send. If a polling for controller state sends the whole state, then according to the screens in the bug report video you'd need to store data for ten axis and 20 buttons:
|
|
#
?
May 7, 2013 22:35
|
|
|
Things like this are the real treasures that get produced thanks to OPEN UNIVERSE YAAAAAAAAAA.
|
|
#
?
May 7, 2013 22:35
|
|
|
XboxPants posted:Couldn't dotalchemy or me runs some latency tests? You guys can test this bug (specifically at 3:00)
|
|
#
?
May 7, 2013 22:44
|
|
|
w00tazn posted:What you essentially need is an application that you can use to display when you've pressed your button and when a light shows up on the TV that you can film at a high FPS and analyze how many frames it takes to register. Bearing in mind that display latency will also have an effect. Yeah, but my first thought is, does dotalchemy or pants have a good enough camera for this to even be worth doing? The challenge with recording latency is really the hardware, not the software.
|
|
#
?
May 7, 2013 22:44
|
|
|
Zaphod42 posted:Yeah, but my first thought is, does dotalchemy or pants have a good enough camera for this to even be worth doing? I have a cellphone. That's the only visual recording device I own, outside of the webcam built into my laptop and the camera built into the Kinect...
|
|
#
?
May 7, 2013 22:55
|
|
|
If one you ship me your OUYYA I will film myself smashing it with a hammer and covering the hardware in dog poo poo.
|
|
#
?
May 7, 2013 23:24
|
|
|
cronox2 posted:I love how haphazardly taped up that first shot of the package looks. When you order something from an upstart company it shouldn't look like you just bought it off eBay. When you have so much Kickstarter money to spend on drugs, things can get disorganized. Some days Uhrman & company just wake up from drunken stupor, covered in sick and general filth, and find a couple of OUYAs littering the ground. They don't know where they came from, and are too embarassed to ask. So they just shove them into boxes and send them to random addresses, hoping they'll never come back to haunt them. And that's how OUYAs are made.
|
|
#
?
May 7, 2013 23:27
|
|
|
I can't get over the preview period thing... I mean what the gently caress. Can someone with a Twitter account ask her if backers are going to get new parts to replace all the broken poo poo they discover during the - gently caress's sake - 'preview period'. Oh hey thanks for the 8 mil guys. Btw that console we said you were getting? Yeah it's just a preview but if you could tell us all the things that are hosed up on it so we can fix it for retail that'd be great.
|
|
#
?
May 7, 2013 23:27
|
|
|
Fnoigy posted:I like how this thread suddenly puts in more collective effort into consolidating pieces of a so-so running joke than the OUYA team put into any given part of their programming or development. Ha. I'm really hoping someone pulls it off, though. I'm really curious to see how many goon names for the BIBBITYBOBBITYBOO there are.
|
|
#
?
May 7, 2013 23:30
|
|
|
steinrokkan posted:send them to random addresses. May not be far from the truth. Some dude on Reddit was complaining that his HONKYTONK with extra controller had been shipped, but the console had ended up in one city, the controller in another, and he wasn't in either of those places.
|
|
#
?
May 7, 2013 23:48
|
|
|
Good Dumplings posted:Huh? I wasn't aware that controllers transmitted their state automatically, or that you could get the state of just one control directly from hardware. From what I've seen, a program usually polls the controller for its entire state once per frame, then tests an individual control's state against the controller data you now have. Serialization seems really pointless here - unless the controller's state and the console have completely different definitions of what booleans and floating-point values are, there's no need to encode and decode raw information like that.
|
|
#
?
May 7, 2013 23:58
|
|
|
Louisgod posted:If one you ship me your OUYYA I will film myself smashing it with a hammer and covering the hardware in dog poo poo. Too bad the BLOWME wasn't around during the "poop on consoles/lost fingat" thread. The most fun thing you can do with it is poo poo on it and melt it with thermite.
|
|
#
?
May 7, 2013 23:59
|
|
|
Louisgod posted:If one you ship me your OUYYA I will film myself smashing it with a hammer and covering the hardware in dog poo poo. Be the first recorded upgrade...
|
|
#
?
May 7, 2013 23:59
|
|
|
Aweful Dreams posted:The serialization was because the early ODK developer didn't know how to correctly pass the controller data from Java to Unity - that's not documented anywhere and from what I gather the Unity company is slow to respond to questions. So he made use of a Unity feature where you can call a Unity function from Java, but only send one parameter, a string. He used JSON to serialize the controller structure into a string and sent it to Unity, which then used JSON to deserialize it (and that process is v-e-r-y slow). And that structure didn't just hold all possible OUYA controller data, but all possible Android controller data, and Android has support for things like racing wheels and gas pedals. That's, uh... how'd they end up deciding any of this was necessary or a good idea? Do you have a link to this? This is really interesting in a horrifying sort of way. e: Guess I can just check the decompiled ODK.
|
|
#
?
May 8, 2013 00:02
|
|
|
Good Dumplings posted:That's, uh... how'd they end up deciding any of this was necessary or a good idea? Do you have a link to this? This is really interesting in a horrifying sort of way. Unfortunately, it's basically something I figured out by following controller lag threads in the dev forum, the info is spread out among a dozen threads on their website, but here's one of the key threads: http://forums.ouya.tv/discussion/comment/9487 (Input Lags extremely when spamming buttons). And the code you're looking for isn't in the compiled ODK, it's in the Unity Package, with the JSON serializing happening in OuyaUnityApplication.java and the deserializing happening in OuyaGameManager.cs. Aweful Dreams fucked around with this message at 00:19 on May 8, 2013 |
|
#
?
May 8, 2013 00:16
|
|
|
Zaphod42 posted:Yeah, but my first thought is, does dotalchemy or pants have a good enough camera for this to even be worth doing? In order to really measure this accurately you'd ideally need some custom hardware wired / soldered directly to the controller pcb contacts. Something like: http://benheck.com/xbox-360-controller-monitor In addition to the high fps camera. Note that display latency of the screen also comes into play during these types of tests. Although, if the latency ever gets as laughably bad as 500ms, a video with just the buttons being pressed in frame will be noticeable. Jerk McJerkface posted:Ha. I'm really hoping someone pulls it off, though. I'm really curious to see how many goon names for the BIBBITYBOBBITYBOO there are. If I have some free time, I'll look into it this weekend. Its a bit more than all caps, since a lot are multi-word, or have hyphenation or other characters, but the power of love regexes should conquer all. Although, as mentioned, the actual annoying part would be the authentication. Also making sure that the crawler is polite, but that's straightforward. Good Dumplings posted:That's, uh... how'd they end up deciding any of this was necessary or a good idea? Do you have a link to this? This is really interesting in a horrifying sort of way. Oh man, I've encountered a lot of horror stories with ridiculously unnecessary serialization / deserialization steps. Including one where someone wrote a custom json parser (not general, had to be modified whenever the data model changed) on a system where the .net json libraries were available  . The rest of it went something like: custom binary format -> json -> custom json parser -> SQL database -> custom json writer -> back to original custom binary format.
|
|
#
?
May 8, 2013 00:22
|
|
|
Good Dumplings posted:That's, uh... how'd they end up deciding any of this was necessary or a good idea? Do you have a link to this? This is really interesting in a horrifying sort of way. Is this so bad? You've gotta have some kind of interface to the Unity API, and JSON is more efficient than passing, say, XML. I guess ideally you'd have a custom protocol which would be more efficient, but would it even really be that much more efficient? I guess they could just use standard java serialization... Aweful Dreams posted:Unfortunately, it's basically something I figured out by following controller lag threads in the dev forum, the info is spread out among a dozen threads on their website, but here's one of the key threads: http://forums.ouya.tv/discussion/comment/9487 (Input Lags extremely when spamming buttons). And the code you're looking for isn't in the compiled ODK, it's in the Unity Package, with the JSON serializing happening in OuyaUnityApplication.java and the deserializing happening in OuyaGameManager.cs. So its nothing to do with OUYA and just how Unity handles things? Nothing to see here folks. Zaphod42 fucked around with this message at 00:34 on May 8, 2013 |
|
#
?
May 8, 2013 00:30
|
|
|
Zaphod42 posted:So its nothing to do with OUYA and just how Unity handles things? Nothing to see here folks. I wonder if anyone has actually profiled it to see where the lag is occuring. Is it on the FOOLEDYA odk side in the deserialization and json parsing or on unity's side. I can't imaging these json controller structures would be big enough to be a huge deal but maybe I'm just wrong.
|
|
#
?
May 8, 2013 00:41
|
|
|
Zaphod42 posted:Is this so bad? You've gotta have some kind of interface to the Unity API, and JSON is more efficient than passing, say, XML. I guess ideally you'd have a custom protocol which would be more efficient, but would it even really be that much more efficient? It's just that I'm not sure why they'd need to serialize anything in the first place. I figured that they'd have some general struct Unity uses that you filled with control states to make it Unity-compatible, not converting a bunch of numbers into a string so you can read a string into those same bunch of numbers (probably) unchanged. This is like a set of nesting dolls, each filled with poo poo.
|
|
#
?
May 8, 2013 00:43
|
|
|
Oops! Someone can't use their EGGSOVEREASY because it shipped missing one vital component. Meanwhile the developer of this https://www.youtube.com/watch?v=dAU4mucktCI Because the OUYA is going to have a huge presence at E3, you see. I'd rather wait in line and read Twitter on my phone or talk to other people in the line. Just being in a line sounds like more fun than that game.
|
|
#
?
May 8, 2013 00:45
|
|
|
I lost it at the HYPERCANE STUDIOS intro. That is some peak 90s multimedia cdrom poo poo going on there.
|
|
#
?
May 8, 2013 00:51
|
|
|
|
| # ? Jun 6, 2024 21:37 |
|
|
XboxPants posted:Apparently there's also some level of bluetooth latency just inherent to Android. From what people are saying, it could be fixed with software, but it'd be a pretty big undertaking. More than OUYA is capable of handling right now, anyway. While I've never actually sat in on a real-deal R&D meeting, I figure this scenario I pulled out of my rear end is light-years ahead of the TOREADOR folks. "We've looked into multiple options and after some extensive testing, we've decided we're going with a modified version of Android for our operating system. We'd like to use Bluetooth for connecting our wireless controllers, but our research team on that end has determined there's a latency issue with Bluetooth devices and Android. We're now looking in to a couple options: One, we could go with a different wireless solution. Two, this could potentially be fixed for our device at the software level for our version of Android. I'm going to need a feasibility study as well as cost and time analyses for both of these options by the end of the week."
|
|
#
?
May 8, 2013 00:59
|
|