Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Nuke on November 06, 2010, 02:01:01 pm
-
gatling guns, everyone loves em. but they pose some challenges making them look realistic in games. so heres some ideas to speed up rendering.
i think it would be cool to have a weapon flag that prevents the projectile from being rendered. this is sort of how flak weapons work by default (sort of, it uses a pspew for its effect). ive actually been using a hack for this, where i would simply supply an invisible model, or blank laser bitmaps. of course im not sure how the engine handles that, it would no doubt try to render the invisible shot, so im not sure which method is faster. i think a flag would be faster still. simply any weapon that has it, will not need a model or any bitmaps. it would still make noise, still rack up damage as usual, and you could optionally have impact effects (or particle spews and trails for that matter). most of those effects are optional, but the weapon will crash the game if it doesnt have a laser effect or a model. you could probibly implement this by either making it possible to leave out model and laser effect tags. or with a flag explicitly saying "no projectile rendering".
of course that alone gets somewhat dull. rapid firing guns sometimes have mixed ammo, usually mixing in tracers with high explosive shells at some ratio. some weapons actually mix in a few types of ammo. so it would be kind of cool to substitute every xth shot with weapon y (something like $substitute: weaponname, and $frequency: 4, would replace every forth shot with weaponname). so you could make a weapon that fires an invisible shot most of the time, but every 5th or so shot may get swapped out with a weapon that has its rendering enabled. this shot could have different capabilities. you could have a maxim that fires an anti-shield round every few shots, making it more useful against fighters. it could also have a different damage type, so a weapon can be made effective against different kinds of armor.
combined these features would make gatling guns (and various other weapons) really fun.
-
I like this idea.
-
That would be great for atmospheric mods.
-
gatling guns, everyone loves em. but they pose some challenges making them look realistic in games. so heres some ideas to speed up rendering.
The primary cost to the engine for a object (especially a single model object) at this point is not really the graphics rendering cost, but the physics simulation cost of each object. Remember that collision detection physics is fundamentally Big O(n2).
i think it would be cool to have a weapon flag that prevents the projectile from being rendered. this is sort of how flak weapons work by default (sort of, it uses a pspew for its effect). ive actually been using a hack for this, where i would simply supply an invisible model, or blank laser bitmaps. of course im not sure how the engine handles that, it would no doubt try to render the invisible shot, so im not sure which method is faster. i think a flag would be faster still. simply any weapon that has it, will not need a model or any bitmaps. it would still make noise, still rack up damage as usual, and you could optionally have impact effects (or particle spews and trails for that matter). most of those effects are optional, but the weapon will crash the game if it doesnt have a laser effect or a model. you could probibly implement this by either making it possible to leave out model and laser effect tags. or with a flag explicitly saying "no projectile rendering".
Have you tested the rendering cost of more invisible objects? IIRC, the engine doesn't even attempt to render an object/sub-object that has only the invisible texture. Also, is the weapon actually colliding with anything?
EDIT: what is in italics.
-
The primary cost to the engine for a object (espcially a single model object) at this point is not really the graphics rendering cost, but the physics simulation cost of each object. Remember that physics is fundamentally Big O(n2).
Specifically, the collision detection physics. I assume that's what you meant though. :)
-
The primary cost to the engine for a object (espcially a single model object) at this point is not really the graphics rendering cost, but the physics simulation cost of each object. Remember that physics is fundamentally Big O(n2).
Specifically, the collision detection physics. I assume that's what you meant though. :)
Yes, collision detection physics. What other use is there for physics? :P
-
gatling guns, everyone loves em. but they pose some challenges making them look realistic in games. so heres some ideas to speed up rendering.
The primary cost to the engine for a object (especially a single model object) at this point is not really the graphics rendering cost, but the physics simulation cost of each object. Remember that collision detection physics is fundamentally Big O(n2).
i dont expect to be able to put out any more shots than im already putting out. i had done fire rates up to 3600 round a minute successfully (thats about a shot every frame at 60fps, anything beyond that is pointless), however i decided to cap fire rates to 1200 rounds a minute, which is the slow end of actual gatling guns (the high end is 10000 rounds a minute). 1200rpm is enough to give the desired effect, without causing a major slowdown in performance due to physics. still, a few less cycles in rendering is a few more cycles for physics.
Have you tested the rendering cost of more invisible objects? IIRC, the engine doesn't even attempt to render an object/sub-object that has only the invisible texture.
i have always figured that invisible models would be faster than black lasers, because invisible subobjects are excluded from rendering. while an all black laser bitmap would still render. even with the laser bitmaps blacked out, they are still being rendered (though the pixels may be skipped because they are zero, they are still being iterated over). as for whether they are faster or slower than rendering a laser or a non-invisible model, there is no apparent change in framerate. ive experimented with several methods for rendering the bullet tracers, i had used invisible models with glowpoints, models with transparent textures, invisible models with trails (what im using now). i dont have any basis for comparison with not rendering anything, it could be tested with a very boring flak weapon without any explosion effects.
Also, is the weapon actually colliding with anything?
i havent had any collision problems with any of my weapons, invisible models or not. i would want them to collide so that damage could be applied and impact effects shown. i just kinda want a waky to make shots invisible in flight that doesnt seem like a hack.
performance gain was not necessarily the primary concern though. i more want the option to not use laser effects or models. sometimes you may want to do the rendering with a particle spew or trail, and dont really need anything else beyond that. this by itself would be useful beyond rapid fire weapons. neither feature would really be exclusive to rapid fire weapons. swapping a weapon for another every few shots would also add to gameplay and make weapons work in a more realistic matter. the effect would be pretty cool.
-
Okay. I am not going to have a chance to investigate this for a little while.
performance gain was not necessarily the primary concern though. i more want the option to not use laser effects or models. sometimes you may want to do the rendering with a particle spew or trail, and dont really need anything else beyond that. this by itself would be useful beyond rapid fire weapons. neither feature would really be exclusive to rapid fire weapons. swapping a weapon for another every few shots would also add to gameplay and make weapons work in a more realistic matter. the effect would be pretty cool.
Thats sort of what I figured. I ignored the thing about the mixing weapons because I know that it will take coding time. It is defiantly a cool idea, but until I look at the code I really don't have any comments, if only because I have am not really that familiar with the weapons system to tell you yay or nay.
-
Should be just a simple hook into weapon_create().
-
Maybe a higher ROF can be made trough simple illusion. Instead of a single bitmap effect, use one that looks like several tightly packed bullets (streaks).
So you fire 1 bullet in reality, but it looks like you fired 5, and damage is calculated for the whole bunch.
something like this:
http://www.wcnews.com/newershots/full/starlancer02.jpg
-
well ive done stuff like that before. ive also considered using impact animations that look like a series of successive hits rather than one hit. though i find it fairly stable to use weapons firing at up to around 2400 rounds a minute. but really thats not what i want. im happy leaving the weapons in the 1200-1800rpm (my rule of thumb is pretty much $fire wait: > 0.03) range. you can also increase velocity and decrease life to prevent too many shots from being created at once. i also limit weapon banks to 1 or 2 firing points and make use of 3 banks whenever possible (this means that grouped together all weapons fire at about a third their normal rate). i may consider using those firing rate with effects to make them appear even faster.
i still kinda want the shot replace feature though, so that i can simulate mixed ammo loadouts. which not only looks cool, but also adds a new element to gameplay. ive been working out a rather complex damage model using armor.tbl and a spreadsheet. i like the idea that the model is very complex because it makes it difficult to decide which weapon to use in which situation. say i have an anti hull weapon that mixes in a penetrator round do destroy subsystems, given that the hull and subsystem have different armor types and both shots have different damage types, in addition to their hull/shield/subsystem factors. combined with subtle hints about what does what, it adds a level of randomness to weapon usage where youre never sure what you can get. you have to play around to find the sweet spots. you may choose a weapon you think is really awesome, but then find out it was only awesome in that one situation and are stuck with a dudgun.
il point out again that i should have omitted rapid fire from the topics. the features i proposed are not 100% exclusive to rapid fire weapons.
-
Updated patch below.
Well, here is a mixed ammo build. I have only tried with the FS2 lasers, but should work on all weapons except for beams.
$Substitute: Weapon Name
+Frequency: Integer
+Offset: Integer
+Index: Integer
The firing pattern is generated at parse time and is dynamicly resized to make sure the specified freqency or index will fit. $Substitute: can be repeated as many times as you want.
An example:
$Name: Circe
+nocreate
$Substitute: Lamprey
+Frequency: 4
$Substitute: Prometheus S
+Frequency: 3
$Substitute: Subach HL-7
+Index: 1
Download a test build (based on trunk) from: http://www.box.net/shared/uvx2jcf016
[attachment deleted by admin]
-
ooh goodie
*applies patch*
-
im having a hard time getting the feature to work with my weapons. your demo tbm worked fine, even when dumped on top of nukemod. but when i try to add the feature to my own weapons, shots are supposed to be replaced are, however the main weapon seems to also be replaced by some other weapon (in my case a rather large missile). im trying to figure out exactly what is causing this.
-
I've actually experienced this same thing. I tried to create an Avenger that fired an Avenger Shot every few rounds that was more powerful. Instead, all the shots are this big missile looking thing that blows up close to my ship.
I have NO idea where it is getting the data for the weapon it's producing; will have to do a bit more testing tomorrow to see if I can isolate anything further.
-
found another bug. if i try to fire two weapons that use the substitute feature in linked mode, you get this lovely assert:
Assert: position != NULL
File: weapons.cpp
Line: 4862
'Alpha 1' is trying to fire a weapon that is not selected
ntdll.dll! ZwWaitForSingleObject + 21 bytes
kernel32.dll! WaitForSingleObjectEx + 67 bytes
kernel32.dll! WaitForSingleObject + 18 bytes
fs2_open_3_6_13d_INF_SSE2 (nuke).exe! SCP_DumpStack + 354 bytes
fs2_open_3_6_13d_INF_SSE2 (nuke).exe! WinAssert + 252 bytes
fs2_open_3_6_13d_INF_SSE2 (nuke).exe! weapon_create + 482 bytes
fs2_open_3_6_13d_INF_SSE2 (nuke).exe! ship_fire_primary + 7194 bytes
fs2_open_3_6_13d_INF_SSE2 (nuke).exe! obj_player_fire_stuff + 203 bytes
fs2_open_3_6_13d_INF_SSE2 (nuke).exe! obj_move_call_physics + 1927 bytes
fs2_open_3_6_13d_INF_SSE2 (nuke).exe! obj_move_all + 344 bytes
fs2_open_3_6_13d_INF_SSE2 (nuke).exe! game_simulation_frame + 1145 bytes
fs2_open_3_6_13d_INF_SSE2 (nuke).exe! game_frame + 495 bytes
fs2_open_3_6_13d_INF_SSE2 (nuke).exe! game_do_frame + 242 bytes
fs2_open_3_6_13d_INF_SSE2 (nuke).exe! game_do_state + 403 bytes
fs2_open_3_6_13d_INF_SSE2 (nuke).exe! gameseq_process_events + 237 bytes
fs2_open_3_6_13d_INF_SSE2 (nuke).exe! game_main + 782 bytes
fs2_open_3_6_13d_INF_SSE2 (nuke).exe! WinMain + 330 bytes
fs2_open_3_6_13d_INF_SSE2 (nuke).exe! __tmainCRTStartup + 322 bytes
fs2_open_3_6_13d_INF_SSE2 (nuke).exe! WinMainCRTStartup + 15 bytes
kernel32.dll! BaseThreadInitThunk + 18 bytes
ntdll.dll! RtlInitializeExceptionChain + 99 bytes
ntdll.dll! RtlInitializeExceptionChain + 54 bytes
im using my own build here, but i tested it with your build to make sure there wasnt some sort of patch error causing this.
*edit*
i found that on ships with > 2 gun banks, firing a weapon that uses this feature linked with any other weapons that dont use the feature causes the same assert. so i tested a ship with 2 banks, one with the feature and one without, no assert.
-
Okay, try this patch.
I think I have solved the problem with regards to linking. Unfortunately it also means that the index is not specific to a bank iff the weapon_type is not unique, ie you have two of the same primary or secondary in on the ship. This could be worked around, but I honestly don't think it really matters.
I have not been able to reproduce the issue with more than 2 banks.
Patch is attached. Build can be found here (http://www.box.net/shared/h20oy8pj8j) (MD5 29BB16791E5DD5E2F8E1089B056D8DAE (14,669,148 bytes)).
Can someone please try this with secondaries?
[attachment deleted by admin]
-
the assert seems to have been fixed. i tried a few variations to make sure. the other bug seems to still be there.
i tested missiles. the normal missile was replaced with a different missile entirely. the missile that did get replaced got replaced with an entirely different missile than was specified. in my case a meson torpedo, the results were oddly amusing.
-
the assert seems to have been fixed. i tried a few variations to make sure. the other bug seems to still be there.
Do you have something that I can test with to replicate the bug.
i tested missiles. the normal missile was replaced with a different missile entirely. the missile that did get replaced got replaced with an entirely different missile than was specified. in my case a meson torpedo, the results were oddly amusing.
Hmm, so much for them just working.... :D
-
heres a modilar table that definately breaks it:
#Primary Weapons
$Name: tracer
;$Model File: hornet.pof ;invisible.pof
$Model File: none
@Laser Bitmap: newglo9
@Laser Glow: 2_laserglow03
@Laser Color: 196, 128, 64
@Laser Color2: 255, 196, 92
@Laser Length: 4
@Laser Head Radius: 0.5
@Laser Tail Radius: 0.4
$Mass: 0.15
$Velocity: 1100
$Fire Wait: 0.03
$Damage: 7
;$Damage Type: Thermal
$Armor Factor: 0.15
$Shield Factor: 0.45
$Subsystem Factor: 0.1
$Lifetime: 0.9
$Energy Consumed: 0.0
;$Cargo Size: 0.1
$Homing: NO
$Free Flight Time: 0
$LaunchSnd: 162
$ImpactSnd: 85
;$Rearm Rate: 400
$Flags: ("Player allowed" ) ;;"ballistic" "stream" "shudder" )
$FOF: 0.5
$Name: Thrasher
+Title: XSTR("Thrasher Gatling Gun", 3381)
+Description: XSTR("Gatling Gun
33mm
Conventional HE Shell", 3382)
$end_multi_text
+Tech Title: XSTR("33mm Thrasher Gatling Gun", 3311)
+Tech Anim: Tech_GTM_MX-64_Rockeye
+Tech Description: XSTR("The Thrasher Gatling Gun is a weapon available on the free market. Because of its reputation, reliability, and ease of production and maintanance, it is very popular with the military, civilians, and pirates alike. Its simple solid u-238 shells provide good armor penetration and can damage shields, making useful against fighters bombers, and criusers.", 3245)
$end_multi_text
;$Tech model: im_phalanx.pof
$Model File: none ;;invisible weapon
@Laser Bitmap: newglo9
@Laser Glow: 2_laserglow03
@Laser Color: 32, 32, 128
@Laser Color2: 64, 64, 256
@Laser Length: 0.1
@Laser Head Radius: 0.1
@Laser Tail Radius: 0.1
;$Model File: hornet.pof ;invisible.pof
;$External Model File: thrasher.pof
;$Submodel Rotation Speed: 34.907
;$Submodel Rotation Acceleration: 32
$Mass: 0.15
$Velocity: 1100
$Fire Wait: 0.03
$Damage: 8.5
;$Damage Type: Shell
;$Shockwave Damage Type: Shrapnel
$Blast Force: 75
$Inner Radius: 5
$Outer Radius: 15
$Shockwave Speed: 0.0
$Armor Factor: 0.85
$Shield Factor: 0.25
$Subsystem Factor: 0.15
$Lifetime: 0.9
$Energy Consumed: 0.0
;$Cargo Size: 0.1
$Homing: NO
$Free Flight Time: 0
$LaunchSnd: 162
$ImpactSnd: 85
;$Rearm Rate: 400
$Flags: ("Player allowed" ) ;;"ballistic" "stream" "shudder")
$Impact Explosion: Exp20
$Impact Explosion Radius: 3.3
;$Muzzleflash: mflash_medium
$FOF: 0.5
$substitute: tracer
+Frequency: 3
#end
#Secondary Weapons
$Name: Shark
+Title: XSTR("GTM-93 Shark", 3381)
+Description: XSTR("Standard Issue
Long-Range Hivel
Heavy Payload", 3382)
$end_multi_text
+Tech Title: XSTR("GTM-93 Shark", 146)
+Tech Anim: Tech_Subach_HL-7
+Tech Description: XSTR("The Shark high velocity long range missile designed to pack a huge kinetic punch. Aside from the speed of impact, the Shark's devistating warhead will inflict extream damage on its target, as well as splash damage upon other ships flying it formation. Close combat with the shark is not recomended.", 3245)
$end_multi_text
$Model File: hornet.pof ;shark.pof
$Mass: 100
$Velocity: 500
$Fire Wait: 3
$Damage: 250
;$Damage Type: Hivel
;$Shockwave Damage Type: Shrapnel
$Blast Force: 1000
$Inner Radius: 40
$Outer Radius: 60 ;400 ;make the shark blow up less for test
$Shockwave Speed: 0
$Armor Factor: 1
$Shield Factor: 0.1 ;0.6
$Subsystem Factor: 0.8
$Lifetime: 5
$Energy Consumed: 0
$Cargo Size: 2
$Homing: YES
+Type: HEAT ;ASPECT ;;chanege to heat for test
+Turn Time: 2.5
+View Cone: 120
;+Min Lock Time: 3.5
;+Lock Pixels/Sec: 120
;+Catch-up Pixels/Sec: 80
;+Catch-up Penalty: 20
$LaunchSnd: 96
$ImpactSnd: 88
$FlyBySnd: -1
$Rearm Rate: 4
$Flags: ("player allowed" ) ;"No Dumbfire")
$Trail:
+Start Width: 0.35
+End Width: 3.0
+Start Alpha: 1.0
+End Alpha: 0.0
+Max Life: 2.0
+Bitmap: newmiss2
;$Icon: icon_shark
;$Anim: ani_shark
$Impact Explosion: Exp20 ;exp_fire
$Impact Explosion Radius: 100
$Name: Stinger
+Title: XSTR("GTM-77 Stinger", 3243)
+Description: XSTR("Standard Issue
Fire And Forget
Swarm Weapon",3244)
$end_multi_text
+Tech Title: XSTR("GTM-77 Stinger", 146)
+Tech Anim: Tech_Subach_HL-7
+Tech Description: XSTR("The stinger has a small warhead, a simple heat seeking targeting system, and are fired six at a time. Excelent for supression fire or to take out small weapons platforms. it was designed for use on small interceptors and recon vessels that rely on more resposive fire control.", 3245)
$end_multi_text
$Model File: hornet.pof ;stinger.pof
$Mass: 5
$Velocity: 400
$Fire Wait: 1.0
$Damage: 20
;$Damage Type: Shell
;$Shockwave Damage Type: Shrapnel
$Blast Force: 100
$Inner Radius: 4
$Outer Radius: 24
$Shockwave Speed: 0.0
$Armor Factor: 1.0
$Shield Factor: 0.75
$Subsystem Factor: 0.5
$Lifetime: 5.0
$Energy Consumed: 0.0
$Cargo Size: 0.5
$Homing: YES
+Type: HEAT
+Turn Time: 0.8
+View Cone: 120
$LaunchSnd: 98
$ImpactSnd: 88
$FlyBySnd: -1
$Rearm Rate: 24
$Flags: ("player allowed" "corkscrew")
$Trail:
+Start Width: 0.4
+End Width: 0.8
+Start Alpha: 1.0
+End Alpha: 0.0
+Max Life: 1.0
+Bitmap: newmiss1
;$Icon: icon_stinger
;$Anim: ani_stinger
$Impact Explosion: ExpMissileHit1
$Impact Explosion Radius: 4
$Corkscrew:
+Num Fired: 6
+Radius: 1
+Fire Delay: 25
+Counter rotate: YES
+Twist: 10
$Substitute: Shark
+frequency: 4
#end
the thrasher is supposed to swap out with a tracer every few rounds. both weapons apperar to be replaced by missiles. looks like a harpoon and what seems to be a child weapon of sorts.
the stinger is supposed to fire off a shark bomb every few missiles, but seems to be launching an infyrno or one of its submunitions, which blows up as soon as its launched. essentially dont test it with invulnerability off.
-
essentially dont test it with invulnerability off.
Oddly enough, I was getting what appeared to be harpoons when firing the primary.
The cause of the issue is that FSO sorts the Weapon_info table after parse is finished, so I had to fix how the parse of $substitute worked, and add a post-parse check to generate the correct weapon_indexes.
If someone needs a updated build, please ask. No one has downloaded the last one that I posted.
[attachment deleted by admin]
-
it looks like its working, im gonna see if i can break it.
-
it looks like its working, im gonna see if i can break it.
Good, go break it, otherwise we will blame you when it causes bugs :P
-
i think +offset: is broke. using it makes the substitution not work.
-
Sorry about being so late in replying, I somehow missed your post.
How do you mean that it makes the substitution not work? That is, what is it doing, and what are you expecting it to do?
-
well i assumed what it was supposed to do is to shift the pattern abit so that the starting point for the replacement pattern may be offset by a number of shots. i kinda figured it would make things look better if all the shots would not be replaced with tracer rounds at the same time so i gave different weapons different offset values.
the problem was whenever i used an offset of any value, weapon replacement did not function. so this:
$Name: Phalanx
+nocreate
$Substitute: Phalanx#tracer
+Frequency: 9
worked, but:
$Name: Phalanx
+nocreate
$Substitute: Phalanx#tracer
+Frequency: 9
+Offset: 3
did not replace any weapons at all.
it could also be that i completely misunderstood what offset was supposed to do.
-
No, you understood just fine how offset was supposed to work.
It seems that when I wrote the loop that applies the frequency based substitutions, I was skipping the first substitution. So, attached is a fixed patch.
I am not going to post a binary because no one asked for one last time, so if someone wants one, please ask!
[attachment deleted by admin]
-
So, I take it there was no breakage?
-
well ive applied it to many weapons in nukemod without any issues.
-
Mixed ammo is now in trunk. Revision 6897.
Now available in this nightly: http://www.hard-light.net/forums/index.php?topic=74207.msg1466572#msg1466572