Why redraw if nothing has changed? Also - how do you know if nothing
has changed if you don't check for it? :)
These are the reasons the main loop is the way it is.
My main loop currently looks like this:
private void update() {
if (!isPaused) {
long now = System.currentTimeMillis();
if (now - lastTick > tickDelay) {
lastTick = now;
if (gameState == STATE_RUNNING) {
// key input was captured
already
updateAI();
updatePhysics();
}
updatePaths();
updateAnimation();
updateState();
updateSound();
}
}
}
On Oct 29, 9:43 am, "Stoyan Damov" <[EMAIL PROTECTED]> wrote:
> 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 [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
-~----------~----~----~----~------~----~------~--~---
