• Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

 Custom tile animation frames

You know, I'm REALLY trying to find myself at home with GMS2 but MAN, this is hard. Not even 5 minutes returning inside the program and I've got something else that does not work.

I have 6 frame animations in a tileset I made but GMS2 does not permit to have a 6, 10 or 3 frames tile animations. Nope, the have binary ways of permiting the number of frames (2, 4, 8, 16, 32, 64, 128, 256).

Would it be possible for us to choose a custom number of frames to our tile animations?
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
Would it be possible for us to choose a custom number of frames to our tile animations?
Nope. The way it works is not arbitrary... it's like that because it's the way to make things work as efficiently as possible. If you want something else, use an asset layer, as that's what it's for. :)
 

GMWolf

aka fel666
I sense code foiled with binary operators and bit shifting ^^
It's true that from a design stand point, its not the best: tile sets have to be designed around it's limitations.

I'm mostly ok with it. Making the animations peers of two is a sacrifice I'm willing to make for better performance, especially on mobile, where battery life more important that memory and CPU these days.
 

Mike

nobody important
GMC Elder
Its to allow everything to be (easily) on a shader at a later date. If you have 8 animations on one set, and 4 on another, and 32 on another, then you can make the texture/tables 32 max, as you just repeat the animation tables (i.e repeat the 8 frame sequence 4 times, the 4 frame one 8 times and so on). in essence, each animation has the same number of frames, and the IDE builds out the repeating sequence for you. This in turn means it can fit nicely in a texture for lookup if/when we ever get around to putting it all on a shader.

So lets say you have a 5 frame animation, and a 7 frame one, and a 32 frame one, and some 16s and some 4, 9 and even a mad 53 one. Getting this all to fit in a texture with a simple single animation cycle is complex. Making them all powers of 2 simplifies this massively, and yet still gives you variable frames without any real problems. Making frames fit in POW2 frame numbers isn't hard, but is something you need to think about.

We didn't do this on a whim.
 
So basically, you accept sprite animations with custom frames but when it comes to tiles, the system is completely different? Animation looping is not a short task to do (example, waterfalls). Once you made one, you do not want to recreate a new one just because GMS2 wants power of 2 frames.

Is there a way for you to simply detect the number of frames and simply enable or disable functions depending on the number of frames in your animation? It's just tiresome for me to have to redo all my tilesheets just to accomodate GMS2's frame laws.

As I can see how things seem to be going, anyone wanting to use GMS2 need to start from scratch their graphic work if some things just don't go with what GMS2 decides to be standard. (The 9 tile auto-tile is an example as I would need to redraw all my tiles to fit GMS2's standards as mine are mostly 9 tiles).
 
Yeah, I wish GM would let us animate tiles however we wanted, too. I'd gladly trade a little performance for more flexibility in the number of frames my animations have, along with how fast they play.
I don't know how feasible this is, though, so this is me speaking my mind, rather than an actual request or complaint.

If it is possible, I'd rather have a slower running, better looking game than a faster, worse looking one. My game runs fast enough on 1.x already, so...

Anyway, yeah. Animating tiles only in powers of two (and all at the same speed, iirc?) feels pretty limiting. For tiles, I usually use 3-10 frames, depending on what it is. With this method, I'll basically be limited to four or eight frame animations, which isn't really ideal.
 
Last edited:

Nocturne

Friendly Tyrant
Forum Staff
Admin
The whole point of tiles is that they are blindingly fast. They have been optimised to make them probably the fastest method of drawing level graphics to the screen available in GMS2, and as such have certain limitations... I find it odd that this is a problem to people, since there were constant complaints from GMS1.4 users about how slow tiles are!!! You can't have your cake and eat it in this life, so blinding speed means certain restrictions - it's a tradeoff. You can't have a luxury sports car like a Ferrari and then ask that it also has the features of a minibus - you want speed and power you use the Ferrari but don't expect to take the family on holiday in it. You want flexibility and room then you use the minibus, but don't expect to get to your destination very quickly. :)

Saying that you'd accept less performance to have a "feature" that is against the point of the whole system would mean going back to the GMS1.4 system of tiling (which is pretty horrible in the efficiency department). The speed of tiles is their main feature so to compromise that when the "problem" can be "fixed" by using the asset layer (which is exactly why we have an asset layer now) is not a good idea, imho. Note that I use "problem" and "fixed" in a very loose way as I feel that this is not a problem to be fixed, but rather something that simply requires a shift in thinking about how to use the current engine.
 
