Animated particles

[neoworm]

I have trouble of getting animated particles to work. I mean Particles that have multiframe animation defined in ANIMDEFS.

This is the particle generator I use for testing:

Code: Select all

class Particle01 : actor
{
	override void Tick()
	{
		int dir = randompick(-1, 1);
		A_SpawnParticleEx
		(
			"",
			TexMan.CheckForTexture ("graphics/Particles/FZFXA0.png"),
			style: STYLE_ADD,
			flags: SPF_FULLBRIGHT,
			lifetime: TICRATE * frandom (1,4),
			size: 0.5,
			xoff: frandom (64,-64),
			yoff: frandom (64,-64),
			velx: frandom (0.5,-0.5),
			vely: frandom (0.5,-0.5),
			velz: frandom (0.4,3.0),
			accelz: -0.001,
			startalphaf: 1.25,
			fadestepf: -0.002,
			sizestep: 0.25,
			startroll: 180/2,
			rollvel: 0.5 * dir,
			rollacc: 0.02 * dir
		);
	}
}

And it works with any single graphics I put into the texture field.

This is the ANIMDEFS for the particle animation:

Code: Select all

texture "graphics/Particles/FZFXA0.png"
pic "graphics/Particles/FZFXA0.png" tics 2
pic "graphics/Particles/FZFXB0.png" tics 1
pic "graphics/Particles/FZFXC0.png" tics 2
pic "graphics/Particles/FZFXD0.png" tics 1
pic "graphics/Particles/FZFXE0.png" tics 2
pic "graphics/Particles/FZFXF0.png" tics 1
pic "graphics/Particles/FZFXG0.png" tics 2
pic "graphics/Particles/FZFXH0.png" tics 1
pic "graphics/Particles/FZFXI0.png" tics 2
pic "graphics/Particles/FZFXJ0.png" tics 1
pic "graphics/Particles/FZFXK0.png" tics 2
pic "graphics/Particles/FZFXL0.png" tics 1
pic "graphics/Particles/FZFXM0.png" tics 2
pic "graphics/Particles/FZFXN0.png" tics 1
pic "graphics/Particles/FZFXO0.png" tics 2
pic "graphics/Particles/FZFXP0.png" tics 1
pic "graphics/Particles/FZFXQ0.png" tics 2
pic "graphics/Particles/FZFXR0.png" tics 1
pic "graphics/Particles/FZFXS0.png" tics 2
pic "graphics/Particles/FZFXT0.png" tics 1
pic DFEMPTY tics 3500

All graphics are there, named correctly, if I use the name of any of the graphics in the TexMan.CheckForTexture ("graphics/Particles/XXXXX.png") call it shows it correctly in game. But if I reference the animation it shows either blank white round particles or nothing at all depending on if I use "optional" keyword in ANIMDEFS definition. I tried to use different graphics for the final animation (FZFX.png instead of FZFXA0.png) and the result is the same regardless if the png exists or doesn't.
I was looking around to see some demo of animated particles and found nothing. So I can't even know if it even works at all. It is definitelly written on Wiki on A_SpawnParticleEx page that it should support animation defined through ANIMDEFS. ANIMDEFS page also reference that is is used for defining particles. The particle setup is copied directly from wiki, only change is that the particle is animated.
What am I doing wrong?

[Enjay]

I *think* I know why yours doesn't work. Using the example on the Wiki (much like you did I think) I got an animated particle generator working.
Then I set about trying to figure out why mine worked and yours didn't.
I'd set up my animdefs with short names, your one has full path names. When I set mine to use full path names, the animation stopped.

i.e. this worked:

Code: Select all

texture PARTA1
pic PARTA1 rand 4 8
pic PARTB1 rand 4 8
pic PARTC1 rand 4 8
pic PARTD1 rand 4 8
pic PARTC1 rand 4 8
pic PARTB1 rand 4 8

this did not:

Code: Select all

