Announcement

Collapse
No announcement yet.

Ouya Game Console Performance Is Disappointing

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by Kivada View Post
    If you stripped Android from it it'd maybe make a decent playback only HTPC.
    Stripping Android from it would actually hurt it's functions as a HTPC. As it has been mentioned, xbmc already works fine with the Ouya and sticking with Android means that you can still utilize services like Netflix/Hulu and still utilize features that they offer like "SuperHD" and AC-3 surround. Those features are missing on the PC web browser versions of those services. Switching it to linux would actually reduce those capabilities. I've got an Ouya and eagerly awaiting it for just plain HTPC purposes and never wanted it for games in the first place.

    Comment


    • #17
      Gaming history is littered with underpowered devices that have achieved amazing gaming experiences despite their limitations. I don't expect there are too many games that will force OUYA over the edge, but I may just be out of touch with Android gaming. To suggest we should expect something like the graphics we see on the PS3 or XBOX 360 become common on Android in the short-term is a bit unrealistic, although in a couple years things may have accelerated at an exceptional pace.

      I think the OUYA has played its cards right by focusing on a low price-point and developers, since there will be plenty of people willing to get a cheap home console for fun, not for graphics. I'm not sure if they would get more business by focusing on high-end graphics at a higher price.

      Comment


      • #18
        @Michael

        And actual tests about actual GAMES?

        IIRC (<- irony..) current gen consoles are weaker than current gen PC's, and still nobody mind that (but PC gamers who would use some better gfx in their ports of console games )

        So lets wait and see what game devs can offer us.

        (And Futuremark claim that they can do cross platform, cross api test with comparable results just by offering same pre-sets....)

        Comment


        • #19
          Too little, too late

          Ouya would have been great if it was released a year ago.
          Technology moves forward and Ouya is getting behind.

          Maybe will be decent as a HTPC and server, kind of like what many people use Raspberry Pi for.
          At least it is ARMv7, not ARMv6 unlike Raspberry Pi.

          Comment


          • #20
            Any good project director would bring the project back into line with market expectations. This means advancing the the grunt of the unit.

            I think phase one kick-starter unit recipients will understand if the public release is more powerful, so as to save the overall project.

            Comment


            • #21
              Guess what

              It's not about performance, it's about content. And, if you have seen the amount of Games and Apps available at launch for the Ouya, it's quite spectacular. But hey, the PS3 and 360 specs are quite disappointing by todays standards also. Besides, you've all had a year to study this, being surprised of the performance is ignorance and laziness; in which case we probably don't want you developing for it anyway.

              Comment


              • #22
                Originally posted by dalingrin View Post
                "Good god, people, how naive can you be?"
                Funny, that was exactly my thoughts when I read your post. Real consoles do multitask to some degree. Next generation even more so. Android isn't slowing down the performance that much, particularly OpenGL. Tegra 3 never had a fast GPU, only good marketing and decent drivers.



                ^ This.
                I am sorry but as the developer of RetroArch (an app where we NEED relatively good audio and video latency to maintain any kind of decent audio-video synchronization), I can tell you that you couldn't be more wrong about this.

                Android is an absolute piece of garbage for any kind of realtime app - the audio latency is so bad that it makes the PS3's 40ms audio latency on the audio server seem almost 'low latency' by comparison.

                Please stop perpetuating this 'myth' that Android is 'just fine' for games or realtime apps - it is not - it is a bad, sad joke, and iOS/QNX makes absolute mincemeat of it.

                Find me one guy that has something favorable to say about Android from a performance standpoint compared to iOS/QNX- you can't find one because the thing can't be defended. It was the absolute worst idea on Earth to base an OS (INTENDED FOR A MOBILE PLATFORM) around some piece of garbage Java VM which has a bad habit of eating RAM like no tomorrow (minimum RAM requirements for Android 4.2.2 are now 768MB RAM - FOR A MOBILE OS!!! This is absolute insanity).

                Oh BTW - since you mentioned OpenGL - I should mention to you that the OpenGL side is also written in Java - as is the audio side (AudioFlinger) -as is the input side (InputEvent service) - as is everything on this goddamn piece of garbage OS. And guess what? Everything you do (whether it is some stupid innocuous weather app - written in Java - or whether it is this crappy OpenGL implementation in Java - or whether it is the crappy audio subsystem) CAN AND WILL at any time invoke the Dalvik garbage collector - and guess what that does to your performance?

                Oh BTW - I saw somebody saying that XBMC 'runs just fine on my Android phone' - no it doesn't - the audio lag is terrible and it pretty much makes any movie you play unwatchable. Try XBMC on iOS however and be amazed at how well it runs by comparison.

                And no, I am not employed by Apple - I don't like Apple's restrictions either - but it's an inconvenient truth that Apple - despite the douchebaggy company it is - has their shit together on the technical side while Google doesn't. I'd expect the badly amateuristic hack that is Android to emerge from some startup company - NOT from a multibillion dollar company that struts around like it owns the world (ie. Google) while pretending it can do no harm.

                Oh BTW - please do 'debate me' on this - I'm looking quite forward to seeing you defend the absolutely terrible runtime performance that this piece of garbage - Android - delivers to developers who are actually going to the effort of writing non-managed code for it - it will be quite amusing to see the amount of denial about this particular piece of crapware.
                Last edited by Squarepusher; 04-16-2013, 08:28 AM.

                Comment


                • #23
                  Originally posted by Squarepusher View Post
                  ...
                  It was the absolute worst idea on Earth to base an OS (INTENDED FOR A MOBILE PLATFORM) around some piece of garbage Java VM which has a bad habit of eating RAM like no tomorrow (minimum RAM requirements for Android 4.2.2 are now 768MB RAM - FOR A MOBILE OS!!! This is absolute insanity).
                  ...
                  Maybe the ubuntu phone OS will fix that for us since it is developed in C/C++ so no intermediary JIT or VM needed to execute instructions.

                  Comment


                  • #24
                    Originally posted by uid313 View Post
                    Ouya would have been great if it was released a year ago.
                    Technology moves forward and Ouya is getting behind.

                    Maybe will be decent as a HTPC and server, kind of like what many people use Raspberry Pi for.
                    At least it is ARMv7, not ARMv6 unlike Raspberry Pi.
                    Those are good points - the one about RPi stands out to me, because today you can get something like the MK802 II for about the same price and probably triple the performance while being a smaller device. RPi, IMO, is great for what it was intended for, which was NOT media stuff and XBMC. I feel a little bad for the devs of RPi because people just blindly bought it thinking "oh I'll just make a media PC out of it" not realizing that it isn't going to be very good at that, and then people start trash talking about it because it isn't some high-end performer that they somehow expected of it. These are the same people who want 512MB of RAM and SATA and all that stuff. Some people really don't understand why things cost the way they do.

                    For the record, RPi was intended for education and development. That being said, it's hardware is more than sufficient.

                    Comment


                    • #25
                      Originally posted by Squarepusher View Post
                      Oh BTW - I saw somebody saying that XBMC 'runs just fine on my Android phone' - no it doesn't - the audio lag is terrible and it pretty much makes any movie you play unwatchable. Try XBMC on iOS however and be amazed at how well it runs by comparison.
                      My Pivos plays and runs XBMC just as fine as any of my iOS devices (all however are far better performing the Raspberry Pi which is running linux). So much for your theory, as that statement is pure BS. Perhaps you saw a version of XBMC running on an android device that did not have any acceleration support.

                      Comment


                      • #26
                        Originally posted by deanjo View Post
                        My Pivos plays and runs XBMC just as fine as any of my iOS devices (all however are far better performing the Raspberry Pi which is running linux). So much for your theory, as that statement is pure BS. Perhaps you saw a version of XBMC running on an android device that did not have any acceleration support.
                        I'm sorry but you are either lying or you can simply not tell the difference between the iOS version or the Android version based on some technical inability to perceive the very clear differences.

                        The Android version can never be as good as the iOS version because of the disastrous and totally dogshit audio latency that is STILL an issue to this day (no, the 'OpenSL fast mixer' path was only for one phone - and even then it still pales in comparison to CoreAudio on iOS). It can also never be as good as the iOS version because of the simple fact that you don't have a Java garbage collector that is hellbent on trashing your runtime performance at a periodical basis (make that every 5 minutes if you're running Google's crapware Play Store services as they seem to like to rely on the garbage collector - 'memory management' is soooo '90s, as is performance apparently). How are you likin' those 20 to 50ms garbage collector stalls?

                        So please - come up with some real performance figures and don't com with your 'appeal to authority - I am a moderator so I can make a vague claim like 'My Pivos plays and runs XBMC just as fine as any of my iOS devices' - that tells us exactly nothing. Notice I actually provided details and facts as opposed to 'my Pivos just runs XBMC fine' - you might want to start upping your game in that department if you want to have any hope of winning this argument. So much for 'pure BS' and who exactly is putting that into practice.

                        Comment


                        • #27
                          Lastly, to the moderator I'd say -

                          if you are not a dev, then your opinion doesn't count. The ground rules are very simple - if you are not a dev, you don't have a frame of reference on any of this. Period. I don't care if you can run a benchmark or not - that does not make you knowledgeable on anything.

                          Once you become a dev, you can start grasping what an absolute unmitigated disaster a garbage collector is to your average runtime performance (especially when said OS puts you inside a Java VM as your 'jail').
                          Last edited by Squarepusher; 04-16-2013, 11:45 AM.

                          Comment


                          • #28
                            Originally posted by Squarepusher View Post
                            Lastly, to the moderator I'd say -

                            if you are not a dev, then your opinion doesn't count. The ground rules are very simple - if you are not a dev, you don't have a frame of reference on any of this. Period. I don't care if you can run a benchmark or not - that does not make you knowledgeable on anything.

                            Once you become a dev, you can start grasping what an absolute unmitigated disaster a garbage collector is to your average runtime performance (especially when said OS puts you inside a Java VM as your 'jail').
                            I haven't tackled anything android yet, but how much can you jam into the NDK to avoid java and GC? I do realize this is inferior to just doing it in c++ (or c). You would hope google would in the future provide a way for developers who care to totally avoid java where control and performance matters.

                            Comment


                            • #29
                              Originally posted by bnolsen View Post
                              I haven't tackled anything android yet, but how much can you jam into the NDK to avoid java and GC? I do realize this is inferior to just doing it in c++ (or c). You would hope google would in the future provide a way for developers who care to totally avoid java where control and performance matters.
                              Well, the 'native activity' is kinda a misnomer - what it is, is just 'glue code' so that your native code (compiled as a dynamic shared library) can interface with Android's lifecycle system through a bidirectional pipe. This means that your native code is actually running on a secondary Java thread and that it has to continually send interprocess communication calls to to the main Java thread that it is still alive. If it doesn't respond to any disputched input events for instance within 5 seconds, then the main Java thread assumes that your program got unresponsive and it will issue an 'ANR' (Application Not Responsive) and will ask you to kill it.

                              Anyway, a 'native activity' is just some kind of hack therefore where your native code compiled as a library (and interfaced through JNI) can work in your Java app. However, none of the 'NDK API' functions are actually native code - the OpenGL NDK code just tallks to the OpenGL Java service which in turn talks to Binder IPC. For audio, OpenSL still talks to AudioFlinger which is a Java service. Same with input - the NDK actually prevents you from reading from /dev/input/event directly - everything has to go through InputEventService and the Java side 'pumps' the input to your native code and you just need to 'react' to it.

                              Anyway, a 'native activity' is not 'real' native code - there are still a hundred and one possibilities for any of these upper layers to trigger garbage collector stalls - and these can range from 2 to 20 and even 50ms. What is even worse is that you have no control over 'services' that might be running concurrently with your app - for instance, if the lovely email service decides it needs to check your mail every five minutes while you are playing a game, then you are going to get pummeled with lovely garbage collector stalls that can ruin your framerate. Worse still, the worst offenders that I have logged turns out to be services like Google's Play Store services and there is absolutely no way to turn those periodic scan intervals off. In the end you walk away with the sense that Google cares more about datamining everybody's ass than they care about giving you any decent kind of runtime performance.

                              Anyway, for apps where you need realtime tight syncing, Android is an absolute disaster and you're just better off going with iOS/QNX - sad but true but it is really quite bad. We can only hope that ARM Linux starts getting somewhere even if it means having to interface with Android GPU driver binary blobs - already the memory requirements are insane (768MB for Android 4.2.2) and that is bound to increase as they keep piling more and more frills eye candy stuff onto this thing. It is simply an ill fit for a mobile OS and they just got the entire thing backwards - it is so bloated it should really be centred around desktop computers and even then nobody would want to deal with it.

                              Comment


                              • #30
                                Originally posted by Squarepusher View Post
                                I'm sorry but you are either lying or you can simply not tell the difference between the iOS version or the Android version based on some technical inability to perceive the very clear differences.

                                The Android version can never be as good as the iOS version because of the disastrous and totally dogshit audio latency that is STILL an issue to this day (no, the 'OpenSL fast mixer' path was only for one phone - and even then it still pales in comparison to CoreAudio on iOS). It can also never be as good as the iOS version because of the simple fact that you don't have a Java garbage collector that is hellbent on trashing your runtime performance at a periodical basis (make that every 5 minutes if you're running Google's crapware Play Store services as they seem to like to rely on the garbage collector - 'memory management' is soooo '90s, as is performance apparently). How are you likin' those 20 to 50ms garbage collector stalls?

                                So please - come up with some real performance figures and don't com with your 'appeal to authority - I am a moderator so I can make a vague claim like 'My Pivos plays and runs XBMC just as fine as any of my iOS devices' - that tells us exactly nothing. Notice I actually provided details and facts as opposed to 'my Pivos just runs XBMC fine' - you might want to start upping your game in that department if you want to have any hope of winning this argument. So much for 'pure BS' and who exactly is putting that into practice.
                                Latency is not an issue with video playback. AE takes care of the timing and keeping it in sync with the video. Furthermore, when working with passthru audio it become nearly a non-existent issue. This is further more backed up by XBMC's own statistic counter which accurately displays AV sync errors. Latency for video playback is a non factor in most scenarios. Where it would come into play is would be realtime mixing with recording, again not an issue with playback. Garbage collector stalls are also easily overcome with a proper playback buffer.

                                Comment

                                Working...
                                X