Is AnimationExample a smooth animation?

[philip]

Hi there,

Running:

object AnimationExample extends UI {

The animation doesn't look smooth to my eyes, it looks like it jumps (slow down and go faster) just slightly as it moves across the screen.

What do you think?

Phil

[Hicks, Matt]

Yeah, I've seen the same problem. This is one of the reasons the
animation example hasn't been finished is because I ran into that and
got sidetracked to other things. I need to do some performance tuning
so that animations are perfectly smooth. If you have the time and
ability to do some profiling to find the cause that would absolutely
invaluable to me.

As a side note, what do you think about the DSL for creating
animations that I'm building there?

[Hicks, Matt]

After quite a bit of digging on this it would appear this is not a
problem with Sgine after all. With libgdx using the LWJGL
implementation turning on vsync seems to cause choppy performance.
For now I've resolved it by defaulting vsync to false and will
follow-up with libgdx team about resolving the underlying issue.

[philip]

That's good to know. I am reading/learning your code base at the moment.

[Hicks, Matt]

That's great. Feel free to ask any questions or make suggestions. I
always appreciate more eyes on my code. :)

[philip]

Hi Matt,

The code is looking good now and the examples are good too, I can get my head around most things.

The workflow is mutable right, so if I want a characters such as a pacman ghost to follow a particular path, I can set a workflow. If the path changes I can change the workflow. Is that a reasonable usage?

Can you explain the vertical sync problem?

At the moment, it flickers "slightly" with vertical sync off, but moves reasonably smoothly.

WIth vertical sync on it has a noticeable slow down for very short periods and speed up to normal speed. What if I fixed the frame rate to a lower frame rate?

In either case, its not good for a game to have either one of these cases, but I can develop with it.

Thanks! Phil

[Hicks, Matt]

I've been thinking about making the workflow immutable as I don't really think that's a good usage.  In a pacman kind of game I would setting a direction and animate moving from one square to another. I started writing a Snake clone in the examples that made me realize I need a Grid container that helps accomplish this kind of functionality easier.  In a game I wrote a while back I have each enemy along with the user's character evaluate at each update.  If it is already going in a direction it will keep on until it runs into an obstacle and then it will deal with each situation as they occur.

As for the choppiness I need to spend some more time looking into this as something strange seems to be going on and I haven't been able to really track it down yet.  If you're interested in digging into it yourself additional eyes are always appreciated.

Thanks,

Matt

[Hicks, Matt]

Philip,

I just checked in support for fixed timestep (see AnimationExample for usage) and that seems to make a big difference.  It would appear that at lower update frequencies slight timing differences between renders create the effect we're seeing.  Using fixed timestep seems to make a big difference for me.  Please take a look and see if it helps you as well.

Let me know,

Matt

[philip]

Hi Matt,

It looks much better.

I read from here: http://lwjgl.org/forum/index.php?topic=3177.0

The problem with nanotime is that it uses the HPC, which are affected by the clock frequency of the cpu. So for any system that uses scaling frequency the time will jutter.

The LWJGL timer is not affected by this. The price for this is 1ms granularity, instead of 1ns.

The LWJGL timer used to be based on HPC (QPC) , but we switched to the multimedia timer since its stable.

In your render in the default case of 0.0 for fixedTimeStep (which means not a fixed time step) you are using System.nanoTime.

    def render() = {

      Gdx.gl.glClear(GL10.GL_COLOR_BUFFER_BIT | GL10.GL_DEPTH_BUFFER_BIT) // TODO: optional?

      delta = fixedTimestep() match {

        case 0.0 => {

          val currentTime = System.nanoTime()

Consider to use Gdx.graphics.getDeltaTime(); ? http://code.google.com/p/libgdx-users/wiki/limitFps

Maybe this would work, but I have not tested as I have to start work now (9am)

         val currentTime:Long = (Gdx.graphics.getDeltaTime() * 1000000000.0f).toLong  

Phil

[philip]

This space invaders uses Gdx.graphics.getDeltaTime()

http://code.google.com/p/libgdx/source/browse/trunk/demos/invaders/gdx-invaders/src/com/badlogic/gdxinvaders/GdxInvaders.java

[Hicks, Matt]

Previous to today I was using getDeltaTime() from libgdx.  Because it internally does the same thing (System.nanoTime) I switched to doing it myself since I use Double and they use Float.

I might have to look into the LWJGL timer when available, but that will increase the complexity a bit.  Although, I don't think it will help because libgdx does Display.sync(60) when useCPUSync is enabled and I would bet that it uses LWJGL's timer but it's still really choppy.