GMS 2 How do I create a tile animation in code?

how do I create a tile animation in code with the new tilesets?
I am thinking about making my game tile based and having it use tile animation for sprites
 
ok so I need this again sadly I do not see a way to make animated tiles in the links you provided.

I am making it so when you are at the tile selection screen you can select multiple tiles by holding ctrl and left clicking on them in the proper order
 

Mike

nobody important
GMC Elder
There is no way to use the "built in" tile animation system from code. You can of course just poke in tiles, but it'll be considerably slower.

You can also setup the tile animation in the IDE, then just set the 1st tile into the tilemap. It'll then animate normally.
 
@Mike why? that was a horrible idea on yoyo games end. the whole point of code is to change things.
this makes dynamic tile maps impossible to do.
we shouldn't have to hack together a method of animating tiles because yoyo games didn't think we needed to be able to make tile animations during run time.
 
D

deciia

Guest
gms1 yoyorpg(get it from marketplace) has the way,it use background tiles.
Codes from AnimationAnimate:
Code:
// Reset timer, go to next frame. Copy a new static frame into animationSet[index, 0]
    animationTimer[_index] = animationStretch[_index];
    currentFrame[_index] += animationDirection[_index];
    background_assign(animationSet[_index, 0], animationSet[_index, animationOrder[_index, currentFrame[_index]]]);
But you want the way use new tile in gms2.
So I don't know.
 

Mike

nobody important
GMC Elder
@Mike why? that was a horrible idea on yoyo games end. the whole point of code is to change things.
this makes dynamic tile maps impossible to do.
we shouldn't have to hack together a method of animating tiles because yoyo games didn't think we needed to be able to make tile animations during run time.
The IDE build tables for animated tiles, an in the long run probably textures. This is to allow for the "free" tile animations. This makes it unlikely that these will ever move into the runner.

There is however nothing stopping you from changing tiles directly yourself using the tilemap_set() functions.
 
The IDE build tables for animated tiles, an in the long run probably textures. This is to allow for the "free" tile animations. This makes it unlikely that these will ever move into the runner.

There is however nothing stopping you from changing tiles directly yourself using the tilemap_set() functions.
doesn't tilemap_set only do single tiles?
 

Mike

nobody important
GMC Elder
At the start of a level loop through it looking for the first frame. Keep a list of the coordinates. Event "N" frames loop through this list setting the current frame of animation.
tilemap_set() is pretty quick, you can easily do this in the odd occasion that your animations need to change.

Tile map animations are for "mass" animations. Where many things in a room need to animate. For the "odd" animation that you want to change, use an asset layer and sprites. You can query these at runtime and change the frames. For the occasion where you need specific control over frames, use an object instance.

Each of these 3 modes allow progressively more control, and are progressively slower. For what your after, either change the tiles directly, or use sprites on an asset layer.
 

CMAllen

Member
At the start of a level loop through it looking for the first frame. Keep a list of the coordinates. Event "N" frames loop through this list setting the current frame of animation.
tilemap_set() is pretty quick, you can easily do this in the odd occasion that your animations need to change.

Tile map animations are for "mass" animations. Where many things in a room need to animate. For the "odd" animation that you want to change, use an asset layer and sprites. You can query these at runtime and change the frames. For the occasion where you need specific control over frames, use an object instance.

Each of these 3 modes allow progressively more control, and are progressively slower. For what your after, either change the tiles directly, or use sprites on an asset layer.
This is something I've wondered about for a bit but haven't found an adequate answer -- is there a performance difference between drawing bg tilesets and drawing sprites? If they're both being done by a single controller object, are both drawing routines of similar performance speed or is one notably faster?
 
@Mike the problem with sprites based tiles though is that you can't draw them from a single image
you have to split them up into separate sprites which makes tileset swapping impossible without dll's. since gamemaker doesn't support external sprites.

I think there needs to be a game maker update that solves all the external resource problems because it makes making an cross platform editor impossible.

all I want to do is make a retro engine and editor that works similar to what games did back in the 1990s and 2000s

I would make a bunch of extensions that included functions to the project in the form of a gex so they don't clutter the project but I don't know how to do that.
 

