[Nuke]

ive been faking fadeout with animations, those look a lot better than the usual particle effect where particles are just blipped out of existance in one frame. its a feature id like to have in particles. but then again it might slow it down. if i understand things correctly, animations tend to use up more memory but not that many more cpu/gpu cycles, since all youre really doing is changing the pointer from frame to frame. id like to add an alpha life to particles, a factor of how much of the particles life is spent fading out. problem is that starts touching the low level code which i as of yet am still unfamiliar with.

one thing i could try to improve performance is decreasing the size of the particles, and their bitmaps as well. my demo used 512^2 or 256^2 animations which should have been around 64^2 or 128^2 at maximum, since most particles barely take up that many pixels on the screen anyway. i also thought about single color particles, which would work on more primitive trails, such as helical trails, which i pretty much use diffuse blobs on anyway. still that sounds like it would be slower than just using the memory, since youd have to come up with a gradient procedurally.

i wouldn't know how to rotate particles without using more math (slower), besides just animating them. ive done that before with other bitmaps and it seems to work quite well. my system assumes particles as primitives rather than as detailed bitmaps.

using bitmaps of sane sizes really dont eat as much memory. try to use as few frames as possible and as small a bitmap as possible. if you animate it you might want to use lods, progressively using fewer, smaller frames as range increases. lods essentially trade memory for cpu/gpu power, and in the case of particles cpu/gpu cycles are in the lesser supply (law of the minimum). 99% of the time those particles wont use up more than a few pixels on the screen at any given time. until i can optimize the low level code there's really no other way to boost performance.

[Fury]

None of the links work anymore. Care to re-upload?

Edit: Updated for .13 nightlies would be real nice.

[Nuke]

yea, i uploaded a newer version to my ftp not long ago. nothing has changed but it was compiled against a more recent trunk.

here it is

[Fury]

Thanks, do you have a diff based on .13 nightly? I'll be sure to try this out later today.

[Nuke]

here yea go.

*edit*
ah crap, this has iss mneur's weapon swap code in it. forgot to backup my code base before applying that patch. i can manually remove it if neccisary.

*edit again*
removed the other code from the patch, so this should be just the particle stuff. patch updated.

[attachment deleted by admin]

[Fury]

I think I can do some neat tricks with this code of yours, I'll be sure to play with it a lot. Hopefully I can somehow get some new effects though.

The E was less enthusiastic about this though.

[The E]

Code review time!

Code: [Select]

- parent_objp = NULL;
- if(parent_objnum >= 0){
- parent_objp = &Objects[parent_objnum];
- }
-(from weapons.cpp, line 4751)

Explain to me why you think that's a good idea?

[Nuke]

i kinda was scratching my head about that one. i dont think that has anything to do with my particle stuff. i think it may be a diffing error, or something i missed while fixing a conflict. i kinda wanted some coder feedback.

*edit*

yep, this looks like the result of some kind of patching error, or a cat, so i merged that code back in.

[attachment deleted by admin]

[Dragon]

Any documentation on what it can do?

[Nuke]

there was at some point a rather detailed set of instructions in a readme file. it was either in the original attachment which was removed (blame goober! ), or on my old gamewarden ftp which went down and lost all my files. for some reason i dont have it anywhere on my computer (which is odd because im pretty thorough at backing stuff up). so il post a quick summary based on comments in my code:

support for up to 4 (limit can be changed in source) particle spewers.
the ability to offset spew position and provide a direction vector for the effect.
all particle tags are now optional

multiple spew patterns, including:
 default - what you have now
 helix   -railgunish trail
 ring   -particles radiate outward from a point in a ring shape
 sparkler   -particles spew out in all directions from the source, which can be spherical or ovoid
 plume   -spewers arrayed within a radius for thruster style effects, may converge or scatter (planned but not implemented)
 jet   -particles spew from a fixed point in a line, mostly for simple missile trails (planned but not implemented)
 lightsaber   -started as a joke but is sort of like jet, except the spew points originate from any point in a line (planned but not implemented, may be removed)

new table tags (all go under $pspew):
 +Type: -string type identifier (see above)
 +Count: (same as before)
 +Time: (same as before)
 +Vel: (same as before)
 +Radius: (same as before)
 +Life: (same as before)
 +Scale: (same as before)
 +Z Scale: (for sparkler types, multiplyer for z velocity for sparkler types, 1=spherical, <1=flat disk shaped, >1=ovoid )
 +Rotation Rate: -only used for helical spews, sets the rate of rotation about the z axis (i think this is rotations/sec)
 +Offset: -spawn origin of particles with relation to shot center (should work for all type)
 +Initial Velocity: -particle velocity (both speed and direction) with regaurds to object (should work for all type)
 +Bitmap: (same as before)

[Fury]

I found out yesterday that this code is missing something rather important.

Something similar to +Index under $Beaminfo $Section.
http://www.hard-light.net/wiki/index.php/Weapons.tbl#.24BeamInfo:

You see, a beam consists of multiple sections and modders needed the ability to modify individual sections in tbm's. For this purpose you needed a way to determine which section you wanted to modify in a tbm, thus +Index was born.

