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

[Hellser]

I agree with Ravick's original idea. Let's skip the whole sprite idea and stick with manipulating particles directly.

[Major Cooke]

I could see this being expanded upon in several ways:
- Color shifting over time
- Size start and end
- Alpha start and end
- Shape

[Hellser]

- Shape

... next in the exhibit, we see ZDoom trying to do a circle.. out of a 2x2 pixel. Some others say, though.. that it is a square.

[Major Cooke]

Before you know it, the stars will align.

[edward850]

Before any more crazy ideas pushes this off the deep end:

A_SpawnParticle(fixed xoffset, fixed yoffset, fixed zoffset, fixed velocityx, fixed velocityy, fixed velocityz, color color, byte lifetime[, bool fullbright = false[, byte startalpha = 255[, byte size = 1[, int fadestep = -1[, fixed accelx = 0.0[, fixed accely = 0.0[, fixed accelz = 0.0]]]]]]])
Spawns a particle from the offsets of the referencing actor, with velocity, colour (same as A_RailAttack and likewise), lifetime defined in tics (0 will ignore spawning), fullbrightness flag, byte alpha value (255 means opaque), size, step of fade each tic (-1 means the internal automatic value of 255/life), and accelerators (think gravity per tic).
This is every possible thing you can modify about particles.

[20:17:46] <Kyle873> Edward850
[20:17:48] <Kyle873> can I get that in ACS
[20:17:49] <Kyle873> please
[20:17:49] <Kyle873> please
[20:17:50] <Kyle873> please
[20:17:50] <Kyle873> please
[20:17:51] <Kyle873> please
[20:17:51] <Kyle873> please
[20:17:54] <Kyle873> please
[20:17:56] <Kyle873> please

void SpawnParticle(fixed x, fixed y, fixed z, fixed velocityx, fixed velocityy, fixed velocityz, int color, byte lifetime[, bool fullbright = false[, byte startalpha = 255[, byte size = 1[, int fadestep = -1[, fixed accelx = 0.0[, fixed accely = 0.0[, fixed accelz = 0.0]]]]]]])
Exactly the same as the decorate counterpart, except with absolute x/y/z positions for spawn, and colour is a hexadecimal value (i.e green is 0x00FF00). Note the lack of return code; This function provides no feedback (as with anything to do with particles), so always assume a particle can very well fail to spawn.

As well as the pull request (+ACS), here's a demo executable+WAD.

And example code:

Code: Select all

ACTOR DoomImpBall_Par : DoomImpBall replaces DoomImpBall
{
  States
  {
  Spawn:
    BAL1 AAAA 1 Bright A_SpawnParticle(Random2(3), Random2(3), Random(2, 6), frandom(-1.0, 1.0), frandom(-1.0, 1.0), frandom(-1.0, 1.0), "Red", Random(17, 70), true, 255, Random(1, 6), -1, 0, 0, frandom(0.1, 0.2))
    BAL1 BBBB 1 Bright A_SpawnParticle(Random2(3), Random2(3), Random(2, 6), frandom(-1.0, 1.0), frandom(-1.0, 1.0), frandom(-1.0, 1.0), "Orange", Random(17, 70), true, 255, Random(1, 6), -1, 0, 0, frandom(0.1, 0.2))
    Loop
  Death:
    BAL1 CCCCCCCC 0 Bright A_SpawnParticle(Random2(3), Random2(3), Random(2, 6), frandom(-1.0, 1.0), frandom(-1.0, 1.0), frandom(0.5, 1.0), "Red", Random(17, 70), true, 255, Random(3, 6))
    BAL1 CCCCCCCC 0 Bright A_SpawnParticle(Random2(3), Random2(3), Random(2, 6), frandom(-1.0, 1.0), frandom(-1.0, 1.0), frandom(0.5, 1.0), "Orange", Random(17, 70), true, 255, Random(3, 6))
    BAL1 CCCCCCCC 0 Bright A_SpawnParticle(Random2(3), Random2(3), Random(2, 6), frandom(-1.0, 1.0), frandom(-1.0, 1.0), frandom(0.5, 1.0), "Gray", Random(17, 70), false, 255, Random(3, 6))
    BAL1 CDE 6 Bright
    Stop
  }
}

