Results 1 to 4 of 4
  1. krische's Avatar
    Posts
    421 Posts
    Global Posts
    442 Global Posts
       #1  
    Has anyone here tried using the Mojo.Animation API yet?

    I'm making an app that will have an object move around based on the accelerometer. I have it moving around and all (the 4Hz doesn't seem to be much of an issue, it also wasn't too hard to account for the accelerometer "noise).

    Anyway, everything still seems to be a littler jerkier then I would like. Has anyone used the animation api to sort of smooth the motion, or would I have to maybe get a physics environment going with a level of friction or something.

    Discuss.
  2. s219's Avatar
    Posts
    498 Posts
    Global Posts
    1,008 Global Posts
    #2  
    For small changes in acceleration, it should work fine. However, for rapid changes in acceleration, you may still get jerky animation because of the 4Hz accelerometer sampling rate. It doesn't matter if you update the graphics at a much higher rate, animation smoothness still is going to be limited by the accelerometer if its acceleration data drives motion of the object you're animating (regardless of your physics model).

    What happens if the acceleration is constant? Say tilt to a fixed angle and hold it there? How smooth is the motion then?

    If you really want to study this in detail, dump the raw data versus time and look at it. I would dump the accelerations, and any rendering primitives that depend on it (such as x,y position of your object). If this really is an accelerometer issue, what you'll likely see is that the graphics get jerky when the step to step change in acceleration is large.

    BTW, when do you update the object's screen coordinates? With the accelerometer event or during rendering? There are improvements to be had based on your strategy.

    Now, on a separate note, are you smoothing the accelerometer data? For instance, this would smooth X acceleration:

    myAccelX = 0.85*myAccelX + 0.15*event.accelX;

    Then base motion of your object on myAccelX instead of the raw event.accelX. You can play around with the weighting coefficients to balance smoothness and responsiveness. Efficiency of smoothing will also be limited by the low 4Hz sampling rate, bear in mind.

    I am focusing on this as an accelerometer problem because it's the obvious low hanging fruit and has been the main problem I have encountered. But it might indeed be a different issue in your case.
  3. #3  
    I was trying to use the Animation API to drive an event loop rather than setTimeout/setInterval, hoping that the 'special' API would be more reliable, but it still seems to bog down when there are UI events. While just letting my tests run with no input from me, it would hover around 36fps. Tapping the screen a lot would cause it to fall a few fps. And flicking would cause disastrous drops to like 7fps every so often. Note that these frame rate drops occurred even when no event handlers were wired up.

    It seems like the code that Palm uses to fire their events might be triggering a GC periodically? Particularly in how they generate flick events. I can deal with losing a frame or 2 from tapping, but the way everything grinds to a halt with flicking is a big issue. And this is never a problem in the simulator, just on the actual device.
  4. #4  
    I tried to use Mojo.Animation in Blocked, when you flick a block, it would animate to where it was going. But I tore it out because of its choppy movement. It was even choppy in the emulator.

    And there was no physics or anything like that going on, I just wanted it to animate between here and there.

Posting Permissions