Actually I don't understand the need to separate rendering and game logic threads. If game state isn't changed there is nothing new to draw. Why bother rendering the same frame several times? It makes sense if there are two game state sets. For ex. OpenGL thread renders current frame using current vertex buffer while game logic thread updates another vertex buffer with new data.
On 12 ноя, 23:28, Lance Nanek <lna...@gmail.com> wrote: > There's a good blog post on this issue re games > here:http://replicaisland.blogspot.com/2009/10/rendering-with-two-threads.... > > I started doing game updates in a separate thread, instead of on the > render thread, in an OpenGL game I've been writing recently as well. > It did result in some improvement. > > I normally log frame rate stats every 300 calls to onDrawFrame. The > longest time between calls, ignoring times when the garbage collector > triggers, used to be ~100ms. Doing updates in a separate thread cut > that measurement down by about 10-20ms. > > On Nov 12, 10:55 am, Neilz <neilhorn...@googlemail.com> wrote: > > > > > Well yes, but that isn't quite the same thing, is it? In LunarLander > > the thread that does the drawing is also the thread that does the > > logic. I took this statement from the dev guide to mean that you have > > a separate thread for each. I suppose the best thing I can do is code > > and experiment and see if I get any improvements... > > > On Nov 12, 2:58 pm, RichardC <richard.crit...@googlemail.com> wrote: > > > > There is a nice simple game example (with multiple threads) in the SDK > > > samples called LunarLander -- 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