Code: Select all

script "nuke_effect" open
{
    for(int y = -96.0; y <= 160.0; y+=64.0)
        for(int x = -224.0; x <= 224.0; x+=64.0)
            SpawnParticle(x+random(-32.0, 32.0), y+random(-32.0, 32.0), random(-16.0, 8.0), 0, 0, random(0.1, 1.0), 0x00FF00, 50, true);
    delay(1);
    restart;
}

[Graf Zahl]

Waiting for sign-off by another developer.

My main concern with this is that it spawns a single particle which may be a performance issue. Even though I have to admit I have no good idea how to change this without making the interface a lot more complex.

[edward850]

My original idea for this function was A_PaintbrushParticles, but ran into the problem where each velocity needed two values minimum to define ranges, let alone the accelerators. However, outside of the quite frankly overkill "nuke_effect" script which is a worst case scenario, you will normally only end up spawning one particle at a time anyway, otherwise it just looks crowded. If anybody runs into an effect they could be improved as a range of some kind, i.e sectors spawning particles, that would work better with a unique function.

Assuming such a sector effect were possible, however is not the scope of the request.

[jpalomo]

I gave it a little stress test to see how the performance was. Using edward's example WAD, I cranked up the amount of particles spawned significantly, then increased the maximum particles via r_maxparticles. I didn't notice a performance hit until around 10,000 particles. I am using an i5-4670K.
Edit:
I can test it on some lower-end hardware later if needed. I realize that most people probably don't have a mid-high end CPU.

[phantombeta]

[...]
A_SpawnParticle(fixed xoffset, fixed yoffset, fixed zoffset, fixed velocityx, fixed velocityy, fixed velocityz, color color, byte lifetime[, bool fullbright = false[, byte startalpha = 255[, byte size = 1[, int fadestep = -1[, fixed accelx = 0.0[, fixed accely = 0.0[, fixed accelz = 0.0]]]]]]])
[...]

Okay, we need vectors and structs and stuff in DECORATE, because the amount of arguments for this and A_SpawnItemEx is just absurd.

[Graf Zahl]

That wouldn't really help here, with all the 'random's that will be commonly needed with this function.

[Edward-san]

I found no problems with the changes, so I give my approval.

[Major Cooke]

my approval.

I see what you did there. Graf means trusted programmers.

[Blzut3]

The answers for how to create something elegant and user friendly and how to make something as flexible is possible are usually disjoint. Especially when you start with the premise of making a structure available via a function call. Perhaps someone can come up with a relatively simple interface to generate effects like those from P_DrawSplash? For example something like: A_ParticleSplash(count, ttl, x, y, z, angle, pitch, speed, scatter_dist, color1, color2="None", speed_spread=0, angle_spread=0, pitch_spread=0) Might need some refinement, but I guess the goal would be to do a decent emulation of the spark actor using the Active state.

[edward850]

After a quick word with Blzut3, a template type in decorate that predefines accelerators, velocities and colour ranges wouldn't be a bad idea for spawning groups, and a sprite name could be logically included in that (if the rendering for it can be worked out). Then you'd just need a A_SpawnParticleType(str type, int count) function to spawn a collection of that type.
However, while that would not only require needing to work out an addition thing for decorate to parse, it'd also become a question of if it'd conflict with "ZScript" (whatever that'll be called).

However, the heart of this request was allow a projectile to leave a trail of particles, and I still think that request has at-least been met for now. There's still room for expansion on other ideas later.

[Graf Zahl]

The answers for how to create something elegant and user friendly and how to make something as flexible is possible are usually disjoint. Especially when you start with the premise of making a structure available via a function call. Perhaps someone can come up with a relatively simple interface to generate effects like those from P_DrawSplash? For example something like: A_ParticleSplash(count, ttl, x, y, z, angle, pitch, speed, scatter_dist, color1, color2="None", speed_spread=0, angle_spread=0, pitch_spread=0) Might need some refinement, but I guess the goal would be to do a decent emulation of the spark actor using the Active state.

Is this an approval or not?