Extremely well written post Bob, thanks a lot for that. I can totally agree to your statements and can confirm that the bottleneck in games is not the Dalvik VM and therefor Java for almost all parts of a game. What kills performance at the moment is way down in the chain at the hardware level. Fill-rate limits are the biggest issue we game developers have to face at the moment. Everything else does not contribute much, implementing your whole game in C does not solve that problem. And i speak from personal experience in this case :)
On a side note: ExDeus was not developed with the NDK. The game is actually a port of an IPhone version so it was developed with the IPhone tools for the most part. Those feature a native debugger. The Android version is probably only different in setting up the gl surface and processing input. On 11 Mrz., 17:01, Bob Kerns <r...@acm.org> wrote: > This comment is perhaps a bit off your main topic, and I don't mean it > to derail your efforts or to criticize. > > But I have a bit of a problem with your statement "Java is just too > slow...", taken as a general statement. Perhaps you have benchmark > data showing specific performance problems, and found it so; I'm not > disputing that. > > However, the performance landscape is a lot more complex than this > would suggest, if taken beyond your context. In particular, there are > at least 4 performance areas to consider here: > > 1) Java performance -- which is actually generally quite good in the > desktop/server world; I've not done any Android benchmarking. > 2) JNI performance -- there's added cost per switch to native code; > sometimes it's better to do more work in Java to avoid this overhead, > or to batch up work and do more per JNI call. > 3) OpenGL library/driver performance. This is both the stuff that's > done in software in preparing for the GPU pipeline, and how > effectively it makes use of the hardware, and failures to use > capabilities that exist in the hardware. > 4) The GPU hardware itself > > Judging from the reports I see here (and not personal experience on > this platform as yet), a lot of the performance problems we see are > further down this chain. Better graphics hardware and better drivers > push the bottlenecks up the chain; faster main processors and Java VM > improvements push them down. But where you encounter the bottleneck > will always depend on just what the application is doing. Textures are > a big part of that, as is managing levels of detail so you don't waste > time rendering detail that isn't really noticeable. There are a lot of > ways to use OpenGL poorly. And there are a lot of ways to use it well, > but push the limits in the search for image quality. > > Pushing things down in to C++ is just going to harm developers, if > it's not actually where the bottleneck is. As Mario says, you have to > choose carefully. Do you move your physics engine into C++ -- or just > the matrix multiplications? Or perhaps just significant components, > like collision detection and the timestep integrations? If you push > stuff down to C++, how do you allow for customization, without > incurring the JNI callback overhead? > > Part of what I'm getting at is that because apps are different, the > optimal tradeoff will differ. I'm not sure that Google providing a > framework would be the way to go. Obviously, each developer > implementing their own isn't a good thing either. I think shared > community efforts, or commercial libraries make a lot more sense > (though there could be an "official" library as one of these options). > > This is especially true of physics engines. > > But there is such wide variation in what demands an application makes > of 3D rendering that blanket statements like "Java is too slow" > conceal the issues. > > So I would council against blindly pushing stuff down to native code > based on such broad statements, but rather doing so conservatively, > based on realistic benchmarks. > > On Mar 10, 2:35 am, Piotr <piotr.zag...@gmail.com> wrote: > > > Both these frameworks are interesting, but as I mentioned before; it > > could be better, to create low-level, native NDK game framework > > library. Java is just too slow to handle thousands opengl calls per > > second for any game more complex than "falling bricks" or sth. > > > Such framework could load game elements (maps, tiles, sprites, bkgs, > > sounds), giving developer control interface set to call high level > > methods like setSpriteSpeed, setBackgroundScroll, manageSpritePhysics, > > etc.. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
