Why have particles when you can use sprites?

[Artwark]

Honestly, for GMS, I really don't see the point of particles unless you're doing a prototype or for playing alpha versions since you can just get sprites to do the job for you.

It makes sense in Unity but game maker.....I really don't see the point of them.

If you feel particles have some use in game maker studio, well let's hear it out here then..

 

[Electros]

...Aren't they hugely more CPU friendly as they don't interact?

Also I have found particle streams and bursts really useful and flexible, as you can just tweak parameters. E.g. in the game I am working on, the rain is all tweaked parameters for a particle stream, and the exploding splinters of wood are actually a sprite, but really easy to configure with a particle burst.

 

[Mike]

They are much faster. You can have many more particles that instances or even drawing your own sprites in a loop.

 

[Artwark]

Problem is that particles take a lot of memory and can lead to lags.

They are much faster. You can have many more particles that instances or even drawing your own sprites in a loop.

Wait....how can creating particles using sprites be easier to do than manually doing the sprites instead of particles? I don't get it.

 

[MelodicCodes]

By "sprites", I'm assuming you're referring to using instances as particles.

The problem with this is that instances take up significantly more memory. They have a lot of setup and initialization code which is run, and for replicating particle effects, you need to have them be updating every frame. Particles don't need to run much of the code that instances need to, and thus, they take up significantly less space in memory, and significantly less time is spent running through the step/draw events of each particle.

I'm not too familiar with Game Maker's backend programming, but I can tell you firsthand that particles are superior to "instance particles" in the vast majority of situations. They are more limited than what you can do using instances, but when using an instance in place of a regular particle, you need to always ask yourself why, and if it's worth the performance tradeoff.

And yes, you can assign sprites to your particles, as in custom graphics. It takes a bit more work and is pretty intermediate, but it's good some goooood stuff. Check up on the YYG docs here: https://docs.yoyogames.com/source/d...articles/particle types/part_type_sprite.html
HeartBeast on YouTube has also done some great video tutorials regarding how Game Maker's particle system works for more advanced uses, including use of sprites to create more interesting visual effects than the default emitters do.

As a side note, there are times when you may want to use instances in place of particles. For example, when your game uses delta time and you expect the framerate to change a lot during play. But in the vast majority of cases, particles are superior for drawing... well, particles.

 

[Artwark]

By "sprites", I'm assuming you're referring to using instances as particles.

The problem with this is that instances take up significantly more memory. They have a lot of setup and initialization code which is run, and for replicating particle effects, you need to have them be updating every frame. Particles don't need to run much of the code that instances need to, and thus, they take up significantly less space in memory, and significantly less time is spent running through the step/draw events of each particle.

I'm not too familiar with Game Maker's backend programming, but I can tell you firsthand that particles are superior to "instance particles" in the vast majority of situations. They are more limited than what you can do using instances, but when using an instance in place of a regular particle, you need to always ask yourself why, and if it's worth the performance tradeoff.

And yes, you can assign sprites to your particles, as in custom graphics. It takes a bit more work and is pretty intermediate, but it's good some goooood stuff. Check up on the YYG docs here: https://docs.yoyogames.com/source/dadiospice/002_reference/particles/particle types/part_type_sprite.html
HeartBeast on YouTube has also done some great video tutorials regarding how Game Maker's particle system works for more advanced uses, including use of sprites to create more interesting visual effects than the default emitters do.

As a side note, there are times when you may want to use instances in place of particles. For example, when your game uses delta time and you expect the framerate to change a lot during play. But in the vast majority of cases, particles are superior for drawing... well, particles.

Correct me if I'm wrong but according to the documents from yoyogames, they stated that having particles can lead to slowdowns and can get the game crash.

And I still don't get it. Say you want to make an explosion. You draw the sprite for it, either give it as a change instance when a car is destroyed to give that animation or use sprite_index and then the instance is destroyed.

So how adding particles can lower the space memory if the procedure is the same?

 

[NPT]

Correct me if I'm wrong but according to the documents from yoyogames, they stated that having particles can lead to slowdowns and can get the game crash.

How bout you provide the document that claim this?

So how adding particles can lower the space memory if the procedure is the same?

Look, the documentation doesn't support your claim, nobody here supports your claim, including the lead Game Maker developer. The procedures are not the same.

If you believe using sprites to get similar effects, post an example comparing the two that can be benchmarked.

 

[FrostyCat]

Correct me if I'm wrong but according to the documents from yoyogames, they stated that having particles can lead to slowdowns and can get the game crash.

Is this the line you are talking about?

Particle systems, particles and emitters take up memory and as such you should be very careful how you use them as it is very easy to cause a memory leak which will slow down and eventually crash your game.

I can see novices interpreting this in an alarmist fashion, but anyone with a genuine CS background can see through that. Anything that allocates additional memory or resources at runtime can lead to slowdowns and crashes if excessively used. For instance, buffers, data structures, surfaces, vertex buffers, particle system and even plain old instances all fit the bill.

Are you going to turn those down too just because they can all be abused to the point of instability?

And I still don't get it. Say you want to make an explosion. You draw the sprite for it, either give it as a change instance when a car is destroyed to give that animation or use sprite_index and then the instance is destroyed.

So how adding particles can lower the space memory if the procedure is the same?

The procedure is definitely not the same once you consider what hasn't been explicitly written out.

According to the page on particle types and its sub-pages, I count around 30 particle-type-specific properties. According to the built-in variable listings from the Scripts menu (for instances only), I count almost 90 instance-specific properties (with alarms taking 11 of them).

Particles passively update their lifespan, position, direction, size, colour and orientation and that's it. Instances share most of that but also have other stuff to deal with: Activation/deactivation, events in the step cycle, collisions, other passively updated properties that particles don't have.

All this evidence points to instances clearly being the loser on both memory and performance. Unless you absolutely need behaviours that only instances have, there is a clear advantage in using particle systems.