Let me try to explain again - I don't want the # of updates to be == the # of redraws, and I'm fine with a variable # of game updates/sec, provided that this number is greater than the fastest movement of a sprite (e.g. 100 updates/sec for a sprite which moves at 100 px/sec). updatePhysics will surely take the elapsed time between the last game tick and this one, *but* then, after updatePhysics exits, if there's no object to be redrawn (e.g. no sprite moved), I don't want to draw, and then again I don't want to enter the next game loop either because I don't need more than N game updates/sec. It's OK though, I have an idea of the game loop.
Thanks to everyone who replied this thread. Cheers On Wed, Oct 29, 2008 at 3:25 PM, Robert Green <[EMAIL PROTECTED]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
