Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (576)
games submitted by our members
Games in WIP (497)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Best Game Loop for Android?  (Read 8755 times)
0 Members and 1 Guest are viewing this topic.
Offline Ranger
« Posted 2009-08-05 13:00:20 »

At the Google I/O Android Game presentation, they suggested using 3 threads for a game:
1. EDT (basically leave it alone to do user input).
2. Draw loop, let it run flat out.
3. Game logic loop.

I did that, and I got terrible performance.  So I tried a wait/notify pattern where there draw loop would wait if there was no update from the game loop.  Brilliant performance!

Well, it was brilliant on Android 1.1.  My phone just updated to Android 1.5, and the performance is not so good any more (not terrible, but noticeably worse).

I tried upgrading my draw loop to use the new GLSurfaceView class, and that didn't make any difference.

My question is, what do you guys do?  Do you use 3 threads?  Do you let the draw loop run flat out, or use a wait/notify pattern (GLSurfaceView.RENDERMODE_WHEN_DIRTY)?  Any other advice?

Thanks!
Offline Markus_Persson

JGO Wizard


Medals: 12
Projects: 19


Mojang Specifications


« Reply #1 - Posted 2009-08-05 13:46:41 »

2. Draw loop, let it run flat out.
3. Game logic loop.

This is a bad idea. You have to keep a lot of things synchronized to avoid weird bugs that are impossible to reproduce.

Play Minecraft!
Offline kevglass

JGO Kernel


Medals: 85
Projects: 25


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #2 - Posted 2009-08-05 14:14:50 »

I currently use 2 threads. The EDT (which I sleep when recieving touch events thanks to Ranger) and the rendering thread provided by the GLSurfaceView. As part of the render cycle before I render anything I call logic().

Seems to work pretty well.

Kev

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Ranger
« Reply #3 - Posted 2009-08-05 14:29:28 »

I initially only had 2 threads, but Google said that because the calls to the GPU take so long (which they do), you are better off having a separate game thread and making use of the idle CPU time (when the draw thread is doing I/O to the GPU).

However, when I did this, I found it was a real pain, as Markus pointed out, keeping things synchronized (ended up making a SceneData class to group the information the draw thread needed together).  And my performance testing showed that the game loop would execute in about 5% of the time that the draw loop took to execute.  So I'm thinking having separate draw and game threads just isn't worth it.
Offline Markus_Persson

JGO Wizard


Medals: 12
Projects: 19


Mojang Specifications


« Reply #4 - Posted 2009-08-05 15:54:16 »

Oh, well, if the gpu really is that slow, I guess separating the threads could be worth it as long as you manage to pull the synchronization off.

I'm getting my HTC Hero later this week, I'm really looking forward to playing around with android. Cheesy

Play Minecraft!
Offline Ranger
« Reply #5 - Posted 2009-08-05 16:03:49 »

I forgot, there was another reason for having separate threads.  If the phone decides it has to do something else, the game loop will generally continue to run at the desired FPS, while the draw loop will start skipping frames.  That way, the game won't slow down, it will just start jumping.
Offline Nate

JGO Kernel


Medals: 128
Projects: 3
Exp: 14 years


Esoteric Software


« Reply #6 - Posted 2009-08-06 10:22:45 »

If your game time is based on time since the last frame, I don't think separating the game logic and drawing in different threads gains anything. Definitely relying on a constant framerate is a bad idea as I see framerates vary pretty wildly.

I use 3 threads: EDT, GL, and a thread for reading from the mic. Some native code somewhere has to be running a 4th thread to play music, since it continues to play even with all my threads paused. There is no way around so many threads, and it is brutal on my framerate. I am only getting 30 FPS drawing some pretty damned simple 2D stuff. Commenting my rendering hardly affects the framerate, the CPU is just busy playing music, reading from the mic, and processing the mic data. This worked a lot better on the iPhone, and I don't think it can be blamed entirely on Dalvik (my mic processing uses native code). My theory is the Androids mic stuff is especially crappy.

