Dear Mark Deloura, I see that you started your first day at Google today. Congratulations on the new gig!
I thought as part of your first day as the new Android games guru, I would make a concise list of things that make game development tough for us full-time Android game developers. 1) Touch events consuming ridiculous amounts of CPU, causing 20-50% reduction in framerates. This is very apparent in 1.6 and back and I believe it is still somewhat there in 2.0/2.1 but it's hard to tell if it's better just because the CPUs are much better on those devices or if the underlying code is actually improved. Either way, I can't put out any 3D games with a hold-your-thumb-down interface because they drop from 30fps to 15fps when controlling and there is no workaround (sleeping like suggested by myself and many hardly does the trick.) 2) Sound APIs are unstable and difficult to work with from a native cross-platform engine. SoundPool is a well-designed class for doing low latency one-shoot and looping sounds played at various rates (I use for engines, and everything else) but it crashes now and then. I don't see it crashing much on 2.0/2.1 but just last night I had a segfault on my G1 (1.6) while testing a new game. AudioTrack in 2.0.1 is also reported to be unstable and has no DirectBuffer interface for getting pcm bytes in from a native mixer. 3) Background processes destroy intense game framerates, even on 2.1. I've been asking for a game mode for a year now. Players probably won't mind shutting off everything but incoming calls if a game asks for it. If it made my gaming lag-free, I'd definitely play that way. Sorry I can't check my email, I'm sort of playing a game right now. 4) With a range of GPUs starting with "none" and going up to "PVR SGX530 and Snapdragon" it's difficult for us to deal with comments like "This game is unplayable" when people install and run a game requiring GPU acceleration on a phone with no GPU. We tell them not to, but they don't listen and then give us 1-star ratings and nasty comments. Yes, we can specify GLES versions in the manifest (which is great!) but both a pixelflinger phone and a G1 are ES1.0 so it's impossible to stop the installs and bad ratings. A simple classification system would do, where a class-1 phone is no GPU, class-2 is MSM7200-era, class-3 is MSM7600, class-4 is SGX530 and Snapdragon speeds, class-5 is whatever the next gen is and so forth and so on. That would allow us to target a game at class-3 and higher GPUs and optionally only ones that support ES2.0 if we so desire. 5) Multitouch on HTC devices is not usable for dual-axis game controls. Perhaps that's not google's issue per se but it is an issue for us devs, regardless of who's responsible. There are several other bugs that are difficult to get anyone to take responsibility for but IMO, these are some of the bigger ones plaguing us today. Feel free to contact me for more details. I've been working with Android game development since Oct of 2008. I'm currently working on my 4th and 5th Android games and would be happy to send them to you to play with. -- 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 To unsubscribe, reply using "remove me" as the subject.
