View Issue Details

IDProjectCategoryView StatusLast Update
0000961FSSCPgameplaypublic2006-11-01 04:54
ReporterARSPR Assigned Totaylor  
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
PlatformP4 2.8 HT - 1.5GB - 7800GSOSWindows XPOS VersionSP2
Summary0000961: Severe performance drop RC2 -> RC3
DescriptionLook at the fps in the attached pictures. They're from "The Stars are Right" within SCP Derelict. You can see how when I'm facing the Lucifer class (just at the begining of the mission) the fps drops from about 55 (RC2) to 25 (RC3)
Additional InformationMy command line is C:\FreeSpace2\fs2_open_r.exe -mod MOD_Derelict,MOD_LightSpeed,mediavps -spec -glow -jpgtga -mipmap -nomotiondebris -2d_poof -noscalevid -cache_bitmaps -dualscanlines -targetinfo -rearm_timer -ballistic_gauge -ship_choice_3d -3dwarp -warp_flash -alpha_env -fps -ambient_factor 60
TagsNo tags attached.

Activities

2006-06-27 17:00

 

RC2 55 fps.jpg (216,079 bytes)   
RC2 55 fps.jpg (216,079 bytes)   

2006-06-27 17:00

 

RC3 25 fps.jpg (214,462 bytes)   
RC3 25 fps.jpg (214,462 bytes)   

ARSPR

2006-06-27 17:01

reporter   ~0005975

OOPS I forgot to properly set Category and Severity (Choose whatever you want).

kasperl

2006-06-28 11:32

developer   ~0005981

Calling it Gameplay because I'm not sure it's pure graphics stuff.

taylor

2006-06-28 17:15

administrator   ~0005982

It's the Lucifer, I get the same speed drop looking at blank space in that mission. If I look at the space station though, it goes back to full FPS, so it's something specific with, something. I can only assume that this is graphics related in some regard, though I'm a bit curious why my speed dropped from 60 (v-sync) to 25 as well. Getting the same FPS there is just a little strange.

I'll take this one and try and figure it out later today.

taylor

2006-06-28 20:44

administrator   ~0005985

Just profiled it and the problem seems to be related to collision detection in some way. Nearly 50% of the CPU time for that mission was spent doing collision detection. I got a diff between RC2 and RC3 and there just weren't that many changes. What was fixed was mainly small stuff and there should be no difference in collision detection.

Though, for some reason, it's something linked with the Lucifer model, destroy it and the FPS goes back to normal. I don't have issues with that model in other missions so it may be linked more to circumstances (ie, docking, playing dead, etc).

There might be more to this than I thought. Unfortunately, I won't have another chance to debug this until sometime next week.

ARSPR

2006-06-29 17:12

reporter   ~0005994

Well, some more "desinformation":

With new Redmenace's P4 2006-06-28: About 55 fps (similar to RC2)

With new Redmenace's normal 2006-06-28: About 40 fps.

???

ARSPR

2006-06-30 18:37

reporter   ~0006001

Another double post ...

As you can see in 962 last screenshots, the FPS raise to about 35 when the first Ganimede docking ring has been destroyed. Without any Ganimede docking ring FPS are at "full speed" (about 50-55).

And now a noob and probably stupid idea to "quickly" track down the bug. If there are few changes between RC2 and RC3, and none is obviuosly causing it, why don't you compile different partial RC2.xx builds adding a change in each one till you get which addition causes it? (And then, for testing possible cross effects, build one version with just THAT change).

ARSPR

2006-07-06 16:20

reporter   ~0006055

With RC4 keeps in 20-25 fps.

taylor

2006-07-08 13:00

administrator   ~0006081

I think it's just an optimization issue now that I've played with it a bit more. I was testing with a debug build and got the speeds you are getting, but changing to a release build I get almost no slowdown. Between RC2 and RC3 we took off one optimization (that caused the Y-bug crash) and that's probably making the difference. I plan to change the optimization settings again (since there is a better release build setting) for the official 3.6.9. At that point I think things will be back to normal for release builds, speed wise.

taylor

2006-07-09 03:22

administrator   ~0006098

Try the RC5.1 build (Goober and I apparently released at the same time, my build is in the same thread). It's got the good compiler optimizations again, but hopefully not the same stuff that caused the 'Y' targetting crash.

ARSPR

2006-07-09 08:59

reporter   ~0006109

Last edited: 2006-07-09 09:51

Yes, now it seems to work fine.

Close it or mark it as resolved. Nevertheless I will check every future release with this mission and versus RC2 to see if there's any noticeable difference in their speeds.

edited on: 07-09-06 05:51

taylor

2006-07-09 15:00

administrator   ~0006115

Ok, I'll wait to verify that RC5 doesn't have the Y-bug, then commit the project file changes for this to CVS, and mark as resolved after that.

taylor

2006-07-15 22:27

administrator   ~0006190

Y-bug doesn't seem to have come back, and the changes are now in CVS.

Fixered.

ARSPR

2006-07-22 20:29

reporter   ~0006296

Last edited: 2006-07-22 20:31

Well I don't want to reopen the bug as it seems fixed.

I'm adding this bugnote just because I've found another mission which also causes it. And it's Derelict "Sheridan's Gambit" (DL4-06.fs2).

It seems you get this error with:
+ A build without compiler optimizations.
+ Facing a "complex structure" built with some ships that intersect themselves (the Lucy plus Docking Rings or the GTG plus Meson plus everything else in the Gorgon cannon).

So, I don't know what is causing this error when you don't have compiler optimizations but it has nothing to do with Lucy model itself.

Close it again...

edited on: 07-22-06 16:31

Issue History

Date Modified Username Field Change
2006-06-27 17:00 ARSPR New Issue
2006-06-27 17:00 ARSPR File Added: RC2 55 fps.jpg
2006-06-27 17:00 ARSPR File Added: RC3 25 fps.jpg
2006-06-27 17:01 ARSPR Note Added: 0005975
2006-06-28 11:32 kasperl Note Added: 0005981
2006-06-28 11:32 kasperl Severity feature => major
2006-06-28 11:32 kasperl Category --------- => gameplay
2006-06-28 17:15 taylor Note Added: 0005982
2006-06-28 17:15 taylor Status new => assigned
2006-06-28 17:15 taylor Assigned To => taylor
2006-06-28 20:44 taylor Note Added: 0005985
2006-06-29 17:12 ARSPR Note Added: 0005994
2006-06-30 18:37 ARSPR Note Added: 0006001
2006-07-06 16:20 ARSPR Note Added: 0006055
2006-07-08 13:00 taylor Note Added: 0006081
2006-07-09 03:22 taylor Note Added: 0006098
2006-07-09 08:59 ARSPR Note Added: 0006109
2006-07-09 09:51 ARSPR Note Edited: 0006109
2006-07-09 15:00 taylor Note Added: 0006115
2006-07-15 22:27 taylor Status assigned => resolved
2006-07-15 22:27 taylor Resolution open => fixed
2006-07-15 22:27 taylor Note Added: 0006190
2006-07-22 20:29 ARSPR Status resolved => feedback
2006-07-22 20:29 ARSPR Resolution fixed => reopened
2006-07-22 20:29 ARSPR Note Added: 0006296
2006-07-22 20:31 ARSPR Note Edited: 0006296
2006-07-22 20:33 taylor Status feedback => resolved
2006-11-01 04:54 taylor Resolution reopened => fixed