Animation of sprite movement

[Fovi]

Hi, i wondering how properly animate movement of sprite ?

In pixi example it is clearly shown that sprite could be animated by increasing x / y axis. But if i want to move something quickly then i need to increment it by a big number (like 10 or 20) that creates ugly "jumping" effect. Is that the best i can do with pixi ?

Also changing sprite texture to make walking animation (for example), can someone show me example of it

[ivan.popelyshev]

Those two questions are basic of any renderer. If you dont have an idea then you just have to read following things and then implement it yourself, otherwise you wont know important parts that are required when you work with ANY engine.

1.

Suppose sprite movement was started in time=t1, and ends when time = t1 + dt, then its coord X = X1 + dX * dT, same for Y. Its basic linear movement , but people are often use different formulas, like exponents or so (https://github.com/Nazariglez/pixi-tween/blob/master/src/Easing.js). You can add handler in "app.ticker" that will handle all moving sprites, and current time will be passed there.

Please look at tweens and their examples, https://github.com/Nazariglez/pixi-tween .

2.

Find AnimatedSprite (old name is MovieClip) examples, then you can write your own thing that changes sprite texture over time from pre-defined array.

Look at pixi implementation: https://github.com/pixijs/pixi.js/blob/dev/src/extras/AnimatedSprite.js

I advice you to make your own thing with textures array and different rules.

[Taz]

What I do, and it's a pretty standard approach I think, is to set a velocity and destination for the sprite. That way the speed and total distance can be set independently. There's external libraries to help with this, but it's worthwhile to get comfortable with custom animations I think.

 

[ivan.popelyshev]

Velocity and destination for a sprite is not a good idea, you need to remember source too!

Or use LERP: NEW_X = X + (DEST_X - X)*0.25

I always use my own custom animations. Just make sure you understand how those formulas work, its not a shame to copy them from https://github.com/Nazariglez/pixi-tween/blob/master/src/Easing.js

[Taz]

Source isn't strictly needed. Velocity tells us direction, which can be used to determine if the destination was overshot. That's how I usually do it anyway, but maybe it's not as common as I thought

[ivan.popelyshev]

>  Velocity tells us direction, which can be used to determine if the destination was overshot.

If you store X and Y velocity, then its ok, otherwise there would be problems with division by distance, which can be small. I recommend to store how much time left

[Taz]

>  I recommend to store how much time left

Hmm, I'll try that approach next time => I think it might make my animate function a little simpler/shorter (less checks and branches) now that you mention it

[Fovi]

1 hour ago, ivan.popelyshev said:

Suppose sprite movement was started in time=t1, and ends when time = t1 + dt, then its coord X = X1 + dX * dT, same for Y. Its basic linear movement , but people are often use different formulas, like exponents or so (https://github.com/Nazariglez/pixi-tween/blob/master/src/Easing.js). You can add handler in "app.ticker" that will handle all moving sprites, and current time will be passed there.

Please look at tweens and their examples, https://github.com/Nazariglez/pixi-tween .

I did not asked about math, i can make calculations later. For now i have basic function that adds or removes fixed number (speed) to coordinates X and Y. And its doing it each frame.

I was just wondering if PIXI have its own hooks / pre-made functions for movement.

PIXI.DisplayObject.prototype.moveTo = function (x: number, y: number, speed: number, onComplete?: Function): void {
	this._moveTo = {};
	this._moveTo.x = x;
	this._moveTo.y = y;
	this._moveTo.speed = speed;
	this._moveTo.callback = onComplete;
}
PIXI.DisplayObject.prototype.move = function (): boolean {
	if (this._moveTo === undefined)
		return false;

	if (this.x == this._moveTo.x && this.y == this._moveTo.y) {
		if (this._moveTo.callback)
			this._moveTo.callback();
		delete this._moveTo;
		return false;
	}


	if (this.x > this._moveTo.x) {
		if (this.x - this._moveTo.speed < this._moveTo.x) {
			this.x = this._moveTo.x;
		} else {
			this.x -= this._moveTo.speed;
		}
	} else if (this.x < this._moveTo.x) {
		if (this.x + this._moveTo.speed > this._moveTo.x) {
			this.x = this._moveTo.x;
		} else {
			this.x += this._moveTo.speed;
		}
	}

	if (this.y > this._moveTo.y) {
		if (this.y - this._moveTo.speed < this._moveTo.y) {
			this.y = this._moveTo.y;
		} else {
			this.y -= this._moveTo.speed;
		}
	} else if (this.y < this._moveTo.y) {
		if (this.y + this._moveTo.speed > this._moveTo.y) {
			this.y = this._moveTo.y;
		} else {
			this.y += this._moveTo.speed;
		}
	}
	return true;
}

Btw. i don't need to time it. (i don't care how long it will take to move sprite to the target), so this works fine for now.

move function is hooked to game tick.

[Taz]

You might still want to compensate for when FPS deviates from 60 You can pass delta (the parameter to animate function) to your move function and use 'var speed = delta * this._moveTo.speed;' to compute the FPS-adjusted speed.

[ivan.popelyshev]

That's diagonal movement, Math.max(dx, dy) metric. The object first goes by diagonal, then horizontal or vertical. That's the first thing my students implemented when I asked them to animate character movement.

[dmko]

19 hours ago, Fovi said:

In pixi example it is clearly shown that sprite could be animated by increasing x / y axis. But if i want to move something quickly then i need to increment it by a big number (like 10 or 20) that creates ugly "jumping" effect. Is that the best i can do with pixi ?

Conceptually, I guess you could add a "motion blur" filter... though I have no idea how to implement something like that!!

The idea is that you can't change is how often each visual update happens (let's say 60fps) - but you can fake it to trick the human brain. For example, let's say frame 1 it's over here, frame 2 it's over there - but also on frame 2 you have like a little bit of a trail of a faded path between here and there. Sounds like it would be super complicated, but I dunno - maybe there's some easy trickery to it.

Unless you're talking about that, ultimately a higher frame rate isn't going to save you either, you really just need to move your objects more slowly (our brain has an upper ceiling for processing frame rate too)