CMAllen

Member
@Mike the problem with sprites based tiles though is that you can't draw them from a single image
you have to split them up into separate sprites which makes tileset swapping impossible without dll's. since gamemaker doesn't support external sprites.

I think there needs to be a game maker update that solves all the external resource problems because it makes making an cross platform editor impossible.

all I want to do is make a retro engine and editor that works similar to what games did back in the 1990s and 2000s

I would make a bunch of extensions that included functions to the project in the form of a gex so they don't clutter the project but I don't know how to do that.
I'm confused. I've done animated sprite-based tiles, so what do you mean, exactly? You can draw 'part' of any image with the draw_sprite_part() function (or has that been deprecated with GMS2?), and you can load various image formats at run-time (or create your own). I grant you that you will have to write your own code for handling drawing the individual pieces, but I've already done something along a similar line, so it's not that complicated. The only thing of note is that when you create sprites at run-time, each one goes onto its own texture page, so you'd want to pack everything onto a texture page manually to avoid senseless texture page swaps (or has this been fixed??). You could also let GM create said texture pages via the texture page preview tool. Then you'd just have extrapolate the requisite drawing information for the individual sprites or assets from those texture page images. Once you do that, you can load a texture page at run-time and manually control which part gets drawn. I mean, if you think about it, when you perform a draw call for a sprite, all GM is doing is taking the information you give it to a 'behind the scenes' array to pull up what texture page it's on, what UV coordinates fully encompass the desired pixel information, and the x and y offset the resulting image information has when it gets drawn.

Heck, I went so far as to create my own sprite-builder program in GM (which I then used for the UI of said program), then built a second program to pack all the sprites I created into a single file. The format contained all the information necessary to draw all the pieces contained in the single image. Neither program were pretty, but they did the job for which they were designed.
 

CMAllen

Member
Well, currently, my map-chunk building program uses a ds_grid of ds_grids to store all that information. The top level is simply a ds_grid of the x and y coordinate of a given tile location. The sub-level ds_grid then contains the various pieces of information I need to draw the correct tile and the correct mask to blend it to the surrounding tiles and different tile sets (the tile texture type and sub-image, the type of mask it uses and the mask sub-image, and so on). _edit_ I could dispense with the 2-tier ds_grid structure and multiplied the x/y coordinates together instead, condensing the top-level 2d ds_grid into a 1d structure, using the second dimension to store the tile data itself instead of a reference to another ds_grid.

The truth is, there are a lot of ways to go about this -- some better or worse than others (I'll find out which one mine falls under eventually). An array would probably be faster, but since the data being used isn't fixed-length in nature and its size can change regularly, the functions available for ds_grids is worth the slower interaction (an array used in this way would get scattered all over GM's memory space). On the other hand, once I finalize the file format and start using it in the actual game I'm making, I will most likely move to an array structure, since the data will be used in a more read-only fashion. I won't need the ds_grid functions for manipulating the data it contains anymore.

The way I tackle animating certain tiles is by having an alarm that increments a global offset value. When the tile controller draws an animated tile, it checks the range of possible animation frames specific to that tile type (a data structure I created contains all that information), clamps the global offset to that range, and adds it to the sprite being drawn. I can do this because of the way GM assigns ID values to assets you load into the resource tree. Assets are numbered consecutively, starting from 0 at the top-most asset, and incrementing by 1 as you move down the list. So adding an offset value to the sprite argument of a draw_sprite() call redirects the draw call up or down the resource tree. This same trick can be used in a variety of other ways, such as changing which sprite you draw based on a point direction. Note: I have no reason to believe this behavior has changed with GMS2, but I felt it prudent to specify that this is for GMS1.4
 
ok well I'm going to try to use a ds_grid I'll get back to you guys if I have any problems


EDIT: I don't think the grid is going to work because I have to access it by a 1d index
 
Last edited:

Jyrocity

Member
Interesting topic, to summarize I agree that tile manipulation is very limited in code. Workaround can get pretty complicated, so I find it hard to believe that YoYo has not implemented functions to do this.
 
Top