kefniark / fatina Goto Github PK

Description

Currently the definition file fatina.d.ts generated is broken (thanks dts-bundle).

Need to investigate if it's possible to get rid of it and just use tsc directly like I did on https://github.com/kefniark/jil

Hey!

I can't figure out how to manually tick Fatina from my own update loop. I can see in the docs that it is meant to work "If you already have an update loop, try to tick manually Fatina to keep animation and rendering in sync", but can't get it to work.

I thought Fatina.pause() and then Fatina.update(timestamp) in the loop should do it, but the test tween will not tick (works fine if I let Fatina do it on its own).

Thank you!

when trying to uglify the .js file it throws an error in Fatina code.

ct";Object.defineProperty(e,"__esModule",{value:!0});e.BaseTween=class{construct

ERROR: Unexpected token: punc «{», expected: punc «;»

Minify works but thought you might be able to help out here.

Description

With the new version of Fatina v3.0, the syntax of import slightly changed:

Typescript / ESM modules

import * as Fatina from 'fatina';
// become
import Fatina from 'fatina';

CommonJS (Node)

var Fatina = require('fatina');
// become
var Fatina = require('fatina').default;

Web / CDN
Nothing change, still use global variable Fatina

Why ?

Sorry for the modification, this default export really makes auto-completion and declaration support easier to manage.

Description

• With tweens, we have linear movement
• With sequence, we have serial or parallel linear movements

It's fine but for some type of motion it can still look quite unnatural.
The idea would be to provide so specific tween (only with position: Vector2(x, y) or Vector3(x,y,z)):

• Curve (simple bezier curve with 2 control point)

Fatina.bezier(
  {x:0, y:0}, // start
  {x:108, y:32}, // control point 1
  {x:176, y:32}, // control point 2
  {x:196, y:160}, // end position
  250 // duration
)
// any usual method (.setTimescale(), .yoyo(), onComplete(), .setEasing(), ...)
.start()

• Path: go through a list of 2D point in a certain duration (unlike sequence where each tween has his duration)

Fatina.path(
  [{x:0, y:0}, {x:108, y:32}, {x:176, y:32}, {x:196, y:160}], // n point to go through
  250 // duration
)
// any usual method (.setTimescale(), .yoyo(), onComplete(), .setEasing(), ...)
.start()

• Curve Path: A mix of both previous one, the equivalent of sequence for curves.

Concern

• For bezier, yes there is a real need
• For Path and Curve path, I still wonder if it's not possible to just use Sequence and provide a way to compute duration based on global speed and distance of each tween on the fly.

Screenshot

Bezier curve

Curve Path

Description

Provide few preset of complex but common tweens.

Things like:

• Pulse
• Breath
• Strobe
• Wobble

Is there a delay option available with the tween so that the tween can start after a certain delay like most tween libraries?
If it's not available can you please provide an update with the 'delay( )'?

Add Fatina.version to make library versioning easier between projects

Description

Investigate if using web worker could be a viable solution to boost perf even more.
Batching tweens and updating them in parallel in different workers.

The main problem would be to make it work cross platform browser, node and deno

Description

Working with callback can quickly be verbose and hard to read.
For simple usage, it would make more sense to have a way to rely on async/await syntax

const obj = { x: 0, y: 0 };
const tween = Fatina.tween(obj).to({ x: 500 }, 2500).start();
await tween.toPromise()

Description

The idea would be to provide an helper to easily add a delay to a tween (not a sequence, there is already appendInterval() for that).

It's already possible through:

Fatina.sequence().appendInterval(delay).append(tween);

or from a tween

tween.toSequence().prependInterval(delay);

Both are doing exactly the same thing:

• Create a Sequence
• Set a Fatina.Delay(delay) at the index 0
• Set the user tween after

But the syntax can be kinda annoying to remember.

Proposal 1

tween.delay(delay): ISequence

But I'm kinda worried by the fact it's the only API that doesn't return the tween but a sequence with the tween inside.
This can cause some side effect based on the parameter order. For example those two tweens should give the same result:

// here the 2nd timescale overwrite the first one, so the tween will run at x2
tween.setTimescale(0.5).setTimescale(2).start()

// here both are set on different object, so the tween will run at x1 (0.5 x 2)
tween.setTimescale(0.5).delay(0).setTimescale(2).start()

Proposal 2

Change the Tween to have 2 extra properties:

• delayBefore: delay after onStart and before the animation
• delayAfter: delay between end and onComplete
  The implementation would be native and everything remains contain inside a tween ... but now we have duplicated feature. And on top of that, the timing between onStart and onComplete wouldnt be equal to the duration expected.

duration = delayBefore + tweenDuration + delayAfter

Description

Add more preset

• bounce
• oscillate

As described in #36

Description

Tweens are powerful but still too low level for most cases, and doing lot of those small things can be time consuming any annoying

• need to keep reference of the object to animate
• start (autostart make more sense in more cases)
• remove duplicates if user spam buttons
• ...

An idea would be to use something closer to CSS Transition (just set end value)

// Your object
const obj = { name: 'sprite', x: 0, y: 0 }

// Create a reusable transition around this object, so you dont have to keep a reference to the object everywhere
const transition = Fatina.transition(obj)

// Creating a UI Animation/Transition becomes one-liners
transition.to({ x: 1 })
transition.to({ y: 1 }, 1000)

And mixed with #76, this can give more intuitive user interaction and partially replace sequences

transition.kill()
await transition.promiseTo({ x: 0 })
await transition.promiseDelay(100)
await transition.promiseTo({ x: 100 })

Description

The idea would be to support ESM:

• replace webpack by rollup
• make use of tree shaking

Hi,

I'm having trouble with the initial tweening operation. I am trying to smooth an SVG viewbox zoom animation that uses the mousewheel. The initial tweening fails with the above warning. The latter ones work as expected.

How can I fix this issue?

Thanks,
Richard

Description

Tweens take a second parameter of properties to update:

Fatina.tween(sprite, ['x', 'y'])
    .to({ x: 12, y:25 }, 0.5)
    .start();

This could automatically deduced from the .to() or .from() to make it less verbose

Fatina.tween(sprite)
    .to({ x: 12, y:25 }, 0.5)
    .start();

Description

Add the ability to .yoyo() to be use like setLoop(-1).
Sometime we want an infinite animation without having to use a giant stupid number

Description

For the moment, the library is based on the deltatime provided by requestAnimationFrame.

Some post seems to say that this dt could be slightly inaccurate and they recommend to use:

• Browser: performance.now()
• Node: process.hrtime()

https://www.stefanjudis.com/today-i-learned/measuring-execution-time-more-precisely-in-the-browser-and-node-js/

Need to test in different browser how big is the difference and if it's still relevant.