I believe there's no common approach to games development. Every game
is unique and requires its own design. Therefore, it's really depends
on the game whether you should span 2 or more threads for your logic
and how excactly are you going to handle UI updates.
On Nov 12, 12:17 am, Neilz
Anyone? This is a common consideration, I would have thought?
On Nov 11, 10:17 pm, Neilz neilhorn...@googlemail.com wrote:
Hi all. I've been reading the developer guide, the sections on
designing for performance and responsiveness. It's great stuff, and
I'm going to go through all my code and
To my understanding the point of threading is, mostly, to avoid
blocking the UI. The UI should never be unresponsive because an app
has the UI thread tied up doing something other than responding to
user's actions. (And if the OS detects an app not responding it will
pop up a message saying the
Oh, and yes you could use Thread with a run() method. Its easy to set
up. AsyncTask is sort of a specialization of Thread tat helps with
some of the communication between parent and child thread. But they
can be run only once. So a new one needs to be instantiated each time.
On Nov 12, 8:13 am,
There is a nice simple game example (with multiple threads) in the SDK
samples called LunarLander
--
RichardC
On Nov 12, 2:03 pm, WoodManEXP woodman...@gmail.com wrote:
Oh, and yes you could use Thread with a run() method. Its easy to set
up. AsyncTask is sort of a specialization of Thread tat
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
There's a good blog post on this issue re games here:
http://replicaisland.blogspot.com/2009/10/rendering-with-two-threads.html
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
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
8 matches
Mail list logo