Forums » Impact Engine » Feature request: 'tiling' an entities' animation when entity.size > animSheet size

I'd like to request a feature to enable entities to 'tile' their animation over their entire size. This would allow resizable entities with animated graphics (.addAnim()) instead of more or less simplistic visualizations relying on ig.system.context.fillRect()

In case this is already possible, I apologize (any pointers how to would be appreciated).

Let's say we have a resizable entity (i.e. acid, lava, ...) for which I have an animation sheet. As long as the graphics are static I can simply size the animation sheet as

this.animSheet = new ig.AnimationSheet('media/acid.png', this.size.x, this.size.y);
this.addAnim('idle', 1, [0]);

That works as long as the PNG is large enough.

Now if I want to add an animation (like waves) I run into a problem since while creating the PNG I can't know how large the entity will be (since its scalable). Because of that, the animation frames won't align properly.

With tileable animation sheets I could do something like this:

init: function(x, y, settings) {
    // resize the entity thru the parent method
    this.parent(x, y, settings);

    // configure animation
    this.animSheet = new ig.AnimationSheet('media/acid.png', 20, 42); // frame dimensions are fixed
    // allow the animation sheet to tile in both dimensions
    this.animSheet.tiles.x = true;
    this.animSheet.tiles.y = true;
    this.addAnim('idle', 0.2, [0, 1, 2, 3]);

Thanks in advance,
Dominique

It's surprising how many things have already been done actually in Biolab Disaster - and water is no different. You might not like how the water's implemented there, but it does fit the criteria, and allow for animation and arbitrary width (in tiles, at least)

What happens is that area is mapped to tiles in a sequence, and that the tiles are also assigned then as a background anim. The long stretch of water in Biolab Disaster's level 1 (right at the end of the level) is 16 tiles wide, and defined as pretty much alternating between tiles 80 and 81 in the main biolab.png tileset. (The level file defines them as 81 and 82 to indicate that 0 is an empty tile, but to tie in with everything else, I'll refer to them as 80 and 81 since that's how the code does it.)

Now, in the main BD code, tiles 80 and 81 are given background animations, cycling through tiles 80 to 87, in slightly different patterns (80 is set to cycle 80-87 in that order, 81 is set to cycle 84,83,82,81,80,87,86,85).

The result is that tile 80, wherever placed, will give you a wave pattern for that tile, and tile 81 will give you another wave pattern, and placed side by side you have an arbitrarily sizeable pool of liquid that is mobile.

Of course, on mobile platforms it's advisable to turn off background animations for performance reasons and if you end up pre-rendering that layer (see ig.backgroundMap), you won't get the animation either.

Doing this doesn't make it an entity, which is why you'd also place an entity like Biolab does and use that for detecting collisions against.

The problem with tiling is that unless you pull something like this, the animation is almost certainly not going to look right when tiled, and under normal circumstances you wouldn't make anything that would be tileable into an entity anyway...

Hi Arantor,

yeah I saw that it was done in Biolab. It's a clever workaround but that is why I requested this feature... it's kind of unintuitive to animate a background when I actually want to animate an entity :).

You already mentioned the side effect of slowing down rendering because pre-rendered backgrounds are out if you want this currently. I don't really see a major performance hit between animating an entity on always-the-same amount of pixels vs. 'tiling' on the entities width/height on the other hand.

Just my 2 cents, Biolab still remains full of clever hacks.
Dominique

Ah, but it's not the same number of pixels, that's the point. When you pre-render a background, you carve it up into tiles of 512x512 (256x256 for iPhone) and render those instead, which means far fewer draw ops.

In reality on a canvas, the number of draw ops overall is almost as important as the number of pixels you do, and in some cases moreso (as pre-rendering validates; drawing vast bitmap images is faster than drawing many smaller images even though the number of pixels is the same)

In the case of what BD does, I'd argue that what it does is far more intuitive than trying to tile+animate an entity. Consider what BD does: in multiple places, you have water, their behaviour is consistent each time but their size is not. So what happens is that you animate the imagery as a background with tiles, and handle the collision with a generic entity (the trigger entity is used in many more places than just water)

The handling of it also means you can very quickly disable it for a performance gain, something you would not be able to do conveniently for an entity.

I can see the logic behind your request but in reality you're actually going to be doing more work trying to make it work as an entity than you are as a background+entity combo, because the thing with entities is that their physical size (for collisions) and their animated size (for animations/rendering) are not necessarily the same thing, and for good reason.

Making it tiled surely implies that the render size must be the same as the physical size, unless you record and track three sets of things, not two? (Since presumably you'd have to store the bounding box size, the animation's size and the size you want to render to)

I actually wouldn't suggest doing it in the base entity class either, simply because of the fact that every entity then needs to make an additional check every frame simply whether it's tiled or not, which for a lot of entities might cause serious performance concerns.

I was going to go through and hack out a quick version that replaced ig.Entity.draw() with a version that supported the tiled attribute as suggested but I realised that it would also require rewriting ig.Animation to support drawing partial frames (since if it's arbitrary width and scalable, it may be across partial tiles, and I have no idea if that's a requirement or not)