Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Test Builds => Topic started by: Nuke on January 15, 2009, 11:04:43 am
-
dump in your fs2 dir, run the build with the directory as mod, load up a subach hl-7 and have fun.
clicky (http://www.game-warden.com/nukemod-cos/downloads/particle demo.rar)
so far i support 4 spew types most parameters are about the same as the default spew parameters. rotation rate is for the helix, controls direction and speed of rotation. z scale is for the sparkler, to make it more ovoid 1 is spherical. this is good for matching it up with the laser effect for some awesomeness. offset and normal dont do anything yet. the code is still abit roguh and the engine likes to crash if you try to remove unused feilds. its now 10am and im going to bed.
*added diff*
[attachment stolen by Slimey Goober]
-
i c wut u did thar:
dump in your fs2 dir, run the build with the directory as mod, load up a subach hl-7 and have fun.
fixed (http://www.game-warden.com/nukemod-cos/downloads/particle%20demo.rar)
so far i support 4 spew types most parameters are about the same as the default spew parameters. rotation rate is for the helix, controls direction and speed of rotation. z scale is for the sparkler, to make it more ovoid 1 is spherical. this is good for matching it up with the laser effect for some awesomeness. offset and normal dont do anything yet. the code is still abit roguh and the engine likes to crash if you try to remove unused feilds. its now 10am and im going to bed.
*added diff*
-
heh, i guess i was half asleep. feedback? how does it run on suckey computers? suggestions?
-
Oooh :D
Well it looks pretty awesome and is waaay ahead of all existing particle effects in game, but I'm seeing approximately a 10FPS drop while holding down the trigger, and this is on an 8600GTS with an i7 920. Might that be considerably worse on lower systems?
-
Yeah but consider the drop on some systems when rendering a lot of the old school impact effects. I don't know why but that even slows down my box considerably. 10fps on my rig right now wouldn't even be noticeable.
-
i really dont have any suckey computers right now. so its good to get feedback. had aardwolf give me a report on his crappy intel chipset and gets dropped to 30 during combat. still im impressed with the speed acheived over the old lua implementation. still im gonna put in some automatic scaling. like automatically reducing particle counts when the framerate drops below 60. more performance can be attained by tweaking. the effect i did was mostly a capabilities showcase rather than a real world implementation. then again if i can offload the system to the gpu that would further increase the speed.
-
You could tie it to the existing particle options in the graphics settings, and leave control of it in our own hands. :)
-
On my crappy Intel 945GM, framerate drops from 60fps to 30fps whenever I fire.
Playing without mediavps, on that build you posted.
-
well it would probibly crash on the media vps. for some reason the optional strings arent being very optional, so if the new flags are missing, kerplam! on the brightside i did manage to make it so retail pspews would work.
-
Pretty good looking...
Nevertheless in the very FS2 campaign mission (training one) my FPS drop from 120 to 60 when firing. And I've got a 8800GTX...
(Although I suppose, performance will improve in the future)
-
Screenshots anyone? Can we see what interesting pspew combos you guys are coming up with?
-
On my crappy Intel 945GM, framerate drops from 60fps to 30fps whenever I fire.
Playing without mediavps, on that build you posted.
On my crappy Intel 945GM, framerate drops from 60fps (the refresh rate) to maybe 30fps when there's combat, and when there's a bunch of these things at once it went as low as 17 or 18.
-
Screenshots anyone? Can we see what interesting pspew combos you guys are coming up with?
seconded, ig gonna post this on the modding board, maybe i can get some pretties :D
-
ive uploaded a new build. the ring type is now supported as are offset. i decided to replace the normal field with initial velocity. why merely indicate direction when you can indicate direction and speed with one vector. i know this is confsing cause we already have a vel value. but dont blame me because volition sucks at naming their pspew variables :D
also i fixed the required fields bug, so it should now work with pspews in mods and the media vps. this also means you only need feilds you want to use. for speed i strongly suggest omiting the 2 vectors, since they throw extra vector-vector and vector-matrix math into the mix if theyre non-zero.
its very easy to overload the game with these features and make it unplayable even on high end systems. so im gonna try coming up with some automatic scaling based on detail settings and the current frame rate. things like count time and life are your critical performance numbers. lower count means fewer particles. higher time means more delay between spews. and lower life means particles are being removed faster. so performance is dependant on how you set those values.
k ive added a couple more weapon replacements. the tempest now demonstrates the ring type. the harpoon has an effect demonstrating what can be done with the initial velocity and offset.
-
60->40fps in a nebula
60fps constant in empty space
This is with holding down the trigger using a subach.
Seriously, is this stuff even viable? 20fps drop using an Athlon X2 5600+ and an HD 4870.
-
i got a few ideas for scaling the parameters, creating fewer particles as the framerate begins to drop. other idea is to use stream processors to handle the particle system. also my sample effects pspews probibly try to go way overboard with the particle creation. the railgun emits 41 particles every frame, some of which linger for several frames before being removed. modders would need to strike an equilibrium between quality and performance. my railgun effect could probibly loose the sparler and the default spewer and still would be better off used on a weapon that fires only every few seconds.
-
Did the development for this stop, or are the new spews in other builds as well?
I really like the new spews, but the performance drop is still pretty bad. (I remember something about using the GPU might should be faster.)
Also, the particle count is still too low for multiplayer. The particle effects look very cheap from the side.
-
the problem is with the low level particle code. my code is rather high level and just says, "make these particles in this shape". really just defines particle generation rather than actual rendering or anything speed related. the underlying particle code is kinda slow, mainly because it focuses on creating a small number of detailed particles instead of a large number of simple particles. i have some theoies on how to increase their speed. one idea is to use hardware pointsprites, another is to offload the generation code to the gpu. i ony have a very rudimentary understanding of opengl, and lack the skill to do either of those things.
on the otherhand the code works well, is reverse compatable, scalable, and when used in moderation can improve the appearance of particle effects.
-
Could we also have particles that only use a single texture and fade out, or rotate and stuff like that?
Or is that another battlefield?
While it often has advantages to use ANI/EFF particles, for simple stuff, it's just a waste of memory.
-
I got a framerate hit of about 15fps running an NVidia 8200M G with an Athlon dual core 1.9GHz. I think it looks great, however its up to you guys who know the guts of the program better than I to decide how feasable it is.
-
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.
-
None of the links work anymore. Care to re-upload? :)
Edit: Updated for .13 nightlies would be real nice.
-
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 (http://nukedspace.fsmods.net/3-6-13-particle builds.rar)
-
Thanks, do you have a diff based on .13 nightly? I'll be sure to try this out later today.
-
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]
-
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. :D
-
Code review time!
- 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?
-
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]
-
Any documentation on what it can do?
-
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! :D), 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)
-
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:
$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).
$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.
-
Sounds awesome.
Can you try to enable this also for thruster partices?
-
Uh, so. How about that +Index addition or something similar?
-
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.
-
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.
-
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.
-
oh...
Thanks a lot of this! :D
I get this:
http://imgur.com/UyELC.jpg (http://imgur.com/UyELC.jpg)
And later, I added a "ring" particle, and I get this: (a little visible)
http://imgur.com/jjly6.jpg (http://imgur.com/jjly6.jpg)
Thanks!
...:nervous:...
-
oh...
Thanks a lot of this! :D
I get this:
http://imgur.com/UyELC.jpg (http://imgur.com/UyELC.jpg)
And later, I added a "ring" particle, and I get this: (a little visible)
http://imgur.com/jjly6.jpg (http://imgur.com/jjly6.jpg)
Thanks!
...:nervous:...
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.
-
oh...
Thanks a lot of this! :D
I get this:
http://imgur.com/UyELC.jpg (http://imgur.com/UyELC.jpg)
And later, I added a "ring" particle, and I get this: (a little visible)
http://imgur.com/jjly6.jpg (http://imgur.com/jjly6.jpg)
Thanks!
...:nervous:...
That's awesome
-
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.
-
BTW, what background is that?
-
They look like arachnid space plops.
I approve, is there any footage?
-
They look like arachnid space plops.
I approve, is there any footage?
Or like plasma spikes from Halo :yes:
-
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.
there are also a couple of other bugs that need to be resolved. theres a rather serious performance busting one with helical spews, where if the framerate slows down, the effect tries to compensate by making more particles, further busting the framerate. i plan to force a limit on how many particles will be spawned on a frame, if a frame takes longer than expected the particles will be spread out to cover more area (since time is distance). this will be self balancing in that as the fps goes down fewer particles per second will be created. theres another bug but its more of a quality concern, that something that would slow the game down. theres also a matter of wanting to make a few more spew types.
since ive managed to stir up new intrest in this peice of code, im considering working on it some more next month, after the holiday booze runs out.
-
oh...
Thanks a lot of this! :D
I get this:
http://imgur.com/UyELC.jpg (http://imgur.com/UyELC.jpg)
And later, I added a "ring" particle, and I get this: (a little visible)
http://imgur.com/jjly6.jpg (http://imgur.com/jjly6.jpg)
Thanks!
...:nervous:...
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.
only, I did a testing, and not problems, exept with the flash of capital explosion. (My screen in total white + crash... only one time)
But, now I can extend this effect, so Thanks! :D
-
Nuke, any update on this? I'd really, really like to get this into trunk, pwetty pwease?
-
well i was just gonna go play starcraft but really i dont have anything planned for a couple days, so il take a go at the code.
heres the roadmap so far:
-dont let helical spews spawn more particles on a slow frame (performance bug) fixed some time ago and forgotten about
-interpolate distance from center in a helical spew segment (quality issue)
-implement other planned spew types (namely plume and jet turns out plume and default could accomplish the same effect)
-add +index, +remove, and +nocreate field for xmt support
-write new documentation to replace lost documentation (if anyone has the readme from the first release let me know) (this will be wikified post-commit)
did i leave anything out?
-
Nothing in particular comes in mind that I'd add. Except a note about tbm support. For it to work, you need to be able to replace, remove and add specific pspew entries. +Index works for replacing existing pspew, but to remove a pspew you probably need both +Index and +Remove. When adding you use neither, as adding should be default behavior. $Section under $Beaminfo uses +Index and +Remove, so those could be used as an example I imagine.
-
Nothing in particular comes in mind that I'd add. Except a note about tbm support. For it to work, you need to be able to replace, remove and add specific pspew entries. +Index works for replacing existing pspew, but to remove a pspew you probably need both +Index and +Remove. When adding you use neither, as adding should be default behavior. $Section under $Beaminfo uses +Index and +Remove, so those could be used as an example I imagine.
ive been looking at the beam section code to try to figure out what it did. looks like in addition to +index i need to add +remove and +nocreate tags. im still trying to figure out how the beam section code works. then i can apply what i learned to the particle spewers. i will make this thing the first thing i work on. after fixing this and the 2 helix bugs, the code should be ready to commit. other spew types could always be coded later and patched in.
so far if you use the "particle spew" flag by itself (as is typical in the retail tables) without any of the other tags, the default values are loaded and only the first spewer is used. the effect behaves like the retail flak effect. all settings are now optional and if any tags are omitted the default value is used in its place. on a new tbl or tbm entry, spews are stored in the order they appear to a maximum of 4.
i figure the tbm behavior is something like this:
if you want to remove a spewer, you need to specify +index, and +remove. im not sure what should be done internally. say you have 3 spewers and you delete the 2nd one, should the 3rd one be downcopied to the 2nd's slot, and defaults restored to slot 3, or should i simply flag it as unused and use it the next time a pspew is added?
i figure replacement or editing requires an +index: and a +nocreate. this explicitly states to use whatever index the user wants (the user should be yelled at if they go over the limit). they could then change any value within, even the type. if the next entry is your typical additive entry, it goes in the next slot. id like to be able to dump the +nocreate flag all together but i want to be consistent with the way beam weapon sections work.
ive added a new type called PSPEW_NONE, and im kinda thinking of making it the default, rather than the retail-compatible PSPEW_DEFAULT that is being used now. on an additive load instead of just counting the number of passes in the loop and using that as the index, to instead loop through the array that stores the particle spew struct, find the first PSPEW_NONE, and store it there. of course id have to consider what to do if the parser found a "particle spew" flag and no pspew tags. i figure so long as none of the spewers are used, you could in that case set the type of the first entry to PSPEW_DEFAULT, and that will handle retail tables. of course what would happen if it encountered the flag in a modular table used in the same way? i figure the best way to deal with that is only change anything if the array is "empty" of any enabled spewers.
just thinking about it gives me headaches. really i just kinda need to know whats expected and the way things should work to be consistent.
-
I don't know if +nocreate is needed for pspew's. In the case of beam sections which contain a lot of information it is handy to overwrite only specific parts of the section, but pspews don't have that much. Yet at least. Whichever works for me. :)
-
i really dont see a need for it. technically using an +index tag should have exactly the same effect. its saying "hey, this is the index i want to use. put all these settings there!". you dont also need to say "i want to change this". it doesnt make any sense to say what your gonna do, and then say youre gonna do it.
*edit*
k i think ive got this figured out. i finished the parse code. i have to change all the other loops now to reflect the change. as it was the number of particle spewers that were used were in the weapon_info stuct. i have removed this number, since slots will now have a random access capability. instead i added a particle spew type, PSPEW_NONE. so instead of iterating through 0 to num_spewers, i simply iterate through all of them, and skip anything if its type is PSPEW_NONE. it was somewhat tricky to preserve reverse compatibility with both existing particle spew tags and the flag-only implementation used in the retail tables, but i think it will work. so heres how things should work when its done:
ommitting both +index: and +remove will add the pspew to the first available slot, starting at 0.
you may add to an existing effect with a modular table in this manor so long as there are free slots available
you may edit an existing tag with a modular table by specifying an index, you may change one value or all of them, including the type or any combination there of. any edits build on the original entry, so the effect is cumulative.
to remove a spewer you need both an +index: and a +remove tag and nothing else. removing a pespew sets its type to none and restores retail defaults.
you can also remove a tag to reset defaults, and then replace it in the same tbm entry.
using the "particle spew" weapon flag without any other tags results in using the defaults and the first spewer only, this may be expanded with tbms. so you can use tbms with new flags on retail weapons while preserving the old spews. omitting the type tag will also use default values with the default spew type unless the type was set by a previous table, in which case that type is used, if you want some other type you must use a type tag.
all slots are filled on a first come first serve basis, lower numbered slots are filled first. they wont ever change places on you, but if you delete a spewer with one modular table, and another in another table, and you add 2 more and delete one, good luck trying to figure out what spew youre editing with +index:. i suggest doing all xmt editing explicitly, if you delete slot 2 in the first xmt, place the next new one in slot 2 just so you know where its going. worst case scenario, you have to run the game up to four times to figure out the correct index.
as usual with fs tables order is not optional. examples of the correct tag order will be made available when i have a new build good to go.
of course i got some more code to rewrite before i release any code/builds. still need to make the rest of the particle spew code work with the new way data is parsed.
-
well i managed to finish implementing what i think is functional xmt compatability. i only tested it as far as using my existing particle mod, the fact that it worked predictably was a good sign. all let you guys go throught the trouble of making sure you can add, edit, and delete particle spewers.
the tags pretty much go the same way they do in the test mod, except now it goes
$Pspew:
+Index:
+remove
+Type:
and so on
so heres the build, diff, and test mod in rar form:
particles! (http://nukedspace.fsmods.net/xmtparticles.rar)
things to test:
+compatibility with retail particle spews
+compatibility with particle spews in existing mods
+spew deletion with xmts
+spew creation with xmts
+spew modification with xmts
+debug messages (information given in warnings should be helpful in debugging mods)
also note that no changes have been made to the spew types, and that helical spews are still subject to be changed for performance and appearance reasons.
-
+compatibility with retail particle spews
+compatibility with particle spews in existing mods
No debug errors, but didn't check for visual errors.
+spew deletion with xmts
+spew creation with xmts
+spew modification with xmts
Deletion, creation and modification works via tbm as expected.
Do you still want to work on this before I harass someone to review the code?
-
if only to fix those bugs with helical spews
as it stands they work, but the change im planning involves changing the meaning of one of the variables and i really dont want people getting used to it the way it is. of course i should have all the other features and bugfixes by tonight if i can avoid getting distracted for a few hours today.
*edit*
looking at my rather mind-splitting maths involved in creating helical spews it does indeed seem that the particle counts are per frame and not per rotation. so there's no reason to change that. so if a frame takes more time than usual the code will spawn the exact same number of particles as under a fast frame, meaning fewer particles are being generated per unit of time while the game is slowing down. now that i think about it i fixed that a long time ago. so i can strike that from the road map. this also means the way things are now is how they will be.
i do still want to add the apearance fix. the helix ix cut up into segments which is spawned at each frame. particles are created along the weapon path between the previous and current position of the weapon. so all the particles are created at the same time and use their velocity to move away from the axis to create the helical effect. problem is that particles created at the back end need to be made to look like theve had time to move while the ones up front barely have time to move at all. not doing this creates a jagged stepping pattern when the effect is viewed from the side. and thats what i aim to fix.
*edit again*
turned out it was a 2 line job. since velocity is essentially distance traveled in unit time all i had to do is take the velocity that i had already calculated and multiply it by frame time and that by one minus the scaler/iterator i was using. and what do you know, immediate results, helical spews look much smoother from the side now. at this point id greenlight commit, but i figure it would just be a few lines of code. better to implement a couple more types while im still familiar with the code than it is to wait a year and have to re-familiarize myself with stuff.
-
ok, new build updated. all bugs i knew about were fixed. i added a new spew type, plume. scale controls the initial width of the spew. z scale controls con/divergence. values greater than 0 will cause the effect to spread out, negative values will mace it converge or cross over. this effect is meant mostly to use with missiles, but should work in primary weapons too. see example.
clicky (http://nukedspace.fsmods.net/xmtparticles.rar)
its ready to commit, unless you can find something wrong with it.
-
Compiled fine on Mac, and I had a play through a few missions okay with the effects.
Would be good to get a few more eyes over it.
-
This has been committed to trunk in 6995 by Zacam.
-
Probably not usefull now but... I played a few missions from the FS2 campaign, found no problems so far.
-
now i can work on other things in weapons.cpp without causing loads of merge conflicts. thanks fer the commit.
-
Amazing work, these improvements are really great.
Could you try to do the same for thrusters (and, if possible, collision and weapon hit spews)?
-
See any nightly since r7080.
------------------------------------------------------------------------
r7080 | Wanderer | 2011-03-19 17:37:32 -0500 (Sat, 19 Mar 2011) | 1 line
Changed paths:
M /trunk/fs2_open/code/ship/ship.cpp
M /trunk/fs2_open/code/ship/ship.h
M /trunk/fs2_open/code/ship/shipfx.cpp
feature commit - damage and impact particle spew controls, control for setting a multiplier for propagating explosion radius.
------------------------------------------------------------------------
Not sure about thrusters though.
-
I know what that does, and although it's nice, it doesn't seem to even allow changing the spew bitmap.
I'd like impact and damage spews to be able to use spew types and allow similar customization to weapon spews.
Thrusters are more important though, and right now, they don't offer as many features as even the old weapon spew system.
Also, allowing defining multiple spews for all of them (for damage and impact, the spew used could be randomly chosen) would most likely meet with a warm welcome.