Last edited:
Saying that you'd accept less performance to have a "feature" that is against the point of the whole system would mean going back to the GMS1.4 system of tiling (which is pretty horrible in the efficiency department). The speed of tiles is their main feature so to compromise that when the "problem" can be easily fixed by using the asset layer (which is exactly why we have an asset layer now) is not a good idea, imho.
The main feature of tiles to you and others who grew up programming on the C64 might be that they're blindingly fast. For lazy younglings like myself, the main feature of tiles is that they don't completely suck from a design standpoint. Do you know how ridiculously obnoxious it is adding 50 different objects per tileset just so I can get some grass waving around or some water rippling? I've been waiting for animated tiles in GM so that my resource tree isn't clogged up with ten thousand objects that are completely empty besides holding a sprite. I've been waiting for animated tiles in GM so that I could open my tileset and drop tiles down, without worrying about going back and adding a bunch of little animation objects everywhere like a dumbass, like we've been doing for the past five years.

So yeah. Faster speed is great. I'd love an option that says "💩💩💩💩 speed!" too, though. Like I said, my game already runs fast enough in GMS1.x, using the VM.
And as far as speed goes, would making animations anything other than powers of two even destroy all speed gains over having a million objects for collision and animation everywhere? I seriously doubt that, though I could be wrong. Enlighten me!
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
The main feature of tiles to you and others who grew up programming on the C64 might be that they're blindingly fast.
My own (and the devs) past or personal feelings on this are irrelevant! I repeat, one of the constant feature requests for GMS1.4 was to make tilesets as fast and efficient as possible. We've done that! This is obviously a case of "you can't please all of the people all of the time..." :(

