Page 1 of 2
A_SpawnParticle... Reogrenized.
Posted: Thu Jan 21, 2016 6:38 pm
by Major Cooke
https://github.com/rheit/zdoom/pull/498
https://github.com/rheit/acc/pull/39
...Do I even need to comment on this?
I will say one thing though. if this gets in, I'm nuking the wikipage. The date of entry will point to this git in particular.
Re: A_SpawnParticle... Reogrenized.
Posted: Thu Jan 21, 2016 7:10 pm
by Gez
You fault for creating it so soon.
Re: A_SpawnParticle... Reogrenized.
Posted: Thu Jan 21, 2016 7:14 pm
by Xaser
This is still highly un-optimal, as the flags/lifetime parameters are buried behind all the position/movement ones. I don't want to have to type 'A_SpawnParticle("#FFFFFF', 0, 0, 0, 0, 0, 0, 0, 35, SPF_FULLBRIGHT)' if all I want is a non-moving glowy particle.
My suggestion:
A_SpawnParticle(color, flags, lifetime, size, xoff, yoff, zoff, velx, vely, velz, accelx, accely, accelz, startalpha, fadestep)
This puts all the x/y/z ones in order, puts flags near the beginning, and leaves startalpha/fadestep at the end since they have nonzero defaults and (IMO) are likely to be the least-used ones.
Probably a good idea to make zero for
lifetime and
size mean "use default" if it doesn't yet, since a value of 0 wouldn't make sense for either. Can maybe say the same for startalpha/fadestep, so feel free to do so and move those earlier in the list.
Thinking on it, defaults for everything except
color is probably a good idea as well. Just whatever order allows me to not have to type a zillion zeroes for the position/velocity params.
Re: A_SpawnParticle... Reogrenized.
Posted: Thu Jan 21, 2016 8:03 pm
by Major Cooke
Done.
Yes, the angle parameter on the decorate version is before the offsets. I'll need more access to that than you think...
Re: A_SpawnParticle... Reogrenized.
Posted: Thu Jan 21, 2016 8:28 pm
by Eevee
Hm! I rewrote the particle fountains in DECORATE — this should be exactly identical to native, except for some minor precision and RNG details. This uses the current arg order on master, of course.
Main source of ugliness is that you can't choose a string at random (for the color), so the entire call has to be duplicated. Alas, you can't have string user vars either, so each color of fountain would have to duplicate all of this as well.
Code: Select all
ACTOR TestRedParticleFountain
{
Height 0
+NOBLOCKMAP
+NOGRAVITY
+INVISIBLE
var int user_angle;
var int user_dist;
states
{
Spawn:
TNT1 A 2
TNT1 A 0 A_SetUserVar("user_angle", random(0, 360))
TNT1 A 0 A_SetUserVar("user_dist", frandom(0.0, 1.0 * radius))
TNT1 A 0 A_JumpIf(random(0, 255) < 30, "Color2")
Color1:
TNT1 A 0 A_SpawnParticle(
/* offset */ user_dist * cos(user_angle), user_dist * sin(user_angle), (height + 1) * 1.0,
/* velocity */ frandom(-128.0, 127.0) / 4096.0, frandom(-128.0, 127.0) / 4096.0, frandom(-128.0, 127.0) / 4096.0 + 3.0 + ((user_dist < radius / 8) * 0.333),
/* color */ "ff 00 00",
/* lifetime */ 51,
/* flags */ 0,
/* alpha */ 255,
/* size */ 6,
/* fadestep */ -1.0,
/* accel */ frandom(-128.0, 127.0) / 16384.0, frandom(-128.0, 127.0) / 16384.0, frandom(-128.0, 127.0) / 16384.0 - 0.0909,
/* angle */ 0)
Goto Spawn
Color2:
TNT1 A 0 A_SpawnParticle(
/* offset */ user_dist * cos(user_angle), user_dist * sin(user_angle), (height + 1) * 1.0,
/* velocity */ frandom(-128.0, 127.0) / 4096.0, frandom(-128.0, 127.0) / 4096.0, frandom(-128.0, 127.0) / 4096.0 + 3.0 + ((user_dist < radius / 8) * 0.333),
/* color */ "ff 7f 7f",
/* lifetime */ 51,
/* flags */ 0,
/* alpha */ 255,
/* size */ 4,
/* fadestep */ -1.0,
/* accel */ frandom(-128.0, 127.0) / 16384.0, frandom(-128.0, 127.0) / 16384.0, frandom(-128.0, 127.0) / 16384.0 - 0.0909,
/* angle */ 0)
Goto Spawn
}
}
- screenshot; DECORATE on left, native on right
Re: A_SpawnParticle... Reogrenized.
Posted: Thu Jan 21, 2016 9:19 pm
by Major Cooke
Nothing I can do about it, sadly. I think that has to wait for doomscript, for strings anyway.
Re: A_SpawnParticle... Reogrenized.
Posted: Thu Jan 21, 2016 11:25 pm
by Nash
Yo don't forget about us ACS folks
Re: A_SpawnParticle... Reogrenized.
Posted: Thu Jan 21, 2016 11:32 pm
by Major Cooke
No I sure didn't. This time...
Re: A_SpawnParticle... Reogrenized.
Posted: Fri Jan 22, 2016 2:34 am
by Graf Zahl
Eevee wrote:you can't choose a string at random (for the color),
I thought it'd parse an int as well. But apparently it doesn't. Well, this will have to wait for the scripting branch to get merged. I'm not going to mess around with the old parser for this.
Re: A_SpawnParticle... Reogrenized.
Posted: Fri Jan 22, 2016 2:37 am
by Graf Zahl
Merged.
But this makes me think:
The ACS version uses absolute coordinates. I wonder if it makes sense to add a second variant that uses a map spot tid instead. As it is it can only be used for effects that are placed in the world - not for effects that are tied to an actor.
Re: A_SpawnParticle... Reogrenized.
Posted: Fri Jan 22, 2016 4:35 am
by kodi
I haven't looked through the function, but shouldn't using getactorx(TID) and getactory(TID) + eventual offsets be enough?
Very excited for this anyway.
Edit: I see. An alternate function sounds like a great idea then.
Re: A_SpawnParticle... Reogrenized.
Posted: Fri Jan 22, 2016 4:37 am
by Graf Zahl
That wouldn't allow spawning stuff at multiple points with one call.
Re: A_SpawnParticle... Reogrenized.
Posted: Fri Jan 22, 2016 5:16 am
by Fishytza
Since there are 16 parameters (for the DECORATE version) numbered 0 to 15, shouldn't ACTION_PARAM_START be 16?
Re: A_SpawnParticle... Reogrenized.
Posted: Fri Jan 22, 2016 5:33 am
by Graf Zahl
If it actually did something - yes. This was meant to be some advance preparation for scripting but Randi chose to do it differently, so it's rather moot to care.
Re: A_SpawnParticle... Reogrenized.
Posted: Fri Jan 22, 2016 5:44 am
by Fishytza
Well, at the moment it's rather inconsistent when compared to other DECORATE functions. (And yes, you're right, it is a moot point, but my OCD
screams says otherwise. >_< )
Also...
Graf Zahl wrote:This was meant to be some advance preparation for scripting but Randi chose to do it differently...
Out of curiosity, does this mean all ACTION_PARAM_STARTs will be removed at some point? If yes, then what's the point of using it when making new DECORATE functions?