GML Particle system with image_index

[NeZvers]

How can I make particle system to replicate character movements when there's no place for image_index in part_type_sprite()?
Braking down all my sprite sub-images into individual sprites sounds super idiotic. Every other function that deals with sprites has an argument for image_index except part_type_sprite().

 

[Kyon]

How can I make particle system to replicate character movements when there's no place for image_index in part_type_sprite()?
Braking down all my sprite sub-images into individual sprites sounds super idiotic. Every other function that deals with sprites has an argument for image_index except part_type_sprite().

it does have a argument for setting a random sub-image, and you can stop it from animating, so that's that.
But yeah, I don't think you can choose a specific subimage..

 

[samspade]

How can I make particle system to replicate character movements when there's no place for image_index in part_type_sprite()?
Braking down all my sprite sub-images into individual sprites sounds super idiotic. Every other function that deals with sprites has an argument for image_index except part_type_sprite().

If you want that level of control you have to use your own object or make a bunch of sub particles. Assuming you aren't going to have hundreds and thousands on the screen, making your own object is fine.

For example:

/////object/////

///create event
fade_rate = 0.05;

///step event
image_alpha -= fade_rate;
if (image_alpha <= 0) {
    instance_destroy();
}

/////use/////
with (instance_create_layer(x, y, layer, obj_fade) {
    sprite_index = other.sprite_index;
    image_index = other.image_index;
    image_speed = 0;
}

You could easily expand this idea to cover a lot of things.

Or here is another solution:

 

[NeZvers]

@samspade Thanks, making particle objects is jokingly easy, but not the best option from an optimization standpoint (I'm striving for mobile game development, so optimization where possible). I think that particle system might be bit better and super easy (well, if only one image used apparently). The second option that might be even better is array or ds_list for draw_sprite_ext() but I have to figure out how to lay it down.

 

[samspade]

For just a few objects the cost is negligible and won't matter at all. However, if it is worth it, your second idea, essentially making your own particle system object, which stores all information in arrays or lists and does all the updating itself should work and be slightly faster. If literally all you want to do is draw a sprite trail for the player you can just save the x, y, and image index to an array/grid/data structure and then use a for loop in the draw event to draw n number of trails.

 

[NeZvers]

@samspade well that's what I'm planning to do, but something isn't working out (either I've forgotten how to work with arrays and/or a huge bug in laying out the code).