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
