Sprite.position - Tweening and/or Interpolation

[mrBRC]

(This following might be more or less a colleage of related, yet independent thoughts)

 

I suppose I just want smoother transitions in my sprite movement. I'm trying to address the issue with my sprite.position changes.. which are currently just incremental.

 

http://www.iakarra.net/demo/polymer/WiAClient/index.html

 

where as, http://www.iakarra.net/demo/polymer/WiAClient/wiia.account.js actually contains the update function/method (and in turn calls on the 'character.step' function) that is executing on every animate call/tick on the main page. So this is really the scope I'm concentrating on.

 

Alright, so I'm familiar with the concept of css transitions being smoother than javascript animations because they are 'hardware accelerated'.

 

but from this article:

http://css-tricks.com/myth-busting-css-animations-vs-javascript/

 

it becomes apparent that javascript can be hardware accelerated as well. And the speed/execution myth was really invalid and perpetuated because people were basing their comparison on jquery animations.

 

 

 

Referencing the following: http://chimera.labs.oreilly.com/books/1234000000802/ch05.html#animating_by_programmatically_updating_p

 

as well as the following sections in/to that reference 'tweening' and 'interpolation' I hope to add a time-based animation (movement) using this javascript hardware accelerated concept.. 

Is there anything within the PIXI framework that I should account for when I do this? Or has someone implemented something similar to what I'm trying to accomplish?

With my mild experience with the XNA framework, I noted that it passed around a gametime tick/timer.. In another post on here, I made reference to the requestAnimation method using the window.renderAnimationFrame .. based on date.now()... though that time did not seem to be global.. 

Edited July 3, 2014 by mrBRC

[d13]

> it becomes apparent that javascript can be hardware accelerated as well.

 

Pixi's WebGLRenderer is hardware accelerated by the GPU and modern JavaScript engines like V8 in Chrome compiles JavaScript down to machine code and runs it on the CPU (http://en.wikipedia.org/wiki/V8_(JavaScript_engine)).

 

For a game loop, you definitely want to use `requestAnimationFrame` instead of timer based systems.

That's because browsers synchronize `requestAnimationFrame` with screen refresh rates and optimize when it's called.

​If you use a timer based system, the timer might call a render at a busy time for the browser and that could cause some jankiness.

 

But there's whole science behind what happens within that loop.

You should definitely read this:

 

http://gameprogrammingpatterns.com/game-loop.html

 

And geoffb's comments in this thread:

 

http://forum.lostdecadegames.com/topic/196/what-is-the-best-practice-for-javascript-game-loop

 

However, I'm still styling looking for hard evidence that there is any advantage to variable time step and/or variable rendering within the context of a `requestAnimationFrame` loop in HTML5 games.

I haven't found any yet.

If anyone out there reading this has any working examples or comparison's, please let us know

 

I stand corrected: 

 

http://www.html5gamedevs.com/topic/8716-game-loop-fixed-timestep-variable-rendering/

 

But there's definitely a lot to be said to clamping the frame rate at specific fps, because that gives you a bit of overhead for garbage collection spikes and means your game will run at the same speed on a 120Hz monitor.