Thursday, February 24, 2011

[android-developers] Re: Smooth OpenGL movement and animation tips.

It's good of you put some suggestions out there to help others, and
I'm not trying to have a dig, but none of those tips have anything to
do with opengl(es) specifically. If you really want some indepth
opengles tips and insight you can't go far wrong with reading through
the posts on the badlogic blog:
http://www.badlogicgames.com/wordpress/

RE 1- this depends rather on what you are making, I'm currently
building a fast shooter and have specifically chosen not to do this,
if a frame takes longer to render I'd prefer the game to slow down and
still be playable than have the enemies suddenly 'jump' because the
time elapsed is greater than average, your point 5 may help this
though I guess.

2 & 3 - agreed, the GC is not your friend (although its a lot better
in gingerbread than previously), and surprisingly few people seem to
know about or use some of the cool tools hidden in the ddms view.

4's not really practical when testing real world situations, you can't
ask your users to switch to airplane mode to use your app.

sorry to be so pedantic :)

A

On Feb 24, 4:21 pm, Tom Cowan <tttco...@googlemail.com> wrote:
> I'm sure anybody who's used openGL will of come across a situation
> where the animation or movement isn't smooth so here are some tips in
> the hope of people posting some more.
>
> 1. Make sure you animate/move using a timer to maintain a constant
> rate of movement regardless of processing speed. So,
>
> x = now
> draw 1st frame
> y = now
> movementFactor = y - x;
> draw 2nd frame
> repeat
>
> That sorts some problems.
>
> 2. Stop the GC firing. If you're getting the gc firing message in the
> logcat whilst movement or animation is taking place your likely to be
> allocating ram. You can check this in ddms, goto the allocation
> tracker, hit start tracking then get allocation and you'll see what
> methods have been allocating ram.
>
> 3. Stop allocations even if the GC isn't firing! This helped me a
> bundle, I was allocating a lot of Strings and once I sorted this out I
> found the frame rate to fluctuate less.
> 4. Put the phone in airplane mode when doing performance testing and
> kill all tasks prior to running your app.
>
> 5. (Not tried this one yet) Apparently you're eye is very good at
> seeing jerks in animations.movement so it's actually better to reduce
> your frame rate artificially as explained by Mario Zechner below,
>
> "Average your delta times, it's the only way you can smooth
> things out. I use a window of 5 frames per second for which i sum up
> the delta times and divide by the number of frames.
>
> An example,
> 15ms, 15ms, 33ms, 15ms, 15ms will give you an average delta time of
> 18.6ms for frame 6. The 33ms will also influence the delta time of the
> next 4 frames after it. To avoid that effect you could use weighted
> averaging: frame delta times that are newer receive a higher weight
> (just an example, haven't boughtered using it)"
>
> Does anyone have any other ideas concerning this topic?

--
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
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

No comments:

Post a Comment