Here's how it works: Renderer.onDrawFrame() is called when GL is ready to draw another frame. After that method finishes (and you called gl.glFlush()), the GPU is busy drawing and another call to onDrawFrame() won't be made until it's ready for business again.
While the GPU is working, your logic thread can be processing things. Therefor, it makes sense to try to move as much CPU-intensive stuff as possible out of that drawing loop and into your logic thread. The shorter you can make the call to onDrawFrame, the less you'll be holding up the precious drawing portion of code and the more time you'll be giving to the GPU to work. There's no point in ticking more than once per draw, btw. If the current world hasn't been drawn, don't both updating again until it is. That includes collision checks, sounds, etc. If you can't see it, it may as well not have happened, right? If you have some really sensitive sound thing or some reason to tick more, then sure, but that's a rare case. Also, assume variable framerate. All physicse should be time- interpolated in the standard way if you want them to work consistently across devices. One last thing - put really CPU intense stuff into native code. I have a great environment set up for doing native development and I use C for complex 3D stuff like vertex processing, sphere->mesh collision checks and response and spatial partitioning. If you install the NDK (and Cygwin if you're in win) and then CDT for Eclipse and create a builder that calls the NDK app build script from eclipse, it's really easy to add in C where you need it. For many 2D games it's not a huge deal but I'd recommend it for pathfinding or any of the core 3D world and animation code. On Dec 15, 9:16 am, Jeremiah Sellars <[email protected]> wrote: > First, thanks Robert... that's going to help a lot. I've not had to > use threading before and it looks to be a must on Android for games so > I'm making sure I understand the concepts as clearly as possible. I'm > quite thankful that Java's tutorials are as good as they are. I was > almost thinking of trying to make the game logic wait and just trigger > it when the renderer fires. My thought being... things like collision > only need to be checked (I'd be checking one frame ahead of course) on > a new render. Would that be a terrible idea? > > Secondly... hooray that posts (not sure if it's per individual or not) > aren't having to wait days to appear... > > On Dec 14, 10:35 pm, Robert Green <[email protected]> wrote: > > > If you're using the render-continuously mode, she'll go as fast as she > > can go. 60FPS if you're doing easy HW-accel 2D or very basic 3D. > > I've never seen over 60FPS. It's probably vsynced to that. > > > I like to use a shared object called the World to pass between my > > logic thread and renderer thread. Logic updates world, renderers > > draws it. Simple! > > > I keep a simple boolean isLocked on the World and synchronize the > > calls to getLock() and release(). You will want to set a max rate for > > your logic thread to run and have it figure out how many MS to sleep > > for. I didn't do that the first time and mine would run at 200-300fps > > while rendering at 30-60. That was a big waste of CPU cycles :) None > > of my code does that anymore. > > > On Dec 14, 9:58 pm, Jeremiah Sellars <[email protected]> wrote: > > > > I suppose I should add... that my background is homebrew for Nintendo > > > DS and coding in C. The game loop would generally just include a call > > > to wait for the screen's vertical blank and that was ~1/60th of a > > > second. It couldn't be relied upon totally for timing, but as long as > > > you weren't running really intense operations it was fine. DS Homebrew > > > is substantially closer to the hardware and the combination of > > > learning Java, OOP concepts, working with a very large API and > > > applying everything to a new platform is causing me to ask some likely > > > stupid questions. > > > > Anyway, I hope someone can find a moment to help. > > > > Thanks again, > > > Jeremiah > > > > On Dec 14, 3:51 pm, Jeremiah Sellars <[email protected]> wrote: > > > > > Hello everyone, > > > > > Continuing to tackle a game project, I've learned tons and have tons > > > > more to learn. > > > > > From what I've picked up, a "proper" game would have at least 3 > > > > threads. The main activity thread which would likely double as the UI > > > > thread, the GL Renderer thread which is setup automatically with the > > > > GLSurfaceView.Renderer and then a Game Logic thread. As I understand > > > > it, I'll need to make sure to setup a sleep timing in the game logic > > > > thread to have it behave correctly, but what I'm not sure on is at > > > > what timing is the Renderer thread working at? Exactly how often is > > > > onDrawFrame() being called? > > > > > Thanks everyone! > > > > Jeremiah -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
