Meh. I think its important to keep your finger on the pulse of trends... but the fact is no matter how. Good. Frramework is.... they may and try apple shenanigans... which makes the scare null andvoid
On Mar 17, 2010 6:48 AM, "Piotr" <piotr.zag...@gmail.com> wrote: M$ has show already done great XNA gaming framework with VS Express NET 4 for Win Phone 7, ready to download: http://developer.windowsphone.com/windows-phone-7-series/ I bet, most developers will choose WinPhone to create games, if they can just create their games for Zune, X360, PC and WinPhone at once, and because C#/XNA programming is much simplier and takes less time than dealing with Canvas optimization, NDK or OpenGL calls and other stuff, that most developers just do not know how, or do not want to do. I say it again, hoping that some Google Worker is watching :D: Android NEEDS something like XNA. Not for you, professional game makers, but for all community of developers, who want to start with game creation. Creating games is not only a coding, but mostly an art. Good tools allow to focus on art. Lack of tools = poor games, because developers with great ideas will waste their energy on creating tools, not an art. On 11 Mar, 22:25, Mario Zechner <badlogicga...@gmail.com> wrote: > 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 agame. > What kills performance at the moment is way down in the chain at the > hardware level. Fill-rate limits are the biggest issue wegame > developers have to face at the moment. Everything else does not > contribute much, implementing your wholegamein 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. Thegameis > 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 NDKgameframework > > > library. Java is just too slow to handle thousands opengl calls per > > > second for anygamemore complex than "falling bricks" or sth. > > > > Such framework could loadgameelements (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<android-developers%2bunsubscr...@googlegroups.com> For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- 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
