Hi Markus, 2010/3/14 markusn82 <markus...@gmail.com>
> Thanks for the input guys. > > Lance, good point about users using the controls in unexpected ways. > This actually happened to me for my first release, but I have since > resolved those issues and users are quite happy with the current > control scheme. In addition, I have already implemented the Sleep() in > dispatchTouchEvent() trick for preventing the flood of touch input > events. > > I have already lamented about the touch slow down in another thread. And indeed this is a serious problem for my game I currently develop. In my game you can shoot either by pressing the track ball, or by touching the screen. Shooting by the trackball does not slow down the game in any way. But, shooting by touching the screen can bring the game down to it knees! If I touch the screen and keep the finger down frame rate drops by roughly 20-30% The effect is less visible since I switched to VBOs. I assume this is because the GPU does most processing and there are lots of cpu cycles left for touch processing. What can nearly kill the game play is shooting (touching the screen) with 5Hz. If I very quickly tap the screen I can bring the frame rate down to below 10 FPS. Unfortunately in my game shooting by touching has the advantage that you can shoot at the position you tap on the screen. So only allowing trackball or hardware key input is not an option. Considering I'm using a Nexus One I assume the situation might be much worse on devices with lower hardware specs. ... This touch slow down can indeed be described as a lag. By the way, I'm pretty sure I don't do anything wrong with touch processing. I think the problem is deep down in the software stack, so even going the forbidden route and linking to "unsupported libraries" ( I'm developing using the NDK, too) can probably not solve THIS problem. > From what you guys have said so far, it really does seem like the main > problem is the GC randomly executing from other processes. This seems > to be a big issue for real-time games on the platform. I actually > noticed that most of the top paid games on the Android market aren't > real-time games... I guess this is due to lag issues dragging down the > ratings. > > I have not recognized any problems with the GC, except that the motion events gets garbage collected every now and then. Oh, I forgot there is a serious GC problem if you process camera preview frames (going the forbidden route and linking to unsupported libs can solve this - but I decided to not go this route, at least for this game). I don't have many background apps running, may be that's the reason my games runs smoothly as long as I keep the fingers from the screen. So, yes I think Android is really not an ideal game platform as long as some fundamental performance problems are solved. In addition there is this multi touch problem, described in another thread. It does not help that I think this is an hardware issue and not a software problem. Even if future devices can track 10 positions flawlessly - there is still a lot of hardware out there which does not support multi touch properly. Anyway, I guess we have to live with the current flaws and work around as good as we can. There is also the irrational hope Google will care and do something about it, but I have the feeling hardcore games are not the main focus. Besides this - who knows may be Microsoft really comes up with on new good mobile OS, so there is an additional alternative to the IPhone. Regards, Ralf -- 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
