Jump to content

Sprite.position - Tweening and/or Interpolation


Recommended Posts

(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.




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:



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.




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 by mrBRC
Link to comment
Share on other sites

> 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:




And geoffb's comments in this thread:




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: 




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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...