without worrying about going back and adding a bunch of little animation objects everywhere like a dumbass
But you don't need to do that? Just add sprites to the asset layer... c'mon it's not that hard. I don't quite get why this is such a problem and (as with a few other things that I'm seeing from a few people) it seems that the issue is not that the new way is bad, it's that it will require extra work from the dev to set it up? Things have been changed in GMS2 mainly due to popular demand, and we know that these changes will require a shift in thinking and workflow for some users, but that's not something that can be avoided if we want to improve everything for the majority.
 
Last edited:

Mike

nobody important
GMC Elder
There is nothing at all stopping you from using sprites to do your animation via overlaid asset layers. If you're doing a few small spot anims of of odd sizes, then this will work just fine. But if you want the whole world to animate and move - every tile, it HAS to be fast, and this is the fastest way of doing things.

So if you want "free" world animations then use the tile system. You can animate every tile free of cost without worry because of the way it's been done. But... if you need odd frame sizes then there will be a cost involved - no matter how small ( they all add up ), then use asset layers and sprites. If you need even more control, then do it like you did before via an instance.

Unlike 1.x there are now multiple ways of displaying animation, choose whichever one is best for you. The method of tile animation will not change as it;s simply too much of a performance hit for every tile to animate itself.
 
But you don't need to do that? Just add sprites to the asset layer... c'mon it's not that hard. I don't quite get why this is such a problem and (as with a few other things that I'm seeing from a few people) it seems that the issue is not that the new way is bad, it's that it will require extra work from the dev to set it up? Things have been changed in GMS2 mainly due to popular demand, and we know that these changes will require a shift in thinking and workflow for some users, but that's not something that can be avoided if we want to improve everything for the majority.
There is nothing at all stopping you from using sprites to do your animation via overlaid asset layers. If you're doing a few small spot anims of of odd sizes, then this will work just fine. But if you want the whole world to animate and move - every tile, it HAS to be fast, and this is the fastest way of doing things.

So if you want "free" world animations then use the tile system. You can animate every tile free of cost without worry because of the way it's been done. But... if you need odd frame sizes then there will be a cost involved - no matter how small ( they all add up ), then use asset layers and sprites. If you need even more control, then do it like you did before via an instance.
Thanks for explaining the reasoning behind the current set up, guys. If there really is such a large gain in speed by doing things this way, then I guess it can't be helped.

You guys said to just drop sprites onto the asset layer if tiles didn't work. That's fine, and an improvement over 1.x, since we no longer need to needlessly tie them to objects, but doing that still means I need to cut all my sprites out of my tileset, and I still need to add a bunch of extra sprites to my resource tree I wouldn't otherwise need. Still not ideal.

So, one last suggestion/question for you guys on this issue: How hard would it be to allow us to place parts of a sprite onto the asset layer, and have those parts animate? This way, if I have sixteen animations in a tileset that don't fit the normal tile animation rules, I can drop them all into one animated gif/sprite-strip, and use them as secondary "tilesets."

If that'd be possible, that'd be really nice. If not, I'll just work with whatever you guys give me, of course. Thanks again for your responses.
 
Last edited:

Mike

nobody important
GMC Elder
No, that wouldn't work. You'd get a single frame if you did that, so in order for it to work you'd have to build up animations using sub-textures, which means a whole new UI being added, and a new runtime component to actually process/render them. We won't be doing that. Also, it's not like the animation will be in both places. Just never add them to your tile sets in the first place and make a sprite from them.

Assume that adding new UI takes time and effort, so if any suggestion needs a whole new UI element then it has to be seriously important/beneficial for it to be done.
 
Fair enough, Mike! Just figured I'd ask how feasible it was, while I had the idea in my head. Thanks for the consideration, anyway. I'll just try to plan on keeping most animations at four or eight frames I guess, heheh. =D
 
There is nothing at all stopping you from using sprites to do your animation via overlaid asset layers. If you're doing a few small spot anims of of odd sizes, then this will work just fine. But if you want the whole world to animate and move - every tile, it HAS to be fast, and this is the fastest way of doing things.

So if you want "free" world animations then use the tile system. You can animate every tile free of cost without worry because of the way it's been done. But... if you need odd frame sizes then there will be a cost involved - no matter how small ( they all add up ), then use asset layers and sprites. If you need even more control, then do it like you did before via an instance.

Unlike 1.x there are now multiple ways of displaying animation, choose whichever one is best for you. The method of tile animation will not change as it;s simply too much of a performance hit for every tile to animate itself.
OK so here is a suggestion that COULD patch the problem. Could YYG make it possible for empty tiles to be ignored. So if I drop a 6 frame animation, I'll add 2 empty tiles which GMS2 could simply skip during it's animation. You would not be clogged up with changing the whole thing. And by the way, asking to use sprites instead of tiles makes the whole process even longer as we would need to cut out all the frames of each animation sequence of a tile sheet to create a sprite. Not good.

But skipping empty tiles seems like a reasonable request to reach both worlds.
 
OK so here is a suggestion that COULD patch the problem. Could YYG make it possible for empty tiles to be ignored. So if I drop a 6 frame animation, I'll add 2 empty tiles which GMS2 could simply skip during it's animation. You would not be clogged up with changing the whole thing. And by the way, asking to use sprites instead of tiles makes the whole process even longer as we would need to cut out all the frames of each animation sequence of a tile sheet to create a sprite. Not good.

But skipping empty tiles seems like a reasonable request to reach both worlds.
That's....genius! How about it, @Mike? Is this doable? This would be a great compromise, I think!
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
How would it "skip" them? The animation would need to pause as it waits for the last two empty frames to be passed so why not just "pad" the animation with 2 extra frames anyway? I don't get how this is a solution at all...
 

Mike

nobody important
GMC Elder
No, this simply isn't how it works. To do this every tile in the map would need it's own animation index, as they would be out of sequence with other tiles.

As it currently stands, there is a single time tick and all tiles use the same animation frame index, and this means not only is memory much reduced, but we only need to work out a single index for the whole map.

Sorry, this simply isn't going to change. if you need funny frame numbers, use sprites.
 
How would it "skip" them? The animation would need to pause as it waits for the last two empty frames to be passed so why not just "pad" the animation with 2 extra frames anyway? I don't get how this is a solution at all...
Right now it's programed to jump to the beginning of the animation when it hits the end of the row, right? Why can't it be programmed to jump to the beginning of the animation when it hits a designated "end of line" tile instead? Either an empty tile, one filled with rgb(255,0,255), or anything else? We can have animations of varying (pre-defined) lengths already, so this seems like it should work?

Unless I'm misunderstanding something here, of course. :(

Edit, ninja'd.

To Mike: Thanks for the answer, but I'm confused. How do we have different animation lengths now?

Edit edit: nevermind. Reading your explanation above, I see why this isn't possible now. Ah well. Thanks for your continued patience in this thread guys, haha!
 
Last edited:

Mike

nobody important
GMC Elder
Okay.... to try and put this to bed once and for all. Here's how the animations work.

we have 4 tiles (not including 0), 2 with no anims, one with 4 and one with 16. The IDE builds up a table like this.... (so actually 23 tiles in total)

0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
2,3,4,5,2,3,4,5,2,3,4,5,2,3,4,5
3,4,5,2,3,4,5,2,3,4,5,2,3,4,5,2
4,5,2,3,4,5,2,3,4,5,2,3,4,5,2,3
5,2,3,4,5,3,3,4,5,2,3,4,5,2,3,4
6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6
7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22
8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,7
9,10,11,12,13,14,15,16,17,18,19,20,21,22,7,8
10,11,12,13,14,15,16,17,18,19,20,21,22,7,8,9
|
etc
|
20,21,22,7,8,9,10,11,12,13,14,15,16,17,18,19
21,22,7,8,9,10,11,12,13,14,15,16,17,18,19,20
22,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21

So before tiles are drawn they are animated, that is the current "index" into this table is calculated once at the start, then when drawing tiles, there is a single indirection lookup into this table, regardless of whether you setup an animation or not. EVERY tile animates, but it'll probably just animate with itself. This removes the "cost" associated with animation.

The reason for the odd sequencing (2,3,4,5 then 3,4,5,2) is so that you can draw with later frames and this will automatically stagger animations in the world for you. If you have a flower waving around, then you don't want them all to wave around in sequence. You want them to look more random - staggered, This allows you to do that without having to do anything fancy at all.

Consider the alternative.

You have the animations above. Currently each tile takes up an INT only. If we were to have variable tile animations, then each tile you put down could be one of 2 anims, or no animation. This requires - per tile, an animation index, and a frame index and probably a current delay tick etc. You might be able to get by without this if animation sequences were held globally, but you'd still need the first 2. This would require at least 16bits for an animation index, and probably 9 for a frame index. 512 frames is probably a reasonable max - although someone would complain it wasn't at some point. So this leads to another 4 bytes. On top of this, each calculation and frame count would be MUCH slower, since we'd have to run over the whole map every frame - not just the tiles being drawn, but everything so that animations were seamless as they went on and off screen.

On top of this. Keeping Powers of 2, means it can easily workout these repeating sequences for frames - you just take the largest one, and it'll easily fit on a texture so you can look it up in a shader if you so wish.

Lastly.... even with these small restrictions, the new asset layer means you can still - without having to create an instance to hold an animation, place down some "detail" where ever you like - even off grid.

Every choice we made for this was done for a damn good reason, so that

1) Tiles are now lightning fast
2) Animations are not only supported - but free! You can animate every tile in the whole map, without cost or effort. It just works.
3) It's expandable into shaders for added effects.
4) Asset layers allow you to drop in non-grid aligned detail, and have it animate if you wish
5) if you need the ultimate control of code to animate, you can still place an instance and have dedicated animation control for these very rare cases.

