Actually the correct way is not to lock in the number of updates to physics at a constant rate but instead to have the physics themselves be defined as a rate. For example, if you want to have a player moving at a rate of 1 virtual foot per second (let's say that's 5 pixels on screen for a 2d game), you would have the physics update take into account the last position at the last update time and then figure out where they should be given the current update time. That way if there are more or less calls to updatePhysics, the player will continue moving at a predictable, constant rate based on time, not tics. More tics at this point will only smooth out the movement and this is the preferred way to handle different processor speeds.
I used tic-rate on my game which tries to lock the game in at 20 tics per second but if for my next one I will be using time-based movement rates like I discussed. Also - Action games are going to suck 100% of the CPU. There really isn't enough CPU to do simple physics and redraws and cap out at the refresh rate. Unless you want a choppy game, you're going to want to get as many updates in as possible. On Oct 29, 4:28 am, "Stoyan Damov" <[EMAIL PROTECTED]> wrote: > Thanks again, yes, something like that - I realize the question was > more for a game development forum, not here, sorry. > Basically I'd like the game loop to call updatePhysics, say, exactly > 30 times/sec but render only when there's anything to render, sleep to > preserve battery otherwise. > > Cheers > > On Wed, Oct 29, 2008 at 4:10 AM, hackbod <[EMAIL PROTECTED]> wrote: > > > 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 -~----------~----~----~----~------~----~------~--~---
