A_SpawParticles (X,Y,Z,XYZSpeeds,Color)

[Ravick]

Something just like: 'A_SpawParticles (Xoffset,Yoffset,Zoffset,Xspeed,Yspeed,ZSpeed,Color)'

Just to make it more easy to use particles in making effects.

Well, just an idea.

[Tormentor667]

Use A_SpawnItemEx

[Major Cooke]

I don't think he means actors, I think he means rail particles.

[TheBadHustlex]

That would be awesome. Right now, all you can do is inherit from a particlefountain and change it's spawning-duration.

[Tormentor667]

I don't think he means actors, I think he means rail particles.

Now that you say Sorry, I was a bit too quick here. Though, emulating their behaviour with an actor based variant would easily work with A_SpawnItemEx

[Gez]

Actor-based "particles" have a huge overhead compared to actual particles. On the plus side you can do much fancier effects with them.

[phantombeta]

What would be nice is an special type of actor that doesn't inherit from Actor and is pretty much the same as the particles... Pretty much "just" exposing the internal particle actor to DECORATE if there's one.
Basically, it would be something like this:

Code: Select all

particle ExplosionParticle1 {
    color Yellow
    speed 8
    fadeTime 5
    stayTime 8
}

Or like this: (Much better because this way you can use sprites)

Code: Select all

particle ExplosionParticle1 {
    speed 8
    fadeTime 5
    stayTime 8
    states {
    Spawn:
        SPRK A 1
        loop
    }
}

[Major Cooke]

I think it's a matter of actually rendering, phantom. ZDoom creates the particles themselves whereas sprites are loaded, albeit I recall Randi saying something about hardly anything is put into the renderer...

[Gez]

Or like this: (Much better because this way you can use sprites)

And you're introducing the whole "actor state" logic, which means particles would have to have the same tick() routine that actors do, and you lose a large part of the benefit of reduced overhead...

[phantombeta]

There would still be the advantage of never being checked for anything by other actors AFAIK.
Just a "sprite" property would be good enough for me.

[edward850]

Particles also use substantially less memory as they aren't an aactor or derived thinker, controllable by the end user for rendering and performance as they are inherently non-existent to the playsim, and have a special optimized rendering routine due to being a single pixel.
I have no idea why you want to over complicate this for everyone else.

[Gez]

Really the entire point of particles is that they have minimum overhead. A sprite property could perhaps make sense in GZDoom's OpenGL renderer; but it'd have to be ignored by the software renderer.

[D2JK]

What sort of things can you do with particles? Can you give them random X/Y/X velocities, subject them to (custom) gravity, have them bounce off surfaces, or emit lights (GzDoom)?

Just wondering.

[Xane123]

This' be another cool feature,especially because particle fountains and railgun particles are too limited!

@D2JK I'd assume all of those except the last two would be possible, no bouncing if they're "non-existent" to ZDoom and if each emitted a dynamic light, I could only imagine if there were a lot of them, there'd be lag.though it'd still look cool.

[Ravick]

As said, the point in using particles would rely on the less memory usage. The Wiki says we can have thousands of them on the screen at the same time. I can barely wonder what experienced modders would do with such power on their hands, even the particles itself being just single [edit] pixels with limited behavior control. Just being able to control initial speeds and color would, I guess, be an awesome feature to work with in making different kinds of effects.

edit#2: BTW, having an 'angle' parameter would also be good. (Assuming that particles can have it, of course).