WARNING: this is a rant, because blaming Google for technical problems based on limited analysis is a bit of sore spot with me. This is not a rant against you as a person, nor against your game (I don't even know what game it is). It is, however, a rant against your methodology, at least to the extent that you described in your two posts on this thread. If you have done much more analysis than what you have described, and just failed to mention any of that, I apologize in advance.
markusn82 wrote: > From what you guys have said so far, it really does seem like the main > problem is the GC randomly executing from other processes. And your proof of this is...what, exactly? You haven't supplied any. > This seems > to be a big issue for real-time games on the platform. And your proof of this is...what, exactly? You haven't supplied any. > 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. And your proof of this is...what, exactly? You haven't supplied any. At this point, you may sense a theme. :-) FWIW, if you keep reading, I have some suggestions of how you can try to get this proof. > The way I see it, there are several possible solutions in the future: > > 1) Improved virtual machine with less intrusive GC (concurrent/ > incremental). As of Android 1.6, "background threads now get placed in a scheduling class that together can't use more than 5-10% of the CPU; this helps a lot in keeping the foreground responsive." http://groups.google.com/group/android-developers/browse_thread/thread/a51e702f8eea4c9f/4d1192f86b67ce23 > In any case, having the GC "stop the world" at random points in time > is really a blocker right now for real-time games. And your proof that this is occurring is...what, exactly? You haven't supplied any. By your own admission, you haven't figured out where the lags are *in your own game on your own hardware*: "I tested the game on both a Motorola Milestone and an HTC Magic and I don't experience any noticeable input lag (except perhaps when the GC is executed by other processes) " "Perhaps" is not what I would consider much in the way of proof. There probably is something going on that is affecting your users. If you find proof that it is *PURELY GC* (i.e., it's not other apps doing work, it is other apps doing work that generates garbage and it is the GC operation that is the frame rate thief, not the work itself), document it, preferably in an issue on http://b.android.com. Heck, forward me the link for it, if you'd like. Now, I don't write real-time games. Frankly, I wouldn't know where to begin. However, I've played with enough games that I know you can somehow determine your frame rate dynamically. Since GC operations get logged in logcat with timestamps, determining if it is GC itself, therefore, should be matter of: -- Paying attention to your frame rates -- Making a record (in memory) of the timestamp your frame rate drops below some threshold (and, perhaps, the timestamp of when the frame rate returns to normal) -- On game end, dump those records to logcat or the SD card or something -- Compare timestamps to see if the frame rate drops coincide with GC going on Since GC is normally asynchronous and delayed from background processing work, what I would expect to see is a close correlation if it is GC itself that is the problem and a leading effect (frame rate drops before GCs) if it is more tied to background work being done. You might also consider adding this sort of instrumentation to the production app. In that case, you would dump some sort of lag report (including device and firmware rev) to yourself via Flurry or email or whatever at the end of a game. That way, you can start getting much more concrete data from the field of what your users experience, rather than relying purely on comments. Timestamps of the lags may or may not prove relevant, but the number and frequency of such lags will give you a sense of scope. You could even perhaps include in the lag report some information on where in the game the user was when the lag occurred (e.g., certain functions or rooms or actions), to see if you deduce a pattern that might indicate the problem is actually in the game itself, rather than coming from outside forces. In other words, get scientific about this. You can find the culprit, or at least get closer than you have so far. These are just some possibilities -- I am sure there are others, and probably better ones, that you can come up with, given your knowledge of your game. And, FWIW, if you do the analysis and come up with stronger proof of where the problem is, not only will you help your game and your users, but if you write up your techniques, you can help Android game developers as a whole, and perhaps Android itself. > Google, do you have > any plans to address this in future Android releases? Until such time as you have demonstrated what is the source of your problem, could you please stop casting blame? -- Mark Murphy (a Commons Guy) http://commonsware.com | http://twitter.com/commonsguy Android Consulting/App Development: http://commonsware.com/consulting -- 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
