Page 5 of 18 FirstFirst ... 3456715 ... LastLast
Results 41 to 50 of 178

Thread: Ouya Game Console Performance Is Disappointing

  1. #41

    Default

    Quote Originally Posted by nikiiv View Post
    That was so biased and based on rumors and not even a single fact that one may think it is sponsored by no other but Steam themselves
    I don't think you have played a single OUYA game to speak about it's performance nor you have done a comparison
    I am not an OUYA advocate but I have always been against throwing stick and stones without anything actual

    You have been bashing OUYA since its first announcement as is you did accept it as a personal archenemy
    I'm one of the most critical people of Larabel on this site, however... Even a blind man could see the Ouya was doomed from the start.

  2. #42
    Join Date
    Oct 2009
    Location
    Brisbane, Queensland, Australia
    Posts
    154

    Default

    +1 what scionicspectre said

    +1 what przemoli said

    +2 what Mike Frett said

  3. #43
    Join Date
    Apr 2013
    Posts
    8

    Default

    I wish the project success, but I think Tegra 3 will really hurt it.

  4. #44
    Join Date
    Feb 2013
    Posts
    240

    Default

    Quote Originally Posted by Squarepusher View Post
    Android is an absolute piece of garbage for any kind of realtime app.
    Quote 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
    Android is generally very competitive with iOS on various OpenGL/CPU/GPU benchmarks even with the Dalvik VM system. Apple's hardware often scores higher, but that is more of a testament to Apple's engineering excellence and better hardware. Benchmarks aren't perfect, but I trust them way more than I trust you.

    Audio latency does seem to have been a legitimate issue. Android 4.2 claims to address this depending on hardware support from manufacturers. From the official Android dev site:
    http://developer.android.com/about/v...elly-bean.html

    "Android 4.2 improves support for low-latency audio playback, starting from the improvements made in Android 4.1 release for audio output latency using OpenSL ES, Soundpool and tone generator APIs. These improvements depend on hardware support devices that offer these low-latency audio features can advertise their support to apps through a hardware feature constant. New AudioManager APIs are provided to query the native audio sample rate and buffer size, for use on devices which claim this feature."
    Also, docs on OpenSL ES for pre Android 4.2:
    http://mobilepearls.com/labs/native-...les/index.html

    As OpenSL ES is a native C API, non-Dalvik application threads which call OpenSL ES have no Dalvik-related overhead such as garbage collection pauses. However, there is no additional performance benefit to the use of OpenSL ES other than this. In particular, use of OpenSL ES does not result in lower audio latency, higher scheduling priority, etc. than what the platform generally provides.
    It doesn't sound like Android's audio latency problems had anything to do with Davlik, virtual machines, or Java.

    Android is taking performance and latency very seriously. Look at the Project Butter 60 FPS locked interface improvements in 4.1. You can also see tons of more detailed performance analysis and improvements on the Android dev site.

    I don't see any evidence that Dalvik or their choice of the Java language has been some kind of permanent problem with Android performance. I would also point out that even console games use some higher level programming language like Lua in some sandbox type runtime to process game logic and it doesn't seem to have disastrous performance consequences.

    Ouya as a whole... The Tegra 3 is just lower performance hardware than what you get with a PS3/360 console. Also, the game selection seems mostly warmed over ports. I am cheering for the Ouya, but this first version doesn't seem like something people would want to buy.

  5. #45
    Join Date
    Mar 2008
    Posts
    210

    Default

    I guess it would be interesting to see the fps min/max range to check variability. That's where GC stalls will hit you. But anyone claiming that java is up to the task of real time hard requirements is deluding themselves. When you want to push the envelope that's where this stuff will bite you.

    About lua: that's a different animal. Lua is typically embedded inside c/c++ applications and not the other way around, and it's also tailored more towards game logic only, not managing memory. Very different animals entirely.

    One advantage the ouya has is that they have their own android distro. They can make sure there's nothing like gmail or other misbehaving applications waiting around to trash out the GC, and I would hope OUYA doesn't put useless uninstallable crapware like you see on many vendor built firmwares.

    Perhaps next gen ouya would ship with a c/c++ pure control and performance oriented system with an android compatibility layer on top to get the best of both worlds (well we can hope, right?).
    Last edited by bnolsen; 04-18-2013 at 04:03 PM.

  6. #46
    Join Date
    Feb 2013
    Posts
    240

    Default

    Quote Originally Posted by bnolsen View Post
    anyone claiming that java is up to the task of real time hard requirements is deluding themselves.
    Why does desktop Java -- which of course uses a completely different runtime than Android -- benchmark so well on something like this:

    http://benchmarksgame.alioth.debian.org/
    look at Java 7 compared to Lua:
    http://benchmarksgame.alioth.debian.org/u32/lua.php

    Why does the Java port of Quake 2 (Jake 2) benchmark at the same level as the official C version of the game on the same hardware?

    Why do super high volume sites like Twitter run primarily on a Java centric back end. They usually have extremely fast response times with extremely large volumes of data. Their code is actually Scala from what they say, but that runs on a Java VM.

    If you mean real time in the sense that you can have more formal proofs of low response times there is even http://www.rtsj.org/

    Also, Android does support C/C++ development. They also have Renderscript which is a C-family language.

    Also, if you want PS3 level graphics or better you need to upgrade from a Tegra 3 chipset. There is no way a programming language is going to get around that.

  7. #47
    Join Date
    Feb 2013
    Posts
    379

    Default

    Was anyone really expecting anything special from this?
    It's just a phone without the phone part. It doesn't even get the bonus points of consoles where they have a small OS designed specifically for graphics calls.

    Also, any GC language is in the end, pretty bad for game programming. I've dealt with it before and I always end up going back to C++, having random garbage collections absolutely ruins your performance. I can't speak for Dalvik/Android, however.
    Last edited by peppercats; 04-18-2013 at 06:35 PM.

  8. #48
    Join Date
    Mar 2008
    Posts
    210

    Default

    Quote Originally Posted by DanLamb View Post
    Why does desktop Java -- which of course uses a completely different runtime than Android -- benchmark so well on something like this:

    http://benchmarksgame.alioth.debian.org/
    look at Java 7 compared to Lua:
    http://benchmarksgame.alioth.debian.org/u32/lua.php

    Why does the Java port of Quake 2 (Jake 2) benchmark at the same level as the official C version of the game on the same hardware?

    Why do super high volume sites like Twitter run primarily on a Java centric back end. They usually have extremely fast response times with extremely large volumes of data. Their code is actually Scala from what they say, but that runs on a Java VM.

    If you mean real time in the sense that you can have more formal proofs of low response times there is even http://www.rtsj.org/

    Also, Android does support C/C++ development. They also have Renderscript which is a C-family language.

    Also, if you want PS3 level graphics or better you need to upgrade from a Tegra 3 chipset. There is no way a programming language is going to get around that.
    Hehe, you just painted a big target onto yourself. It makes zero sense to benchmark java and lua against each other, how they are used is dramatically different. That's just plain foolish.

    If you were right then java should not have been rejected outright on the linux desktop. It most certainly has and for VERY GOOD reason.

    I've also worked enough with java to know that a few hand picked benchmarks does NOT necessarily indicate reality. And there's the elephant in the room: Java applications hog memory like there's no tomorrow. And I'll toss in multithreaded scaling for extra measure (my current specialty).

  9. #49
    Join Date
    May 2011
    Posts
    1,611

    Default

    Quote Originally Posted by bnolsen View Post
    If you were right then java should not have been rejected outright on the linux desktop. It most certainly has and for VERY GOOD reason.
    License reasons.

  10. #50
    Join Date
    Feb 2013
    Posts
    379

    Default

    Quote Originally Posted by DanLamb View Post
    Why does desktop Java -- which of course uses a completely different runtime than Android -- benchmark so well on something like this:

    http://benchmarksgame.alioth.debian.org/
    look at Java 7 compared to Lua:
    http://benchmarksgame.alioth.debian.org/u32/lua.php

    Why does the Java port of Quake 2 (Jake 2) benchmark at the same level as the official C version of the game on the same hardware?

    Why do super high volume sites like Twitter run primarily on a Java centric back end. They usually have extremely fast response times with extremely large volumes of data. Their code is actually Scala from what they say, but that runs on a Java VM.

    If you mean real time in the sense that you can have more formal proofs of low response times there is even http://www.rtsj.org/

    Also, Android does support C/C++ development. They also have Renderscript which is a C-family language.

    Also, if you want PS3 level graphics or better you need to upgrade from a Tegra 3 chipset. There is no way a programming language is going to get around that.
    JVM and Dalvik are completely different beasts.

    Also, in some of those Lua benchmarks I think Lua used almost up to 1/100th(!) the memory of Java.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •