Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Test Builds => Topic started by: WMCoolmon on March 18, 2005, 02:42:42 am
-
- Turret code has been revamped, AI code rearranged so that turret code is separate. It seems to work fine, but I've only done a small bit of testing.
- Dynamic clipping distance setting for objects. What this means is that if all objects that you can see are distant, then they should look better than normal. This will mess up some stuff, like beams. Shields, particles, missile trails, and nebula may also be messedup, I'm not sure.
-Two new command line options, disable collisions and disable weapon rendering. These are mostly for Omni - Omni, could you please try them with the full BSG model and tell me which helps the most? :)
-The lab will probably crash as soon as you enter it. This is known, I've been trying to code things in proper C++...however, I may just go back to the C/C++ hybrid I was using if I can't get it fixed.
-I may have fixed the weapons-going-through-shields-that-are-still-up thing while trying to optimize the model collisions code.
-The zip includes a P4 optimized build...has anyone noticed a significant difference with this round of CPU-optimized builds and the normal non-debug builds?
-As usual, there are some other tweaks/updates that I forgot
http://fs2source.warpcore.org/exes/latest/C20050318.zip
Added to the website.//redmenace
-
I put checks on both and individually... no effect. BSG with only 24 turrets attacked by 18 fighters brings fps from 120 to 7 when the battle begins. Same as all other builds. Its fine without weapons fire, fps minimum is 80fps with the same models on screen.
I had a suspicion that the insane amount of ribs on the BSG may be causing the performace drop becuse of the increased number of bounding boxes the CPU must account collission for. I revmoved ALL ribs cutting the BSG's size from 33k to 15k. That done, all I got was a boost of 10fps. HALF THE SIZE of the original and my minimum fps went from 13fps tp 20-23fps. I expected a much high performance gain. (both collission and weapons rendering were disabled in the launcher)
Strange enough I got a minimum of 25-30 on Bob's 3-14-05a build. Nothing drastic but a gain nonetheless.
From these tests I'm begining to suspect its more of a weapons rendering issue.
BTW the BSG's turrets fired at a much slower rate on your build and the rotation was much more jerky.
-
Odd...did both the flags work correctly? With both on, none of the ships should've been damaged or even hit, and weapons fire shouldn't have shown up at all (except for muzzle flashes).
If they did work correctly, that leaves the physics code and the AI code as the most likely candidates - which have to increment through all objects. (In the case of turrets, per turret). Or something else, which has to enumerate through all objects. :doubt:
What I'd really like is a profiler...unfortunately, my copy of VC++ doesn't have one.
-
Nope... the ships were getting destroyed and I see all weapons fire.
-
Originally posted by Omniscaper
From these tests I'm begining to suspect its more of a weapons rendering issue.
I can second that. Same happens in WCS as well: while in the older builds I have small performance drops, new builds go down to 15 fps. That makes a 300% performance drop.
-
What file-format are you using for the weapon shots?
-
Probably Lighspeeds maxim effects, or the default ones...
If it's Lightspeeds, it's a no duh why the framerate is getting killed, the maxim uses animated particles to create the right effect.
-
mostly custom WCSaga pcx images. Laser is the most common bolt, resolution is 64*64, 8 bit
P4 build increases the in game performance by 30-50%
-
Interesting. I'm now using the same build, and the same data as Tolwyn, but I have no noticable slowdown at all. Though my machine is very fast, but like you all describe, I should also encounter slowdowns in battle.
If it helps you figure it out, it must be related to single launcher-flags and not the entire code. As said, I have no slowdowns, and I'm using "only" these flags here :
-glow -jpgtga -fps -ambient_factor 125 (using the P4-Build)
so the error must be in another flag (maybe shine-maps, since I'm one of the few persons that isn't using them).
But there are two things I would like to mention :
1) I was very suprised seeing that you (or probably Bobboau) implemented the correction of the turret-erection into the code, so we don't have to mess with it in the tables. (That is really some remarkable progress, I'm convinced that sooner or later we will be able to put multipart-turrets on non-horizontal faces too ;), keep up the good work guys :yes: )
Only thing I would like to see : Could you make the turrets on the underside also point into forward direction ? Could you change that please ?
2) I also noticed something, which I think is a part of your 3d-cockpit tryouts, I mean the feature, that you now see your own fighter-hull when looking backwards. However, I'm a little skeptic about that feature to it's current state of development. In the first version I could see through my own fighter (simply because the eyepoint was inside the model). I now set the Eye-point higher, but for a good effect I have to set it nearly so high, that it is obviously wrong (gives the feeling that you sit above your cockpit). Is there a way to "block" the view backwards, when you are "inside" the cockpit, or must we model cockpits for that first ?
(I hope it is understandable, what I'm trying to descripe here, but here is a pic for explanation, and a sideview of the fighter embedded so you get the idea where the cockpit is).
(http://www.starman.ag5.de/pics/backwards.jpg)
Besides that, my own shipmodel was only rendered while I'm inside, or very close towards the capship. As soon as I get into a bigger distance (+ 300 meter maybe) the rendering stops and I get the normal "empty" back-view).
-
AFAIK you should only see your ship hull with the show_ship flag in the tbls.... at least that's the way it is on the build I use.
{immature}
hehe.... turret 'erection'....
{/immature}
-
Yeah, show ship should only work with the ship flags; I think I forgot about Padlock view while fixing it, though. Its rendering only when close to a big ship is a result of the dynamic clip distance stuff.
The turret code stuff was in my local codebase. It wasn't really supposed to have gotten commited, so it must have snuck in with my big merge. :nervous: I'll see if there's an easy way to fixx0r upside-down turrets, but it'll go out if I get any complaints about it causing problems with models.
I'll also get the disable-collision/weapon rendering flags fixed.
-
Okay, I uploaded a new build. It should render shield effects and muzzle flashes a bit better with the dynamic clipping,.and fixes the no collision/no weapon rendering flags.
I also made some modifications to the show-cockpit code.
-
Yes it works now. Even with the flags on, I'me still experiencing the same performance drop with BSG and 20 fighters. FPS went as low as 7fps.
I did some more experimenting with different settings, and I get a 50% increace in performace when the "lighting" settings only has 3 dots. Specular disappears on everything though.
There must be away to disable specular in relation to distance, or limit the amount of interactive lighting in furball scenarios. Disabling sound also gives me a 30 percent increase, but thats definitely not an option for our project.
-
Well, I'll look into optimizing the turret code - at the moment, each turret individually goes through every object in existence, which includes weapons fire - I should be able to have each ship make a list of valid targets, then have turrets choose from that list.
I think I've also tracked down why the BSG's turrets were slower im firing, too.
-
Looks like I have no luck at all. :(
I was so happy seeing this turret-arm correction, but unfortunately I have to say that in this build the turrets aren't rotating properly anymore (infact, they nearly don't do any rotation at all, or only a very small one).
Guess it has to go back to the drawing board.
-
If you fly a cap-ship the beams don't work.
-
don't forget some waepns should be getting shot at (bombs)
and while your looking at it, could you see how much work would be involved to implement interceptors, weapons designed to nutralise incomeing weapons fire. a weapon flag should enable interceptor weapons to colide with any other weapon, and make the AI prioritise incomeing weapons fire.
-
Would this allow interceptors A La B5 defensive screens? Right now, we can only intercept secondaries with the "Bomb" flag, but would this allow for interceptable primaries... with a certain flag however?
-
that was the principal reason for me asking.
-
Cool!
-
Originally posted by Bobboau
don't forget some waepns should be getting shot at (bombs)
and while your looking at it, could you see how much work would be involved to implement interceptors, weapons designed to nutralise incomeing weapons fire. a weapon flag should enable interceptor weapons to colide with any other weapon, and make the AI prioritise incomeing weapons fire.
I don't think it'd be a whole lot of work. The same functions that handle bombs could be used instead of interceptor weapons, and making turrets shoot at them should just be a matter of specifying any weapons with the interceptor flags as valid targets.
-
well it isn't the interceptor that gets shot at, it's the interceptor that does the shooting, a turret with an interceptor weapon on it should target the most dangerous weapon of any kind that it can find.
-
Is this a D3D primary build, OGL or both?
-Ta
Update:
Woah, few buggies.
Though I found there did seem to be a bit of a perfomance increase.
But as you can see, a few other bugs show up:
Piccy (www.3dactionplanet.com/hlp/hosted/tap/grug/bugs01.jpg)
That's running in OGL, the numbers seem to render below the player ship.
More saddening however is that in OGL and D3D, the weapon effects are chopped in half when in Alt-Pause mode. So I goto try and take a screenshot, and the effects are chopped in half if the camera is close.
At a longer distance however, it appears that they are normal.
I think they work ok from the cockpit view too.
I need a screenshot build... :p
-
Ok, tried this build and its somewhat stable. However, I keept getting random crashes related to sound bits sometimes.
Also, any mission using the cutscene sexp's CTDs giving a program error once I try to hit commit and launch itno the mission (there is no problem during loading at all)
I've yet to try it with another build though, so it may be something else. Also, these sexps were from the latest FRED build, where I used the menu stuff rather than doing it via notepad.
-
Yeah, Jake101 had the same problem - turns out I did something exceptionally stupid. Something like:
if(in_rotation_rate == NULL)
rotation_rate = *in_rotation_rate;
else
vm_vec_zero(&rotation_rate);
In english: "If rotation rate is an invalid pointer that is sure to cause FS2 to crash if it is accessed, then access it and set the rotation rate to its value. Otherwise, set the rotation rate to 0."
-
Whoops, a little backwards in your code logic there. I still do that from time to time, so I completely understand how that kind of bug gets introduced.
-
well, its prevalant from the 0306b build onwards (the earliest I have). Any chance of fixing it anytime soon? I really need to use the missions ASAP :/
Another random crash: whenever I am about to die (i.e. hull 1% all systems 0), it will crash immediatelybefore giving me the death message at all. Rather odd :/
-
Yeah, I'll try to remember to upload the release build I made to test it.
-
http://fs2source.warpcore.org/exes/latest/fs2_open_ex.zip
-
ok, it stopped crashing for me now, but another bug popped up instead.
After the first scene, when the sexp calls for camera movement of any sort, it'll move for a split-second before resetting itself to the first view. No matter how many camera changes I have after that, it will reset itself to the first view.
The error appears to be in set-camera-facing, since set-camera position seems to work allright.
really, really odd though, to say the least :/
-
Does the same problem happen with set-camera-rotation?
-
Originally posted by WMCoolmon
http://fs2source.warpcore.org/exes/latest/fs2_open_ex.zip
Most stable build recently. Good job, and nice that you included Bob's new warp effects.
-
Originally posted by WMCoolmon
Does the same problem happen with set-camera-rotation?
Haven't tried yet, will do so by today.
-
OK. I've found a bug with the "ex" build (and possibly others before, I don't get the chance to test too often). As you can see from the pic below, the targetting of jumpnodes gives and out-of-position result for the targetbox. I also had this when targetting a sentry gun, (which I gave a cruiser AI so it could mount HUGE weapons).
(http://www3.sympatico.ca/daniel.topps/TargetOffset.jpg)
Also, some of you may have noticed that I'm using a non-standard jumpnode model. This is one Bob released when node rendering was switched to HTL.
-
Is this only for certain ship types, or with everything that you target.
Also, are you using a different FOV from normal or have an odd screen size?
-
That node looks horrible. Way too busy. If you don't want to use the one Raa made (IIRC) I released one that was closer to standerd, but I thought HTL had been fixed to use the old node anyway.
-
Originally posted by StratComm
I thought HTL had been fixed to use the old node anyway.
:nod: :)
-
I've only noted this on the jumpnode and on said sentry gun. I am using no perspective-altering command lines, and resolution is 1024/768. It should be noted however, that prior to this, targetting a jumpnode, (since the model was first HTL-ised), always resulted in the target box being very small compared to the node... though in the correct spot.
As for why I use this node model, I like it. Its actually got an inner sphere too.
-
Originally posted by WMCoolmon
Does the same problem happen with set-camera-rotation?
set-camera-rotation is even more screwed up. Teh viewpoint jumps all over the place instead of to the way I want it. It's damn scary, to say the least :nervous: