Hard Light Productions Forums
Modding, Mission Design, and Coding => The Modding Workshop => Topic started by: Nyctaeus on August 20, 2014, 05:55:22 pm
-
In short: What are the most popular reasons of in-mission lags or mistakes during modpack preparing? All that can slower game performance. I'm desperatly looking for what cause small lags in missions of mod I'm working on. I rid off all 4096x4096 textures, compress every texture to dds, removed every effect that is not needed and while our missions are smaller than in Shadow Genesis, game performance is much worse.
Our modpack is more than 2gb of stuff and there is everything here: Dozens of new models, textures, music... I'm kinda confused what may cause lags and I'm running out of ideas.
Yeah, this is one of the most important prolems of Mystery Project we have to deal with before beta-testing :P.
-
Well in my opinion just having too much stuff can cause lag, optimization of missions involving near BoE situations (only assuming that's what this Mystery Project will have based upon Shadow Genesis) can be very difficult, especially with high poly models and such.
As for mistakes, well, at least in my experience poor organization of files can create mistakes, just look at my Dusk Wars mod, up until what I'm working on now I had 0 organization skills and never prepared properly and I'm paying the price for it. However this was causing show stopping bugs not slowing performance, I'm not quite sure what can slow a game's performance beyond what Blue Planet has learned* and what I said above.
I'm sure someone with more modding experience then myself could shed some light :D
*Poorly optimized Karuna
-
Mystery Project is something independent than SG, but not less ambitious. There are a few bigger missions, but not as big as in SG. Actually there are no Karuna-like things as I'm making my models friendly for the game engine :). Low count of textures per model [similar to Scylla and Evangelist] and nothing bigger than 2048x2048 etc. We have Hi-Res textures prepared, but I actually don't have enough decent PC for something like this. I even removed AnimGlows and MV_Advanced for better performance with almost no effect.
Organization is actually not the problem too. Modpack is pretty well organized. All models and tables have proper filenames. I'm keeping things like this clean.
I'd rather want to know what can cause lags from technical point of view... Other than way too big missions :P.
-
How frequently are events being called in missions and how much scripting are you running, and again how often as these can quickly sneak up on you overhead wise
-
While it is mostly intended for the coders, you could try the launcher flag "Profile Engine Subsystems" which will add a display to the HUD showing where most of the CPU time is being spent. That may point you in the right direction.
-
Check for every-time events - more than a few of them will eat the CPU with great rapidity.
-
That's what I wanted. These are good points to start. We will try everything out. Thank you guys.
More suggestions are still welcome :)
Edit: I checked "Profile Engine Subsystems" flag. Post Move and Page Flip have pretty high value [10+] but Render has highest amplitude [52 was the highest]. Game render a lot of things so I'm still not sure what exactly cause problems.
Edit2: What is this?
Assert: bmp->bpp == 8
File: bmpman.cpp
Line: 1215
ntdll.dll! KiFastSystemCallRet
kernel32.dll! WaitForSingleObjectEx + 67 bytes
kernel32.dll! WaitForSingleObject + 18 bytes
fs2_open_3_7_1_NO-SSE_20140818_r11009-DEBUG.exe! <no symbol>
fs2_open_3_7_1_NO-SSE_20140818_r11009-DEBUG.exe! <no symbol>
fs2_open_3_7_1_NO-SSE_20140818_r11009-DEBUG.exe! <no symbol>
fs2_open_3_7_1_NO-SSE_20140818_r11009-DEBUG.exe! <no symbol>
fs2_open_3_7_1_NO-SSE_20140818_r11009-DEBUG.exe! <no symbol>
fs2_open_3_7_1_NO-SSE_20140818_r11009-DEBUG.exe! <no symbol>
fs2_open_3_7_1_NO-SSE_20140818_r11009-DEBUG.exe! <no symbol>
fs2_open_3_7_1_NO-SSE_20140818_r11009-DEBUG.exe! <no symbol>
fs2_open_3_7_1_NO-SSE_20140818_r11009-DEBUG.exe! <no symbol>
fs2_open_3_7_1_NO-SSE_20140818_r11009-DEBUG.exe! <no symbol>
fs2_open_3_7_1_NO-SSE_20140818_r11009-DEBUG.exe! <no symbol>
fs2_open_3_7_1_NO-SSE_20140818_r11009-DEBUG.exe! <no symbol>
fs2_open_3_7_1_NO-SSE_20140818_r11009-DEBUG.exe! <no symbol>
fs2_open_3_7_1_NO-SSE_20140818_r11009-DEBUG.exe! <no symbol>
fs2_open_3_7_1_NO-SSE_20140818_r11009-DEBUG.exe! <no symbol>
fs2_open_3_7_1_NO-SSE_20140818_r11009-DEBUG.exe! <no symbol>
fs2_open_3_7_1_NO-SSE_20140818_r11009-DEBUG.exe! <no symbol>
fs2_open_3_7_1_NO-SSE_20140818_r11009-DEBUG.exe! <no symbol>
fs2_open_3_7_1_NO-SSE_20140818_r11009-DEBUG.exe! <no symbol>
fs2_open_3_7_1_NO-SSE_20140818_r11009-DEBUG.exe! <no symbol>
fs2_open_3_7_1_NO-SSE_20140818_r11009-DEBUG.exe! <no symbol>
fs2_open_3_7_1_NO-SSE_20140818_r11009-DEBUG.exe! <no symbol>
fs2_open_3_7_1_NO-SSE_20140818_r11009-DEBUG.exe! <no symbol>
fs2_open_3_7_1_NO-SSE_20140818_r11009-DEBUG.exe! <no symbol>
kernel32.dll! BaseThreadInitThunk + 18 bytes
ntdll.dll! RtlInitializeExceptionChain + 239 bytes
ntdll.dll! RtlInitializeExceptionChain + 194 bytesIt appears on debug build when game try to open the briefing.
-
If render is really high then I'd guess that checking your models would be a good idea. i.e. what's the polycount for each? How many textures each, just one UVMap? And how many ships are present in the mission when you have the performance issues? I should say that these are mostly guesses as the rendering part of the FSO engine isn't my strong point...
As for the assert you triggered, you should put the .map and .pdb files (from the nightly zip archive) in your FSO directory and then reproduce the issue. That'll give useful info in the stacktrace about where in the code the assert is being triggered.
Lastly you should probably use the SSE2 binary unless you've already tried it and it causes issues, as every x86 CPU made in the last 10 years supports SSE2.
-
extremely hi-poly models == very expensive collision detection, but not a permanent drain
trails and particle effects == massive fps drain when a lot are present. even off-screen.
-
extremely hi-poly models == very expensive collision detection, but not a permanent drain
trails and particle effects == massive fps drain when a lot are present. even off-screen.
Will there be any coding solutions to these things in the future? Especially the off-screen particles thing, since I'd wager that those take a big chunk of processing power.
Same happens with shadows, in my experience. We've been spending the last years upping the polycounts of what we do, and now it is a problem with shadows.
-
Particles could probably be batched somehow (not sure if it's possible for animated particles where every frame is a separate texture), and it sounds like a good idea to add some collision detection options to, for example, use the current visual LOD for collision detection as well (as opposed to always using LOD0).
There will be solutions if someone writes them. Otherwise, not so much.
-
or make a non-hacky way to create collision meshes and add something else, like a submodel flag, to mark that submodel as "shadowable" or not. or something. half-baked idea.
-
Particles could probably be batched somehow (not sure if it's possible for animated particles where every frame is a separate texture), and it sounds like a good idea to add some collision detection options to, for example, use the current visual LOD for collision detection as well (as opposed to always using LOD0).
There will be solutions if someone writes them. Otherwise, not so much.
Particles are already processed in batches.
-
Actually some missions have more ships than usual. A few missions are in similar sizes as Delenda Est and they were quite laggy. Most of the models we have are hi-poly and with 2-3 2048x2038px textures. For example main frigate of player's faction has 115k polys, but I excluded it as a reason of lags. God bless detailboxes, which consists most of it's details. We have only a few tilemapped models.
A direct reason of low framerate were of course particles. I was aware that large amount of particles may render the FPS count low, so I reduced pspew-based weapons to minimum. But of course I'm retarded and ignored the explosions which are also particles [right?].
I have to make more tests. Expect me asking more questions, folks :)
-
Actually some missions have more ships than usual. A few missions are in similar sizes as Delenda Est and they were quite laggy. Most of the models we have are hi-poly and with 2-3 2048x2038px textures. For example main frigate of player's faction has 115k polys, but I excluded it as a reason of lags. God bless detailboxes, which consists most of it's details. We have only a few tilemapped models.
A direct reason of low framerate were of course particles. I was aware that large amount of particles may render the FPS count low, so I reduced pspew-based weapons to minimum. But of course I'm retarded and ignored the explosions which are also particles [right?].
I have to make more tests. Expect me asking more questions, folks :)
from memory, flak, possibly? especially if its rapid-fire.
-
Everything. I changed all the explosions in my mod because I'm not quite a fan of explosions in MediaVPs, and completly ignored the tact, that my alternate explosion is 512x512px, has alpha channel and 47 frames. Overall of weapons killed my FPS in seconds.