Re: [android-developers] Re: Windows Phone and XNA. Nightmare is real. What we do with that ?
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
Re: [android-developers] Re: Windows Phone and XNA. Nightmare is real. What we do with that ?
On Wed, Mar 17, 2010 at 1:48 PM, Piotr piotr.zag...@gmail.com wrote: I say it again, hoping that some Google Worker is watching :D: ... and right here is where your effort ends, and the whole concept becomes little more than hot air. Google are not a gaming company, they are not even a commercial software vendor. Google are a SAAS company. They develop and host Web-based services and products, and engage in technology that increase the market share and accessibility of those services. Please take your (potentially) great ideas, concepts and designs to the next level. Work out a business plan, build a community (or a company), and GET IT DONE. Don't analyse an area of software market and tell Google they should do it, they pay their own risk managers and market analysts to do that. If you can find a way to make your XNA-like gaming platform valuable to the advertising industry - at that point you're likely to get some serious interest from Google. -- 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
Re: [android-developers] Re: Windows Phone and XNA. Nightmare is real. What we do with that ?
Does this framework support simple 2d physics and collision detection and/or elastic collision? Jiri On 10/03/2010 01:11, Mario Zechner wrote: While it's not nearly as full featured as XNA i started working on something similar to XNA. It allows you to develop your games mostly on the desktop and deploying it to your Android device with just a couple of lines that instantiate a special Activity subclass. It's based on OpenGL and allows developing 2D and 3D games. I just finished writting all the java doc for it and am constantly adding new features to it. It's called libgdx and can be found at http://code.google.com/p/libgdx/. I also started blogging about it lately and will continue so adding sample codes for specific problems. You can find that blog at http://www.badlogicgames.com. An introduction to it can be found at http://apistudios.com/hosted/marzec/badlogic/wordpress/?p=274. A series of small tutorials wil follow this week and next week. The whole thing is LGPL so that there's no problem including it in commercial apps. It's far from being perfect of course but i think the base functionality and ease of use can kill some of the burden a fresh android game developer has to overcome. I'm open for suggestions and features you want to see in there! On 9 Mrz., 22:35, Piotrpiotr.zag...@gmail.com wrote: Hello, At my daily job I work as WinMo C++ developer, so I had enough time to become hater of that platform ;) But now, M$ is coming with new Windows Phone. As I suspected, they will abandon awful Win32/MFC native coding and all applications, will be now managed - run in CLR sandboxes on top of 15 years old Win32 kernel. Main coding language will be C# with .NET framework - Java rival. WinMo always was terrible phone OS, but now, more interesting is, that Windows Phone will support XNA framework: http://www.youtube.com/watch?v=LQv_3fwopo8 This is full gaming framework with C# interfaces and support for 2D/3D graphics, animation, sprites, net play, game sound, controllers, etc.. XNA greatly improves creating games, because it gives a developer an ready to use game abstraction layer. To the point; Android needs game framework, like XNA. Maybe it should be written as NDK library, ready to link with your own application. This library could load, manage and draw sprites, backgrounds, make simple physics, etc.. Why ? To create games faster, easier. At this time, you must be very skilled to create simple platformer with 2 bkgs and 5 sprites. Our devices have even 1GHz CPU's and animation can be STILL too slow ! I'm tired of the same logical bricks/ball/falling diamonds games over and over. What do you think ? Is there any chance, that Google will work on something like that ? -- 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
Re: [android-developers] Re: Windows Phone and XNA. Nightmare is real. What we do with that ?
On Wed, Mar 17, 2010 at 2:25 PM, Streets Of Boston flyingdutc...@gmail.com wrote: True and not true. If google thinks that making an XNA like framework could enhance Android's adoption and device sales enough to bring more ad-revenues/ SaaS-revenues (because more phones would be around if such a framework existed), then google could be interested in creating such framework. However, if the potiential return on such a framework is not large enough, then they won't do it. You are of course correct, though I firmly believe spending lots of time speculating on such things will 100% fail to actually get the work done. There is also the question of whether Google are the ideal company to produce such a framework. Microsoft have invested a lot in DirectX and their XBox projects, they have the experience and the partners to make it work. What experience do Google have in the games industry? Personally I think they are stretching themselves enough with their shoulder barging into the mobile market, without trying to dive into the centre of the extremely competitive games market. Having said that, the Android platform does need to compete in this field. This seems like the perfect opportunity for a start-up, or an established games development company, to build a native framework and contribute it upstream. Mario's library might be a good starting point for this - as well as a technical evaluation of the other libraries/engines out there (such as Rokon by StickyCoding). The way to move forward would be to actively pursue a solution though, rather than mull around the topic passing notes to Google like we were in the Peoples' Front of Judea. :) -- 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
Re: [android-developers] Re: Windows Phone and XNA. Nightmare is real. What we do with that ?
Great thread. I happen to agree with both sides of this argument. While I like the idea of several of the current native/java game engines maybe collaborating, coming up with some sort of presentation on why it's prudent for Android to have a much more solid game capable api/sdk, I also think that Google/Android has sort of said Yes, apple/iPhone, we'll take you on, and maybe beat you at your game. There has been tons of articles showing how android will surpass iPhone in a couple years. Yet, I forget the percentage now, but I thought it was some 35% of the iPhone market is games.. and there has to be a decent population for audio apps. That's a pretty good sized market and to ignore that would to me be a potential death sentence for Android. Maybe not... just my gut. I think most teens/young twenties and a lot of us older adults that grew up with games look at platforms like Nintendo DS, PSP, and then compare to our droid/nexus, iPhones, etc and realize we have a much more capable bit of hardware in our single device.. why not make it a game/audio app/utility app/phone/calendar/internet tool all in one. iPhone is already clearly taking a chunk of Nintendo DS sales.. they say so themselves. Android devices like the Droid, Nexus, and many new phones coming out have 600+mhz cpus, lots of memory, etc.. they easily are more powrful than hand held game devices and we know that even before iPhone/Android that crappy mobile games on J2ME were huge all over the world. So while I don't know if it should fall squarely on google to build some robust gaming kit like XNA, I do think they should invest heavily right now, for a 3.0 release within the next year, that gives us a JIT, a lot more native access to things like audio hardware for low latency, and find a way to curb some of the potential GC issues many threads have brought up. I think right now, within this year, is the time that google has to really flesh out a solid much improved Android 3.0 that can compete on most levels with iPhone and keep in mind iPhone 4.0 due out in a few months will add multi-tasking (dying to see how they do this without breaking existing apps and how they are coded), more features, etc. I think in many many ways Android is a lot better than iPhone or anything MS will put out. At the very least, I think it would be great for Google/Android team to figure out IF they are planning on doing anything close to the above... and let us developers know. I know many developers have said, and I too am waiting to see a much improved audio capability so that apps like iPhone BeatMaker and such can come out. Likewise this impacts game developers, along with other variables that many developers are quite clearly saying is impacting them on being able to build better games. The screen touch issue that is causing massive lag on input and slowing games down greatly, and the buggy multi-touch capabilities... all of these things need to be wrapped up into a 3.0, or a 2.5, 2.6 etc in the coming year so that developers get a few months or longer to make use of them and put out some really good games, music apps and such by mid 2011. Not that it will be game over, but I would think that this is important enough to developers that google/android team should listen and perhaps keep the developers posted on up coming changes to the platform. Is there any site that covers what is being worked on right now? Is there any info that we can read about, maybe provide some input on, that might be coming up in 2.2, 2.3, 2.5, 3.0, etc? I mean, if 3.0 is just getting started, perhaps nows the time to solicit the developers that will write apps for the platform and keep it alive for ideas and what is most important that they need to want to keep writing for Android. Just my .02. On Wed, Mar 17, 2010 at 7:40 PM, Bob Kerns r...@acm.org wrote: I'd say instead that it doesn't NEED to slow you down. But if you store your entire scene graph on the native side, but do all the manipulation of it on the Java side, with a lot of Java-Java calls dispatched by the JNI layer in between, and lots of arrays getting locked or copied -- I guarantee you'll regret it. But if you start with an intelligent architecture, so you're not just replacing lots of Java calls to trivial code with JNI calls to trivial code, you will usually be OK. Chris Pruett's strategy as he outlined it in this talk: http://code.google.com/events/io/2009/sessions/WritingRealTimeGamesAndroid.html I find to be a very solid strategy. BTW, the argument against moving things *unnecessarily* to JNI is not just one of performance. It is also negatively affects how quickly you can modify the code, how well you can test it, and how many bugs you'll ship with. But so will doing weird things in Java to try to get it fast enough. There's a point where it makes sense to move a body of code to JNI. It's somewhere after you benchmark and think about the problem for a bit, and before you drive