texture "graphics/PARTA1.png"
pic "graphics/PARTA1.png" rand 4 8
pic "graphics/PARTB1.png" rand 4 8
pic "graphics/PARTC1.png" rand 4 8
pic "graphics/PARTD1.png" rand 4 8
pic "graphics/PARTC1.png" rand 4 8
pic "graphics/PARTB1.png" rand 4 8

Just like you described, that just showed the first pic in the animation. So, it seems like it's the ANIMDEFS that's failing, not the particle.
I don't know: is ANIMDEFS supposed to support full path names?

Working one attached (just load it up in Doom2 - it replaces the Zombieman):

TestParticle.pk3

(4.51 KiB) Downloaded 7 times

[neoworm]

Just like you described, that just showed the first pic in the animation. So, it seems like it's the ANIMDEFS that's failing, not the particle.
I don't know: is ANIMDEFS supposed to support full path names?

ANIMDEFS with full path names is definitely used in example for Visual thinkers and since both Perticles and VisualThinkers just take TextureID as an argument than I presume both should work like this. But obviously they don't - neither of them. I already tried even the Visual Thinker instead of Particle and it has the same problem. I could even check with VisualThinker that it does spawn, but doesn't show any graphics as long as it's animated one. Singular sprites with long names work. So I presume it's either error in Wiki or bug in ANIMDEFS. Or an upcomming feature that is not marked as upcomming just like BEHAVIORs.

[Enjay]

I just did a quick test of a texture on a wall with this in the animdefs:

Code: Select all

texture "textures/TEXYA1.png"
pic "textures/TEXYA1.png" rand 4 8
pic "textures/TEXYB1.png" rand 4 8
pic "textures/TEXYC1.png" rand 4 8
pic "textures/TEXYD1.png" rand 4 8
pic "textures/TEXYC1.png" rand 4 8
pic "textures/TEXYB1.png" rand 4 8

And, using the texture on a wall in a map, it animated. So, yes, apparently ANIMDEFS does indeed support full path names. Why it's not working with particles, I have no idea.

AniWallTest.pk3

(5.76 KiB) Downloaded 3 times

[phantombeta]

That's odd, it's working just fine for me on GZDoom 4.14.2 and the latest UZDoom autobuild... I attached the copy I made with full path names here just in case.
Maybe there's something else going on here? What version of GZDoom or UZDoom are you two using?

[Enjay]

OK, I'm a doofus!

The reason mine wasn't working is because when I changed the ANIMDEFS to use the full path name, I forgot to change the ZScript to also look for the full pathname of the graphic. So, my ZScript was just looking for the graphic name PARTA1, but my ANIMDEFS was animating "graphics/PARTA1.png". So, the ZScript could use PARTA1 because it was a valid graphic, but I hadn't told the game to animate that, I'd told it to animate the full path version. So, obviously, the simple name version didn't animate.

So, yes, my one works with both short names and full path names and phantombeta's one does too (I'm using UZDoom rc2, GZDoom latest git build and GZDoom official).

Sorry for the wild goose chase.

However, that doesn't explain why Neoworm's one isn't working because the posted code has the full path name in both the ANIMDEFSs and the ZScript.

[Enjay]

OK, I think maybe I have it this time.
I *think* it's the very long duration at the end of Neoworm's ANIMDEFS.

I used exactly the code as posted in the OP and provided a full set of FZFXA0.png-FZFXT0.png graphics and a DFEMPTY graphic. I assume that final graphic is invisible in Neoworm's copy, but I made mine visible because I wanted to see what was going on.

Then I loaded it up.
When the particles appeared, they always just showed the DFEMPTY graphic. So, I gave it a much shorter duration (1 tic), and the animation worked (i.e. the animation visibly cycled through all frames).
My next test was to give the first frame of the animation a longer duration (200 tics) and restore the 3500 to the final frame, when I started the game, I saw the animation. Interestingly, the first few particles appeared and just showed the first frame, but after the first few seconds of the game elapsed, the particles quickly cycled through the rest of the animation and then held on the long-duration final frame - with all new particles using that frame because they are synchonised.