So now you have total control over tiles, and animations. From simple "free" animations, to a little more expensive overlays, to instances for total control. You can pick whichever one you wish because you now actually have a choice of strategies.
 

GMWolf

aka fel666
Here is a tl;Dr of @Mike s post:
(Though I strongly recommend you read it).

1. Animation is handled on a per tilemap basis. Not on a per tile basis. So the animation index is the same for every tile.
2. This makes it fast and reliable. Also reduces problems when using shaders, etc.
3. Powers of two are used, because it allows all tile animations to be looped to be as long as the longest animation in the tilemap.

End of TL;DR.

I fully agree with this decision. It does allow for incredibly fast tiles! I've been messing around with them a bit, and I'm quite impressed.
It may not seem like a huge deal on desktop. But on mobile and web, it makes a huge difference.
If every tile required its own animation index, you would quickly get terrible performance: a huge portion of your processing power on an average sized game would be used just to increment the animation index.
This is just a very logical tradeoff.

What mike is suggesting is also rather logical:
Try to make all your animations powers of two in length. But if one or two tiles need another animation length, then create a sprite for them, and put them down in an asset layer. This isnt much trouble if you only do that with a couple one-off tiles.
 

gnysek

Member
If I understand correctly, non-animated tiles in fact are animated ones, but with same frame on every animation?
 

GMWolf

aka fel666
If I understand correctly, non-animated tiles in fact are animated ones, but with same frame on every animation?
Well, the animation has a length of one. So there is only one frame.
But I presume it still increments and wraps around every step. Saves on branching.
 

Mike

nobody important
GMC Elder
yup. every tile animates - always. This removes all "Ifs" and "buts" in the render loop, making it a single constant lookup, and makes all animations basically free.
 
Top