Here's a good video if you want to pick up the basics Mark: http://code.google.com/events/io/2009/sessions/WritingRealTimeGamesAndroid.html
Includes coverage of the GC issue by a Googler. On Mar 14, 11:10 am, Mark Murphy <mmur...@commonsware.com> wrote: > 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/threa... > > > 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 onhttp://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