And now that there are multiple $Pspew flags within a single weapon, modifying those in another tbm seems to be a pain in the arse. So what you need is a way to be able to differentiate one pspew from the others.

So, for example. If original weapon has following pspews set:

Code: [Select]

$Pspew:
+Type: helix
+Count: 5
+Time: 5
+Vel: 0.02
+Radius: 0.7
+Life: 120
+Scale: 9
+Rotation Rate: 3
+Bitmap: rail_blob_1
$Pspew:
+Type: helix
+Count: 9
+Time: 5
+Vel: 0.01
+Radius: 0.4
+Life: 120
+Scale: 4
+Rotation Rate: -6
+Bitmap: rail_blob_2

And you want to modify existing pspews and add more in another tbm. How would you do it? If we take a note from how beam sections were done, then it should be fairly simple (for a modder).

Code: [Select]

$Pspew:
+Index: 0
+Type: helix
+Count: 9
+Time: 5
+Vel: 0.01
+Radius: 0.6
+Life: 90
+Scale: 4
+Rotation Rate: -6
+Bitmap: rail_blob_2
$Pspew:
+Index: 1
+Type: default
+Count: 20
+Time: 15
+Vel: 0.5
+Radius: 0.1
+Life: 150
+Scale: 0.5
+Bitmap: rail_blob_3
$Pspew:
+Type: sparkler
+Count: 7
+Time: 15
+Vel: 1
+Radius: 0.25
+Life: 60
+Scale: 9
+Z Scale: 8
+Bitmap: rail_blob_3
You see that the first two pspews above have +Index: defined and have values of 0 and 1. Which means those two override original's pspews 0 and 1 and add a new, third pspew.

[Dragon]

Sounds awesome.
Can you try to enable this also for thruster partices?

[Fury]

Uh, so. How about that +Index addition or something similar?

[Nuke]

in theory it sounds like it would be an easy thing to implement. if index is found, then stick it in that index regardless of whats there. and possibly change the number of particle spews if its less than what it was. but i must admit im not 100% sure how modular tables work internally. how would/should things work if you try to replace spewer #3 with another effect, but want to keep #4, and how would deletions work.

also theres the fact that i really havent touched this code in a year, aside from fixing conflicts as i updated from svn. so id have to re-familiarize myself with it. i had always planned to bring this up to a more stable/useful/compatable state, but never got around to it. maybe after this infernal holiday season i might be in the mood to work on it, but at this point i wouldn't mind if someone took over. id hate to see the feature fall into obscurity. id be happy to provide up to date diffs on request, and i might actually finish it myself someday if noone beats me to it.

[Fury]

ihow would/should things work if you try to replace spewer #3 with another effect, but want to keep #4, and how would deletions work

I dunno what's the best approach code-wise, but I'd suggest doing it so that if you use +Index 4 in $pspew, it would replace previous third $pspew completely. Other $pspew flags would remain untouched that are other than index 4.

Might be best discuss it out with other coders and use beaminfo sections as something to compare to.

[Nuke]

i admit with 4 spewers set up for a weapon it makes it somewhat annoying if you want to make a slight variation. if you want to make a slight variation of a couple of the spewers, i think you would just need the $pspew: tag and the tag you want to change. i think if you want to change the 2nd spew you could use the first $pspew with no child tags, and it would act as a place holder for the first spew effect (it might try to load default values, which would be your standard flak spew). i think it would be better to explicitly say you want to replace #2. likewise i might also have a +delete option, for clearing unused spews.

still if there are any set conventions for handling parsing subsets like this, i think it would be best to follow them. often ive found myself scratching my head trying to figure out how to remove tags (such as a trail) with a modular table, and ended up cutting and pasting the entire block of tags and omitting nocreate to make it work. im thinking about it now and i dont think theres a way to delete anything with an xmt, i think its an entirely additive process.

[Jessnec]

oh...
Thanks a lot of this!   

I get this:
http://imgur.com/UyELC.jpg
And later, I added a "ring" particle, and I get this: (a little visible)
http://imgur.com/jjly6.jpg

Thanks!

 ......

[Nuke]

oh...
Thanks a lot of this!   

I get this:
http://imgur.com/UyELC.jpg
And later, I added a "ring" particle, and I get this: (a little visible)
http://imgur.com/jjly6.jpg

Thanks!

 ......

i find so long as you dont go completely overboard, these spewers look awesome. going overboard means your framerate will drop by half. but if you can fit 8 wings of fighers, half hostile and half friendly with this weapon and stay at 60 youve probibly struck a good balence. also note that you can use different bitmaps for each spewer. but other than that its not a bad looking effect.

[Spoon]

oh...
Thanks a lot of this!   

I get this:
http://imgur.com/UyELC.jpg
And later, I added a "ring" particle, and I get this: (a little visible)
http://imgur.com/jjly6.jpg

Thanks!

 ......

That's awesome

[Fury]

Yes it is. I very much would like this to get into trunk. The only thing it really, really needs is +Index or equivalent for tbm's.