Troubleshooting random crashes

Expanding and utilizing the engine via C++.
43 posts Page 4 of 5
PaulWeston
Posts: 143
Joined: Thu Apr 23, 2015 7:16 pm
by PaulWeston » Wed May 27, 2015 4:32 pm
Running Windows 7 home premium 64-bit on all machines at home. At work it's windows 7 professional or enterprise or whatever. Only difference really is amount of ram, home machines have only 4 and work has 8. Home machines even all have after market video and rate between 5.9 and 7.1 in the performance index. Other new games are fine.

So ya its weird lol. But at least that fixes it.

As for the low FPS, my machine is actually the slowest in the house, kids got the quad cores and mine is just an old dual core refurb. Good video card though. But i always get low FPS.

Its kind of decieving though, its actually playable at that speed and is not as choppy as one would think.

What do you mean by profiling? I'm curious :) we are not open source but for you guys I could provide a build for r&d if you like.
buckmaster
Steering Committee
Steering Committee
Posts: 321
Joined: Thu Feb 05, 2015 1:02 am
by buckmaster » Thu May 28, 2015 2:31 am
By profiling I mean enabling the profiler to see which parts of the code are taking the most time. See if there are any particular bottlenecks.
PaulWeston
Posts: 143
Joined: Thu Apr 23, 2015 7:16 pm
by PaulWeston » Thu May 28, 2015 3:10 am
That would be great to know... Is that something I can do myself?

Maybe it's just that I have a lot of script stuff going on all the time, and that I am running on dual core with 4 gigs. I will know more tomorrow when I am at my colleague's using a 6-core 8 gb machine what the performance difference is.

Would be happy to provide everything for testing if need be. It would be big though - engine code is not bad of course but game folder is 1.4 gigs zipped, there is a lot of stuff :)
buckmaster
Steering Committee
Steering Committee
Posts: 321
Joined: Thu Feb 05, 2015 1:02 am
by buckmaster » Thu May 28, 2015 10:36 am
If you hold down ctrl F3 for a little while the profiler will dump a sample. It'd be very interesting to see what results you get!
PaulWeston
Posts: 143
Joined: Thu Apr 23, 2015 7:16 pm
by PaulWeston » Sun May 31, 2015 6:19 pm
Wow, cool, have never seen this before :)

At a glance, I don't see anything particular that is caught in a loop or anything. But maybe you can tell me a bit more about what it going on.

Some notes:

- I put the zones and portals back in, because now with 64-Bit they no longer seem to add to the crashing problem I was having before... I do still have some issues with the portals, they seem to be revealing more than I think they should, when you look at that direction even if you are looking through walls. But with zones back in I gained a lot of FPS on my dual-core system.

- I also set it up so when you are in the saucer section, it completely removes the lower hull decks, and vice-versa. When you move from one to the other, it plays a short turbolift video animation while it takes the 10 seconds or so to load in all the decks again. So when the turbolift door opens, the deck is loaded there for you. This also gained a lot of FPS.

So now on my dual-core system with only 4 gb ram, I can average 15-25 FPS in most areas (drops to 5-10 when loading stuff, then comes back up). With that, the game becomes viable even on older systems.

I did 20 seconds or so of profiling for this. Have attached the file to this post.

Thanks!
P

Attachments

profilerDumpToFile127904.zip
(16.42 KiB) Downloaded 69 times
andrewmac
Posts: 295
Joined: Tue Feb 03, 2015 9:45 pm
 
by andrewmac » Mon Jun 01, 2015 3:20 pm
For those too lazy to download and open the file, here's the top items:

%%NSTime %% Time Invoke # Name
889301.429 1412807.143 2966895 GenericConstBufferLayout_set
556268.571 556508.571 1168668 AdvancedLightManager_GetLightingShaderConstants
523953.810 523953.810 1100303 String_String_constructor
496644.762 503736.190 1057846 ShapeBase_ProcessTick
493198.571 523505.714 1099362 GFXD3D9ShaderBufferLayout_setMatrix
428440.000 428440.000 899724 FeatureSet_hasFeature
374434.286 374434.286 786312 RenderBinManager_setupSGData
247898.571 249967.143 524931 LightManager_Update4LightConsts
224756.667 228688.571 480246 ProcessedShaderMaterial_SetShaderConstants
223342.381 223342.381 469019 ProcessedShaderMaterial_stepInstance
221014.286 228688.571 480246 ProcessedShaderMaterial_SetTextureTransforms
211990.952 211990.952 445181 VectorResize
184622.857 184622.857 387708 SceneCullingState_isOccludedByTerrain
134128.571 134128.571 281670 String_default_constructor
133589.524 133589.524 280538 GFXD3D9ShaderConstBuffer_activate_dirty_check_1
130927.619 236888.571 497466 GFXDevice_updateStates
107886.190 241475.714 507099 GFXD3D9ShaderConstBuffer_activate
106340.476 106340.476 223315 GFXD3D9VertexBuffer_unlock
105960.952 105960.952 222518 GFXD3D9StateBlock_Activate
103763.333 103763.333 217903 GFXD3D9Device_findVBPool
buckmaster
Steering Committee
Steering Committee
Posts: 321
Joined: Thu Feb 05, 2015 1:02 am
by buckmaster » Tue Jun 02, 2015 10:22 am
There are some very interesting results there. String? isOccludedByTerrain?
PaulWeston
Posts: 143
Joined: Thu Apr 23, 2015 7:16 pm
by PaulWeston » Tue Jun 02, 2015 2:58 pm
IsOccludedByTerrain is in scene/culling/sceneCullingState.cpp, in the function:

U32 SceneCullingState::cullObjects

And the String bit appears to be from core/util/str.cpp:

String::String()
{
PROFILE_SCOPE(String_default_constructor);
_string = StringData::Empty();
}

They are part of the stock engine code I'm pretty sure, I didn't add them, is there a reason we should not be seeing those?
andrewmac
Posts: 295
Joined: Tue Feb 03, 2015 9:45 pm
 
by andrewmac » Tue Jun 02, 2015 6:03 pm
The list you're seeing is listing, from the top, the functions that are called the most and/or taking the most time. The point of looking at the profile is to figure out whats taking so long so you can try to reduce that particular item.

Seeing IsOccludedByTerrain seems odd because you don't have any terrain. And String::String() is odd because why is the engine spending so much time allocating strings? It almost seems like you're creating new strings every frame for some reason. Is there anything you can think of that's occuring per-frame that creates a new string? It may also be coming from torquescript.
PaulWeston
Posts: 143
Joined: Thu Apr 23, 2015 7:16 pm
by PaulWeston » Tue Jun 02, 2015 6:17 pm
Hmm, that's interesting for sure...

The scene is full of zones, so maybe part of having zones in there causes it to run through every possible occlusion method, including terrain? Agreed that I do not have terrain in there at all so why would that need to be checked, at least in this mission - I do have a mission with a Cestus III terrain and the Vasquez rocks where you can go fight some Gorn, but that wasn't what I used to do the profiling.

As for the String stuff, I'm not sure... I do a lot of command to client and command to server back-and-forth in my TorqueScript, doesn't that use tagged strings and such flying back and forth? Other than that I don't know what else I'm doing that is out of the ordinary.
43 posts Page 4 of 5

Who is online

Users browsing this forum: No registered users and 1 guest