bottleneck in frame rate occurring

I wont post any code right now, but if you would like to see some, go ahead and tell me.

Here is my problem:

I am making a 3d Battletech game (many of you would probably better know it as Mechwarrior). Things were going pretty well until just recently.

I was getting about 60 fps with my terrain engine, which I considered quite nice.

Then I began to load in 3ds Max models into my game. Immediately my frame rate dropped to 10 fps (or lower).

I decided to take out the 3ds library for the time being, so I completely took it out, yet I am still getting the 10 fps I got when I loaded 3ds models, and not the 60 fps I got before I loaded in models...

Anyone had an experience like this and could shed some light?

Just a guess but sounds like your project file has gotten corrupted or something. I had something similar happen to me in MSVC. Ended up going through every module to make sure I had not changed the engine; created a new project; and just put the files in that project. It worked.

Weird thing was that the files were not altered at all when I created the new project so theoretically it should have worked the same in the old project. Very strange.

I'm not saying this is your problem, but I have run into this. I've also had MSVC break my good code and have to take the above steps to get it working again.

On a side note I've never had Borland compilers do this to me.

FPS is in the actual exe - which really doesn't have anything to do with the compiler (aside MAYBE its assembly compilation efficiency - which msvc is great at).

DavidP More then likely when adding your loader you've introduced something into your code that requires a lot of UMPH to do. You may have removed the 3ds related stuff, but you've probably forgot something you might have changed. Perhaps new extensions for lighting or enviornment mapping or anything really - theres no way to know with out knowing the code. I suggest you go over your code again, and remove or comment out everything not terrain related. Until your back to 60fps - then uncomment bits of it until you find the bottle neck.


good luck.

FPS is in the actual exe - which really doesn't have anything to do with the compiler (aside MAYBE its assembly compilation efficiency - which msvc is great at).

My point exactly. But the compiler did mess with my FPS - and I could not find out the reason so I started a new project with the exact same files and it fixed it.

augmenting what goten said, compiler shouldn't have much to do with the framerate drop. Instead of uncommenting parts of the code I personally leave everything in and count the time it takes to perform each cycle. That's called profiling your code. Say you want to find out what is causing yoru problems:

Code:

int main()
{
GatherInputs(); //1ms
PerformAI(); //2ms

unsigned int time = timeGetTime();
DrawScene(); //uh oh, 25ms, taking a long time
unsigned int difference = timeGetTime() - time; //gives amount of 
time that passed to draw the scene
}

You do that for every major component of your game, find out what part is taking the longest, then examine it more closely.
Say you want to know how long it takes to render the real polygons of the *world*:

Code:

void DrawScene()
{
     DrawStencilShadows();  //1ms
     DrawStencilReflections(); //1ms
     DrawMonsterModels(); //2ms
     DrawWorld() //25ms
}

Using that same idea you can break things down and find out exactly what went wrong. Note it only takes 16 and 2/3ms to render a single scene if you are going at 60frames per second

Just wondering, what are you using to build your terrain (what program) and what type of partitioning does it perform? I hope you aren't doing an unpartitioned terrain. If you are doing unpartitioned terrain there is little hope your fps will go at or above 60. Are you doing frustum culling, and if so how? (on a per polygon basis, on a per bounding box radius (for each leaf) ), does it have potential visibility sets?

Good sugestion S-cord:
augmenting what silver cord said about profiling your code, #define statements are very fun here.

you can use compiler statements to see if you compiled a debug version or a release version so you can effectively eliminate testing code with out having to scour through it and deleting it all when your finaly happy.

Stufl ike this:

Code:

#define COMPILE_DEBUG


#ifdef COMPILE_DEBUG
startTime = GetTickCount() // or timeGetTime if you prefer
#endif
// functions here
#ifdef COMPILE_DEBUG
displayViaTextMessageElapsedTime( GetTickCount()-startTime );
#endif

Seems like a lot of extra typing, but is a very useful tool for all your debug methods in large programming systems.

so basically take mine and goten's advice and narrow down exactly what is farking up your code, then we can tell you what is going wrong. I'm suspecting unpartitioned terrain, does 3d studio max do partitioning? I think Lightwave has a BSP thing, so I'd assume 3ds would too...

Or just use the profiler built in to MSVC... which is a lot easier.

i honestly didn't know there was one
how do you use it

EDIT: nvm i figured it out

davidp if you are on msvc:

go to Project->Settings

go to general

make sure enable profiling is checked

build your project

then go to build->profile

EDIT1: if you don't have the most up to date PROFILE.DLL installed it won't work (it is in the Bin directory of vc)

EDIT2: If someoen has a profile.dll that is more up to date than June17 1998 plz upload it (~92KB file)

What I'm saying is that the project file gets screwed up somehow. Not saying that this is DavidP's problem but it has happened to me. I've had a couple of projects in MSVC get corrupted for some reason which causes the code either to execute slowly or it causes the code not to execute at all. The problem is not in my code, its something else because the code has not been changed. I'm well aware that compilers have nothing to do with FPS - but if your project file gets waxed it can do strange things. Perhaps it is simply resetting all of the optimization options - which are local to your project or it is changing other options. Either way it does mess up the program.
I'm sure there is probably a patch or something for it or perhaps my version has a conflict with something else - but it has happened to me.