Best practice for animating sprites

#1

What is the best practice for animating sprites. performance wise?

My current approach is to load a sprite atlas into a Sprite and adjust scrollRect for different frames.

#2

If you’re experiencing performance issues, try switching to Tilesheet. If you aren’t experiencing performance issues, don’t worry about it.

1 Like
#3

Actually, I’m not optimizing. I’m writing a library for 2d pixel-perfect lighting and shadows, and I was wondering what is the generally-considered-best way to animate sprites (so I can modify only the parts the are currently displayed).

#4

from some time I have been doing animation, some people say use Timer, other say use EnterFrame event, while some recommends the use of time increment.

Some things I have coded:

  1. I tried to use Timer/x, y increment, i can get it close to pixel perfect animation.

  2. Then tried to use EnterFrame, it is smoother than Timer/x, y increment.

  3. But using the Actuate Library beats them all, it is the smoothest OpenFL animation I have seen, I think it uses time increment.

#5

Actuate uses ENTER_FRAME, and I don’t think I’d call it better or worse. It produces the exact same results as if you’d coded the animation yourself with ENTER_FRAME events.

There’s no standard that I know of. Joshua once said he wants to make every option really fast, so that people don’t have to worry about things like this. I’m not sure that’s possible, but at least it makes a good goal.

Anyway, when you aren’t trying to optimize, the “best practice” is always to write simple, maintainable code.

The code you described sounds simple enough, so you shouldn’t need to change much. My one suggestion is, if you’re loading a Bitmap anyway, why not skip the Sprite? You can scroll a Bitmap in exactly the same way.

#6

Actuate is a hybrid of ENTER_FRAME events, plus delta time, so it’s time based, but only on frame events. So I think it’s a bit stronger than either a strict Timer-based or ENTER_FRAME-based solution :slight_smile:

#7

Isn’t that standard practice when using ENTER_FRAME?

#8

I know a lot of people who insist on using ENTER_FRAME only, with equal increments each frame. If you drop frames (or are inconsistent at all) it quickly does not look smooth, but some people say just to test a lot. Personally I think delta time makes a huge difference in making things look great :slight_smile:

#9

I made tests. Switch prepared bitmaps in sprite container much faster.
200 animations with change scrollRect = fps decreases to 18
500 animations with juggle bitmaps = fps still 45-50

But i tested it for flash platform.

UPD Ran tests on cpp platform (android device with -Dlegacy). There swap approach showed pretty low fps… :astonished:
UPD2 Forgot about blitting. 1 bitmap canvas and copy pixels. It should be fastest)

#10

Currently, swapping bitmaps is (likely?) the fastest Flash method, and drawTiles is faster on native. I hope to unify this in the future with things like Tilemap