Thanks Lance for the suggested reading. I actually read those slides almost a year ago when they were first produced (around the time when I first started to develop a game for Android). I already took into account the points made in that presentation and they were quite helpful.
Mark Murphy, it doesn't sound like you were trying to be productive in your original post. Rather it sounded like you just wanted to blow off some steam (for what reason I don't know) and you were taking it out on my post. I don't believe I ever sounded like I was just complaining and trying to blame my problems on Google. Rather, I was trying to make real suggestions for a real problem that exists. Many developers including myself have made tremendous efforts in working around the "challenges" of developing real-time games on Android. My efforts include: - pre-loading textures before gameplay - writing most of the game in native code and providing JNI bridges only where necessary - using only fixed point math during run-time since most older handsets don't have FPUs - separate threads for input, gameplay, and rendering for smooth input and to avoid GPU blocks - never allocating VM heap during gameplay and always calling system.GC when its appropriate - optimizing renderer for tile-based GPUs You're telling me to look to my own app for problems and not "blame Google"? I've stuck it out with the platform from day 1 even though developing games on the iPhone would have been much easier. I re-wrote my entire engine when the NDK came out just to squeeze out every last bit of performance. Despite all these efforts the game still ends up having spikes in its FPS due to the garbage collector. When the GC executes from other processes, it always takes up ~100-300 ms.. thats a deal breaker for a real-time game. Its quite clear that this is a big problem and I think its productive to raise such issues in a public forum. On Mar 14, 3:38 pm, Lance Nanek <lna...@gmail.com> wrote: > Here's a good video if you want to pick up the basics > Mark:http://code.google.com/events/io/2009/sessions/WritingRealTimeGamesAn... > > 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