Given that the animation seems to be syncronised (all particles show the same graphic at the same time) my guess is that by the time the particles are actually visible, the quick part has cycled and we are just watching the 1 minute, 40 second long last frame of the animation. Either that, or the animation is synchronised with the game tics and we have a much higher chance of being in the long duration frame than any of the others at any one time. [Edit: based on the following, this seems likely.]

[Edit: Yep, final test, using the version where I extended the first animation frame, I started a game, watched the animation until all particles were showing DFEMPTY when they appeared. Then I just left the game running for another 1 minute 40seconds and, voila, all new particles showed the animation until its duration had elapsed and I was back to watching DFEMPTY again.]

There doesn't seem to be a flag for "don't make this particle synchronised", though random frames in the ANIMDEFS does kind of do it - but I don't think that would help in this case. I guess that particles are just synchronised to the game tics for efficiency or something. In fact, it may be the case that all ANIMDEFS animations are - that's ringing a bell somewhere in the deep recesses of my brain.

Anyway, the short version of the above is that it seems to be the final frame of animation at 3500 tics that is the problem in conjunction with what seems to be the synchronised nature of particles. If the final frame duration is reduced, the rest of the code from the OP can be seen working. In fact, the code as posted works, it just doesn't do what Neoworm hoped I guess.

Given the structure of Neoworm's animation, I suspect the intention was to have each particle appear on frame one of the animation, cycle through until holding on a (probably) invisible frame to give the particle enough time to vanish properly. That just doesn't seem to be how animations on particles work - unless there is some cunning way to do it.

[neoworm]

That makes sense. I thought that it kinda makes that feature barely useful but I went through the wiki again and I think this flag:

Code: Select all

SPF_LOCAL_ANIM

should do the trick. I will try that in the evening.

Then I will need some way to actually safe and propagate particle settings across multiple actors easilly, I kinda don't want to write the block of code setting up the particles every time I want to use it and even less I want to return back to the actors where I used such particle and tweak it in every place.

[Enjay]

There doesn't seem to be a flag for "don't make this particle synchronised"

Code: Select all

SPF_LOCAL_ANIM

should do the trick.

Somehow I missed that one - despite the fact that it was EXACTLY what I was looking for. In my defence, it was about 2a.m. I thought there must be something like that because without it, many of the potential applications for this feature simply wouldn't work - like a flame/fire slowly progressing from a bright orange sprite to an increasingly dark and smokey-looking one.

I just tried it and I think it will indeed do exactly what you want. Every new particle seemed to spawn from the start of the animation, regardless of what frame the other particles were on.

[neoworm]

It works now. I just found out that the scale for particles is kinda weird. It gets squished into a square and even when I use square graphics I can't get it to have the same texel as rest of the sprites. The size of the pixels is just off. Compared to Visual thinkers it's annoying. Visual Thinkers do have the correct scale and even use offsets. But I pretty much have to bookkeep them by hand - count it's lifetime and despawn it after it's done...

It's still kinda annoying to work with these. Particles don't exists as their own object so you need to pass to it the huge block of arguments every time. I wanted to store somewhere the FSpawnParticleParams for some premade particles, but I don't know how. Visual thinkers can be saved as their own objects but I need to set it's position by hand for every instance and I need to do the manual bookkeeping.
I had plan to make set of generic particle effects like flames, sparks etc and use them through the whole mod, but it's getting more hard and more annoying than just spam complete Actors with state stack. Thats what I get for trying to optimize things.

I would like to have something that have it's own spawning function like Particles which could take as parameter some premade particle object and it behaved like Visual Thinker when it comes to how the graphics are drawn.

I will probably stick to Visual Thinkers for now and write some custom spawning functions to be shared through Mixins.

[Enjay]

Yes, I spotted on the Wiki page about the square pixels thing (or, more accurately, I noticed that there was a flag to stretch them to the normal Doom ratios - no idea how that plays with rotations though). I spotted a few of the other limitations mentioned too. So, at least I've learned a bit about how xZDoom handles particles because I didn't know much about it at all until you raised the issue.

I guess that the nature of particles, and their relative efficiency, means that they necessarily lose a lot of the flexibility of more traditional actors.