If you want to throttle your updates to something less than the screen refresh rate, you can just use SystemClock.uptimeMillis() to find the time between each draw and Object.sleep() or Object.wait() to suspend the thread until it is next time to draw. Is that what you are looking for?
On Oct 28, 6:01 pm, "Stoyan Damov" <[EMAIL PROTECTED]> wrote: > Thanks to you and Romain! > > So my follow up question is what is the maximum number of vertical > syncs per second of a G1 phone? > In other words, if the drawing code is really fast (e.g. if I don't > invalidate the entire screen but just a tiny rectangle), what am I > supposed to do in order to make an animation run at no more than N > frames per second? The reason behind this is this: I don't wanna draw > a frame that has already been drawn, so I'll keep a list of "active" > or "dirty" objects (dirtyness determined in updatePhysics or > whatever), but in this case, I'll just spin the CPU waiting for the > next game update which will invalidate some objects. Hence the initial > questioning of the game's loop - what if the game's scene has to be > drawn in less than the max FPS for the device? > > I hope you'll understand what I mean - it's 3am here and I'm not a > native speaker :) > > Cheers > > On Wed, Oct 29, 2008 at 2:46 AM, hackbod <[EMAIL PROTECTED]> wrote: > > > A little more info (I missed that the app has been changed to use a > > SurfaceView) -- the call to lock will block if you are running faster > > than the maximum frame rate. See here: > > >http://code.google.com/android/reference/android/view/SurfaceHolder.h...() > > > On Oct 28, 2:03 pm, "Stoyan Damov" <[EMAIL PROTECTED]> wrote: > >> On Tue, Oct 28, 2008 at 7:44 PM, PorkChop <[EMAIL PROTECTED]> wrote: > > >> > My emulator gives a result of 543.94 bogomips, better be careful > >> > coding games otherwise they are going to end up sucking on the actual > >> > device! > > >> > Speaking of which, has anyone noticed Lunar Lander's "game loop". It's a > > >> real WTF to me: > > >> while (running) > >> { > >> updatePhysics(); > >> draw(); > > >> } > > >> No shit batman? At what FPS? The max possible on the device? Redrawing a > >> frame possibly hundreds of times per second w/o the physics even being > >> updated at all? > >> I expected to see some sort of a game loop with constant game update rate > >> and some target FPS (not precise of course) and some sleeping eventually so > >> CPU's not utilized at 100% because this is a MOBILE DEVICE for crying out > >> loud, and this sucks battery, and the sample is supposed to be a > >> "reference" > >> implementation with best CODING practices, etc. (i.e. fuck graphics, > >> gameplay, etc.), *right*? > > >> Cheers --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
