Ah, I see, it might have been due to my misuse of wait() and notify().
In any case, I remember that even sleeping the thread caused
decreased fps rate, (which I took as increased cpu usage.)
I mentioned the pool thread, not because I implemented one, but
because I avoided implementing one and
No, we're not arguing semantics, we're agreeing. We were both
responding to Miguel. (You did leave out being blocked in an IO call,
but that's a minor detail).
On Apr 10, 6:56 pm, Robert Green rbgrn@gmail.com wrote:
Bob,
Perhaps we're just arguing semantics. I was simply saying that you
You say: So, say I have the game loop logic in a thread like that,
using the
render fps average as a counter, I've noticed that the fps drops when
using more than one thread, even if it's just running in an empty
loop.
Um, ESPECIALLY if it's running in an empty loop. The point is, you
don't want
I understand that this is pseudo-code, so it probably does not reflect
your actual implementation, but I have two comments on this code:
* Depending on how the scheduler works, the GameLogicThread or the
Renderer thread may receive the lock two or more times in succession.
* The renderer and the
If a thread is hogging the CPU, it is *BY DEFINITION* not idle. And
vice versa.
An idle thread will be waiting on something. Either a synchronization
lock, or an object using wait(), or some blocking IO call. This may be
buried inside some other code, of course.
I would suggest wondering why you
Ok, like I said I may have missed something, but say I have something like this:
class MyThread extends Thread
{
run()
{
while (something)
{
if (something_else) //perhaps input has changed, or we have
data in a socket
{
//do some work,
Viktor, specifically in an Android 3D game using GLSurfaceView, the
are you want to parallelize on is what happens after the lock is
released by the renderer because significant time will be spent during
the buffer swapping as the gl command list is flushed there and it is
at that time that the
Hi,
I had a lot of difficulties getting the threading and app lifecycle
issues done, too. For my part, this was much more confusing than
getting the actual game done. ;)
The good thing is: you do not have to do too much for the render- and
logic-thread separation because most of the rendering
I'm a bit confused. What exactly is Game.sInstance? And can you
explain what the update() and render() methods do? (Well, I know what
they _do_, but I do not know how they are doing it (pseudocode would
work here).)
My gameplay is probably going to be a bit bigger than what you have,
so I don't
Another thought occurred to me. I'm more comfortable with the old-
fashioned game loop, and I noticed I can turn off auto-rendering. I'll
see if this works out instead.
On Apr 9, 8:55 am, Eddie Ringle ed...@eringle.net wrote:
I'm a bit confused. What exactly is Game.sInstance? And can you
I suggest you take a look at the open source Android game Replica
Island. Chris Pruett (a Google employee and Android advocate)
programmed it and I understand he uses a Thread for rendering, a
Thread for game logic and a Thread for the Activity (life cycle, input
etc...). He has a
It's pretty easy to do this:
I use a World to write to and read from for the two sides. Makes
networking nice too. My World has a simple lock. Only one thing can
write to it or read from it at a time.
in GameLogicThread:
run() {
while (!done) {
// wait for renderer
world.getLock(); //
Where do you store all your attributes, like player position?
Currently I just have a GLQuad class that I use to create new quads,
texture them, and manage position and velocity. Do you store them in
World, and then each side can access them from the world object?
Also, threading is new to me, so
Yeah, you're going to want to model your game like you would model the
real world:
class World {
public Player player;
public Enemy[] enemies;
public int timeLeft;
public int level;
//etc..
}
Then you update the world (usually by calls to player.update,
enemy.update, etc) from your
I wonder how much true parallelism is happening when the game logic
runs on a separate thread than the rendering (in addition to the
Activity thread for a total of 3). I do not claim to be an expert in
this arena, but what follows is what I think about the subject of
threads in Android games.
One more thing question and I think I will be set. Coming from a C/C++
background, I enjoyed the use of references. I know that there is a
way to pass the reference by value in Java, but am not quite clear on
how. Could I, for example, create my World object, then pass that
object to the renderer
This topic is pretty interesting. I also am off the school of one
thread is enough. I have to admit that I don't fully understand the
benefits of a seperate logic thread. Am I right in thinking that the
only reason to have a seperate logic thread is being able to use the
cpu while it blocks on the
Is it as simple as:
In GameView.java (my custom GLSurfaceView class):
World _world = new World();
GameRenderer _renderer = new GameRenderer(_world);
In GameRenderer.java:
public World _world;
public GameRenderer(World world)
{
_world = world;
}
In GameRenderer.java, _world would now have
Here is some more talk about threading (on Replica Island's Dev Diary/
Blog): http://replicaisland.blogspot.com/2009/10/rendering-with-two-threads.html
On Apr 9, 2:58 pm, Eddie Ringle ed...@eringle.net wrote:
Is it as simple as:
In GameView.java (my custom GLSurfaceView class):
World _world
Eddie,
Yes, that'll do the trick.
As far as the multiple threads goes, sure you can drive your logic off
of the call to onDrawFrame but there is a situation in which having a
separate thread makes sense:
After onDrawFrame, the rendering thread is finishing/swapping. That
can actually take a
Robert,
Silly question, but how do you get input to the logic thread? I have
to get sensor and touch data from the main Activity class and somehow
get it to the logic thread.
Current program flow is as follows:
onCreate() - GameView() - World() Renderer() GameLogic()
On Apr 9, 3:24 pm, Robert
That's what i was wondering. It makes of course a lot of sense to use
the CPU idle time while the GPU is doing the heavy lifting. However,
but having to put a synch around the access to the logic data in the
rendering thread and the logic thread you explicitely starve one of
the threads, depending
That depends on what kind of input you need. If your game is happy
with just checking the current state of the accelerometer/touch screen/
keyboard/trackball simply polling will do the trick. This means that
in the UI thread, where you have your event listeners installed, you
simply save the last
Then I think this simplifies the advice we should give you.
If you don't know enough about threading to know what a lock is, you
should avoid threading for now. It'll be too much to learn at once,
and you won't be able to do a good job of either learning about
threading, or applying it.
I think
Think of it this way -- there is no such thing as pass-by-value in
Java, and no such thing as references, either. Everything is
equivalent to a pointer, except there is NO pointer arithmetic, and no
- operator, that role being handled by '.', so it LOOKS like a
reference with C++ eyes.
To add to
Okay, I figured I could just pass the Activity through parameters, but
wanted to know if a better way was possible.
Thanks for all the help everyone.
On Apr 9, 5:56 pm, Mario Zechner badlogicga...@gmail.com wrote:
That depends on what kind of input you need. If your game is happy
with just
There are a lot of built in classes in Android and Java that you can
use to avoid having to write any synchronization or lock code
yourself. In my case GLSurfaceView sets up my render thread. I use
HandlerThread for my game thread. The game thread sends an update
object detailing all the draw
I may be completely wrong on this, but I've found that threads hog the
CPU even when idle.
The way that has worked well for me is to have the render thread, and
the logic timer.
(using a looper and communicating via a handler can be slow, from my
experience locks are faster)
To keep things
Miguel,
Threads hog CPU only when _not_ idle. A thread constantly looping
with no sleep is _not_ idle and is what people tend to do before they
know better. This is what .wait() and .notify() were added for and
using them means negligible CPU usage while waiting.
The article you posted on
29 matches
Mail list logo