Offline Ranger
« Reply #7 - Posted 2009-08-06 10:39:27 »

I noticed on the G1, playing MP3 files takes a lot of CPU, while playing OGG files takes much less.

As my game is a multiplayer game, I decided to make the game loop run at a constant frame rate (just because I thought it would make coding easier).  The draw loop is free to skip frames whenever it needs to.

I have this problem now where sometimes when I run my game, the OpenGL calls will all execute quite well, and my game will run smoothly, and other times they take forever and the game is really choppy.  If anyone has any ideas as to what might be the problem, please let me know.

EDIT: I found the problem:  If the window that launches my game is in landscape mode, I get about 18fps.  If it is in portrait mode, I get 30fps.  It's weird because I actually force my game to run in landscape mode.  I thought the launcher window may have some soft of problem with landscape mode, so I cut it right back to just 1 button, but that didn't fix the problem.  Then I thought the game might be starting multiple game loops...nope.  Now to try to reproduce it in a test case.
Offline kevglass

JGO Kernel


Medals: 85
Projects: 25


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #8 - Posted 2009-08-07 20:12:05 »

I've just tried the 2 threads (logic vs GL) approach and it's slightly better responsive wise and smoothness. Though there isn't a great deal of difference that I can see.

Kev

Offline Ranger
« Reply #9 - Posted 2009-08-07 23:38:44 »

I've just tried the 2 threads (logic vs GL) approach and it's slightly better responsive wise and smoothness. Though there isn't a great deal of difference that I can see.

Kev

Did you use GLSurfaceView.RENDERMODE_WHEN_DIRTY, or run the GL loop flat out?
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline kevglass

JGO Kernel


Medals: 85
Projects: 25


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #10 - Posted 2009-08-07 23:47:12 »

Run the GL loop flat out, is it better on dirty?

Kev

Offline Ranger
« Reply #11 - Posted 2009-08-07 23:55:09 »

Run the GL loop flat out, is it better on dirty?

Kev

OK.  I don't have a direct answer, but this is what I have done.

Android 1.1 -> GL loop flat out with my own loop, terrible performance.
Android 1.1 -> GL loop doing a wait() and game loop doing notify(), excellent performance.
Android 1.5 -> GL loop doing RENDERMODE_WHEN_DIRTY and game loop requesting repaints, I think the performance was slightly slower then wait/notify, but hard to tell.
Android 1.5 -> GL loop flat out, never tried.
Offline lordx

Junior Newbie





« Reply #12 - Posted 2009-08-25 04:34:55 »

hi
I use three threads in my game,
1. UI
2. GL (only drawTextOES)
3. game logic

and framerate is nearly 60.
at first I use logic thread  to notify the Gl thread and I got very slow performance, then I changed them 2,and it seems works fine.
Offline Ranger
« Reply #13 - Posted 2009-08-25 05:12:54 »

I shied away from using glDrawTexiOES because in that Google I/O talk, they said that GL11Ext might not be supported by all phones.  Anyone know if this likely to be true?
Offline Nate

JGO Kernel


Medals: 128
Projects: 3
Exp: 14 years


Esoteric Software


« Reply #14 - Posted 2009-08-25 08:10:06 »

It is possible, so if you are going to use it, you might want a fallback. It isn't hard to do it both ways. Or you could always wait for your game to break, then fix it. I tried it out and didn't find it to be much better, if even better at all.

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

xsi3rr4x (15 views)
2014-04-15 18:08:23

BurntPizza (12 views)
2014-04-15 03:46:01

UprightPath (25 views)
2014-04-14 17:39:50

UprightPath (11 views)
2014-04-14 17:35:47

Porlus (28 views)
2014-04-14 15:48:38

tom_mai78101 (50 views)
2014-04-10 04:04:31

BurntPizza (109 views)
2014-04-08 23:06:04

tom_mai78101 (209 views)
2014-04-05 13:34:39

trollwarrior1 (177 views)
2014-04-04 12:06:45

CJLetsGame (184 views)
2014-04-01 02:16:10
List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:05:20
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!