Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Lightspeed on December 07, 2003, 08:14:53 am
-
Remember the performance drain on the 11_18 build?
It was suddenly gone with the 12_01 build. We were all happy.
We download the 12_05 build. It's back. Not quite as bad as it was, but it's back.
first 32-bit build / 18_11 build / 1_12 build / 5_12 build
To Parts Unknown:
max FPS: 70 / 36 / 51 / 42
min FPS: 50 / 17 / 37 / 20
avg FPS: 65 / 20 / 41 / 31
i'll try to run it with that line thingy (thanks for putting it into the launcher)
-
line thingy doesn do a thing.
-
[color=cc9900]I didn't really notice a speed difference, it still looks like around 50-70 fps for me for both 12/1 and 12/5. Then again, it's hard to notice framerates when it consistently freezes for a second or so whenever something warps in or something interesting happens. I thought it loaded texes and stuff at the start, not mid-mission.[/color]
-
What 'line thingy are you talking about'? -timerbar? Thats not really going to tell you much.
The change that you might be noticing is this:
FS2 used to cache most pcx files needed before mission starts but not ani's (explosions, warps etc) becuase caching the full thing would take a lot (in those days) of video memory.
The (I think) stutters are frames of the ani's being loading in a gametime.
So I changed it to cache *everything* which lead to longer loading times but gameplay without stutters. However the extra memory usage caused low memory machines to go slower becuase they were so short on resources.
Once I released this I took it back out, now Im in the process of changing ani caching to be off by default, but you can turn it on using a flag. I'm also trying to find a better balance so some ani's that dont need to be cached like breifing ani's arent.
However lower spec machines may well have the continuing problem that if the flag is off they will have stutters and if on they will have general slowdowns. We need to find a way to reduce this.
I'll post when I have a new build ready.
-
if more people would post these kind of specs, i could turn it all into a nice little excell sheet with graph, if that would be usefull.
-
:nod: It might be. Start a new thread.
-
Tested it some more. It doesnt happen every mission or every game -- sometimes it plays just as the 12_01 build. And it happens only when theres a lot of ANIs displayed i think. That might be our problem.
Also, it threw me back to desktop once without giving any error message; something SCP had NEVER done on this system before.
-
Originally posted by Goober5000
:nod: It might be. Start a new thread.
done, you might wish to sticky it.
-
Originally posted by Lightspeed
Also, it threw me back to desktop once without giving any error message; something SCP had NEVER done on this system before.
Yeah, the 12_05 build is giving me a ton of trouble with the Homesick campaign(i haven't tried anything else)
Sometimes the game goes wacko (speed is set to 0, can't turn or anything, if you hit afterburners the sound works but nothing happens, you can hit alt-j, says warp initiated, the sound plays, but nothing happens. - this usually happens at end of mission), other times it just CTDs on me. And another time the whole screen went black and i had to reboot. I get a CTD about every 3rd mission. Meh.
Athlon XP 1600+
GeForce4 Ti4200
512mb DDR Ram
Windows ME
-
Originally posted by DragonClaw
Yeah, the 12_05 build is giving me a ton of trouble with the Homesick campaign(i haven't tried anything else)
Sometimes the game goes wacko (speed is set to 0, can't turn or anything, if you hit afterburners the sound works but nothing happens, you can hit alt-j, says warp initiated, the sound plays, but nothing happens.
Athlon XP 1600+
GeForce4 Ti4200
512mb DDR Ram
Windows ME
I had the same thing happen to me.
Athlon XP 2100+
Asus N7N8X Deluxe
Radeon 9800
! Gig DDR
Windows XP
DX 9
-
This build must be the most weird i have ever had. While making the performance test mission I discovered the following:
As soon as i put about ~15 capships or installations into a mission, FS2 will crash before even attempting to load it.
-
The speed seems to be about the same as the last build for me (a good thing). I ran through a couple of PI missions and everything worked perfectly, and as a refreshing change, I did not (yet) encounter any of the random CTDs that I have been getting in all other SCP versions.
As soon as i put about ~15 capships or installations into a mission, FS2 will crash before even attempting to load it.
Don't all the versions do that? At least the original 1.2 did this (something to do with the number of turrets/subsystems, I think), although it was not really a problem since you never had to deal with that many capital ships in one mission.
! Gig DDR
:D
-
yeah, it happens with other builds too, just checked.
Still, I hope the next build will work better again.
The great thing about this build though: the -pcx32 command line makes everything look really great (especially the interface, although i think it looked like that on vanilla FS2 too when configured correctly? I already started to wonder why it looked worse with SCP :wtf: ) without decreasing the performance at all.
-
I can see through many ships... Even though the geometry is solid...
And you should all know my specs by now...
-
hmm let me try to remember
duron 600 with some memory and a GF2
-
Yep, 320Mb of ram... win2k. :D
You know me too well :shaking:
-
Perhaps you guys who are having problems could try to narrow it down. Does the same stuff happen in OGL? Is it particular parameters that seem to make it happen?
-
Actually this is getting a bit out of hand.
When are we rolling out the new bug report system?
-
Originally posted by RandomTiger
When are we rolling out the new bug report system?
Hm. I guess we should do that soon. Look for an announcement this week.
-
OpenGL crashes me straight to desktop. It never worked in-mission here.
-
Well, I'm not sure if it's really slower or anything. But I really think that a flag to allow loading everything before the mission starts would be very good.
Example: Surrender, Belisarius!
I start the mission. It's going at about ~84FPS.
I fire my Subach (I always do this now to get it over with). It lags for a moment and two bolts are fired. Subsequently, firing the Subach no longer causes this lag.
79-82FPS
I look at my wingmen (I also always do this now). It lags for a second or two (@@) and then smooths out. Wingmen no longer lag me.
73-80FPS
I center my reticle on the transports and Vasudan fighters. It lags for a second or two... etc etc
69-75FPS.
The Hercs jump in. It lags... etc.
~65FPS
By the time both the Belisarius and Psalmtik are on the screen at the same time, there's a total of 8 craft: me and my wingmen's Myrmidons, the two Vasudan fighters, the two transports, the Belisarius and the Psalmtik. The FPS is about 40FPS now. Very decent speed, very smooth too. But whenever anything appears for the first time on my screen (or jumps in) it lags for a second ><
Explosions also do this; the first time it appears, it'll lag.
Now for the good parts.
I love RT's new gamma system. It works wonderfully and everything is not way too dark now.
Shine-mapping is beautiful. It isn't too harsh but appears enough to remind me how much better it looks now. Asteroids and Boedicia still looks odd, but I don't mind too much.
Glow maps. The two transports looks great from the dark side.
No ambient lighting. In my sensors, I can see the ship as if there was ambient lighting. In the normal view I don't. This is very good. It gives great atmosphere and I have no trouble seeing stuff in the Volition missions (except when I'm in the dark side of a really large object like an installation, in which case, it SHOULD be dark).
Engine glows. The glows are now fixed due to Lightspeed's mastery. The Beam Glow effect isn't too bold and is actually very nice. Especially the Vasudan glows. And while green afterburners felt weird at first, I began to appreciate them.
Engine thrust trails. Spectacular. Especially in conjunction with the glow effects. Watch a Vasudan fighter flying in circles around the transport it's guarding is very nice.
And all this at a framerate that averages about 25-33FPS in a more hectic battle, to about 45FPS in a more calm situation. Very nice.
Note: I am using the 12_05_r (which I assume is the release build).
My specs are:
Windows XP
DX9.0b
Celeron III OC'd to 1.33GHz (basically a P3 since the L2 cache is 256k)
256MB PC133 CAS3 SDRAM (:()
GF4 Ti4200 128MB
Finally, the ugly part. As I am writing this with FS2_open in the background, my page file usage sits at 655MB. I have only about 40MB RAM free. Mind you, the usage dropped a bit when I switched out (from looking at the time graph). What's making FS2_open use so much memory anyways?
Oh yes, one more thing. Great job making the stars and jump nodes show up again. It's rather nice to have those back =)
Hmmm. Okay, now I've run into the problem. I forget the mission name, but it's the first one where you see the Knossos Portal. Throughout the mission, it has various lags as new fighters jump in.
Finally, when the orion arrives, the game slows down to 10 FPS whenever I face it. @@
And here's a little tidbit that may or may not be useful: In the armament select screen, if I click a button, it's animation will start, but there's a lag just before the sound plays. Could it be possible that the lags are caused by sound effects loading rather than graphics?
-
The one off lag when you fire is the textures being cached.
What we need to do is cache them before the mission starts.
Doesnt look like a trival code change though.
The interface lag is the same thing (however in this case its loading the hilight graphics for that button), I'm looking into that.
-
The graphic already changed; it's before the sound plays when it lags. I was like O_o when I noticed that.
-
I might have to disagree with that but I'll take another look.
-
And you are right. I've replicated this several more times and have come to the conclusion that it's not the sound loading that causes the lag. Rather, it's the next screen that's lagging.
When I go from briefing to loadout for the first-time, it lags. Then if I go to ship-select, it'll lag, but if I go back forth after that, it doesn't lag anymore XD
In any case, I ought to be more attentive next time...
[edit] Added some pretty screenshots. It's only going to be a link though to save those poor people on dial-up.
The Lysander fades into the mist (http://filespace.brentdax.com/ChronoReverse/Deimos.png)
It's painful, but pretty (http://filespace.brentdax.com/ChronoReverse/Engines.png)
Now for a few more things.
It's all very strange, but if you select any ship besides the default, the cool new thruster effects don't show up. Not only that, but the old ugly thrusters don't even have the glow and all you get is the pof ><
And as you can see from the screenshots, the ship in the left bottom corner sensor is solid black for some reason.
Note that the colouring of the Lysander is perfectly fine despite the lack of ambient light. As a matter of fact, so far, the Volition missions do not suffer but rather benefits from the lack of ambient lighting. HOWEVER, I do believe that allowing ambient lighting to be set via FRED to be very important.
BTW, the warp.pof doesn't have edges in the nebula anymore. :yes:
Another thing: The Y targetting bug is still around. Doesn't occur a lot though so it's better =)
I just got it while trying to target the Colossus while it was jumping in (hence not targettable yet). It targetted a piece of debris behind it and then crash to desktop (of course, this was the release build so I didn't get anything in terms of messages).
[/edit]
-
Decided to put this in a new post.
Sometimes, the glowmaps are "off" until you get close enough. I took a few screenshots to illustrate.
Who turned out the lights?!? (http://filespace.brentdax.com/ChronoReverse/Glowmap01.png)
and then when you get closer, they suddenly turn on:
All systems operational sir! (http://filespace.brentdax.com/ChronoReverse/Glowmap02.png)
And just for fun, beauty shots of the Sathanas.
The Sathanas cruises by (http://filespace.brentdax.com/ChronoReverse/Sathanas01.png)
The Sathanas displays signs of weakness (http://filespace.brentdax.com/ChronoReverse/Sathanas02.png)
@lightspeed
Currently, the thruster glows for Shivan ships look... awkward. Since the flames swirl isn't animated, it's really not very nice and you can also easily tell that it's flat. The thruster trails and colours are really nice though.
-
bob made thos trails...
Originally posted by ChronoReverse
Since the flames swirl isn't animated, [/B]
LightSpeeed? ;7 :D
-
Bobbeau made the original trails. Lightspeed improved them and made the Shivan ones IIRC ;)
Oh one more thing. For some reason, if you play the FS2 main campaign, in one mission, and only ONE mission, the planet in the background has a black square around it. In all other missions this isn't true.
The mission I'm referring to is the one where you have to escort the Bastion to the jump node where it'll detonate all the meson bombs on board to collapse the node.
And here's a screenshot (http://filespace.brentdax.com/ChronoReverse/Square.png)
-
Hmm, it looks like all the planets Lightspeed did don't have a transparent background.
I'm not quite sure if I can fix that.
-
Actually, only this one is like that XD The other ones turned out fine.
-
Actually its the same for any mission with his new planets. I saw the same thing in the mission where you have to escort civilian ships to the EP node, right before "Dunkerque" (sp?). Lightspeed says that it only happens when the planets were added AFTER the nebulae. I'm hoping that when DDS gets implimented, we can get versions in this fomat that could potentially fix this problem (and possibly cut down on filesizes and system loads).
Later!
-
Ah yes, that's right, LS said that if the mission was made so that the planets are not placed before the nebulas are the boxes appear =/
I guess that one mission is the only Volition one that has the nebulas placed before the planets XD
-
Bobbeau made the original trails. Lightspeed improved them and made the Shivan ones IIRC
that's correct. The glows & the shivan thrusters are completely redone from scratch.
Oh one more thing. For some reason, if you play the FS2 main campaign, in one mission, and only ONE mission, the planet in the background has a black square around it. In all other missions this isn't true.
I know of the bug. You need to place the planets BEFORE the nebulae in the background editor, or it will not be able to blend. For some reason 32-bit alpha tgas do not work, and nobody made the code to automatically alpha blend backgrounds.
Hmm, it looks like all the planets Lightspeed did don't have a transparent background.
I cannot, and the code using the tga's is scripted to paint them opaque and then blend any other tgas over them. It just happens when the planets appear last in the background editor.
as I said, it works with most, but not every mission.
I think DDS supports transparency so that should fix the problems. It will also help to speed things up.
@lightspeed
Currently, the thruster glows for Shivan ships look... awkward. Since the flames swirl isn't animated, it's really not very nice and you can also easily tell that it's flat. The thruster trails and colours are really nice though.
really? it kinda flickers around a bit here. Ah well, i'll see what I can do.
-
Does that mean the planets will appear behind the nebulae? They're supposed to appear in front; they're closer.
-
yeah they will be blended behind, but there's no other way to do it, since TGAs with an alpha channel will not be displayed at all, and 02550 transparency is not suitable.
That's why i asked for someone to fix it so planets work with 32-bit TGAs as well :)
-
Heres another odd bug, the main build is crashing about 2 minutes into the game, and when I ran the Debug Build I got.....
Assert: hull_percentage_of_hits > 0.0f
File: E:\Languages\Visual Studio Projects\Visual C++\fs2_open\code\Ship\Ship.cpp
Line: 2521
Call stack:
------------------------------------------------------------------
parse_shiptbl() ship_init() game_init() WinMainSub() WinMain() WinMainCRTStartup() kernel32.dll 77e814c7()
------------------------------------------------------------------
The game didn't even get as far as starting with the _d build. To an uneducated eye, I would say it looks like I've given a subsystem 0% hull somewhere, but I've looked, and can't see one :(
Flipside :D
-
I get some minor graphical bugs with this build. Rotating components have a texture flickering effect and laser bitmaps show right through ships.
Not sure if those are common accross the board or limited to a certain configuration.
Running a Radeon 9700Pro...Cat 3.7's.
-
I get the lasers visible through ships as well.
Running GeForce MX440
-
Flipside. The assert is saying that the sum of all subsytems
e.g. weapons + comms + engine + ...
is greater than or equal to 100% leaving nothing for the hull.
-
Ah! I know which ship that is, I thought you could get away with destroying a ship by knocking out enough subsystems :( Ah well, Back to the Drawing Board ;) Mind you doesn't explain the sudden crash error, but at least I might be able to get there now :)
Flipside :D
Hmmmmmmm... Ok, I've altered things so that the subsystems total less than 100% and it's still doing it :blah:
Maybe a reset'll fix it
-
It would be useful if the asserts when parsing ships and weapons told you what ship/weapon was causing problems.
apparently that percentage of hits assert can prevent a div by zero error or something. thats what the comment said
-
The wierd bit is that it works in-game (non-debug), you can take out a couple of subsystems and the thing will blow apart no problem :)
Flipside :D
Edit : Which means it may not be this which is causing the crashing :(
-
I'm not a C programmer but if they work the way I'm used to in Java an assert will cause errors that don't happen in the non-debug version. The reason for this is because that's exactly what an assert is supposed to do :D
The idea is for the assert to trigger if it finds something that shouldn't ever happen under any circumstances (percentages greater than 100, less than 0 etc). That way the programmer knows exactly where the problem is and can correct it. This is much easier than a normal crash where the problem with an object can show up all over the place.
Non debug builds won't have assertations turned on and therefore won't get exactly the same crash. However the problem which caused the assertation (in this case a percentage of more than 100%) can cause a different crash elsewhere in the code.
Okay C guys. Did I get close? :D
-
Is there any way you could compile a debug version that would tell you what ship it is reading when it crashes? I've only added one model recently, and I've made sure that doesn't reach 100%. Then I can get on and find this 2-ish minute crash thingy :D
Flipside
-
Originally posted by karajorma
Okay C guys. Did I get close? :D
:nod:
Originally posted by Flipside
Is there any way you could compile a debug version that would tell you what ship it is reading when it crashes?
The debug versions should already do this. If you're getting a crash elsewhere, it's a different type of bug.
-
the asserts don't tell you what ship is causing the error. i converted the asserts converted to warnings that tell you what ship is causing problems
-
Is the new version in your siggy Phreak?
-
*looks at Phreak's sig dated 10/23/03*
*looks at Latest Builds thread dated 12/05/03*
:rolleyes:
-
PhReAk only updated his Inferno build, which is dated to Dec. 15th.
Later!
-
Hyup, of course, I forgot, we all keep our websites 100% up to date with content ;) hehehe
Flipside :D
-
woo and sid wanted an inferno exe that had ht&l working to some extent