Sign in to follow this  

Weird problem -- DX game goes faster with more polygons on scene...

This topic is 4414 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, I'm having a strange problem in my current game and I'd like to hear your input. Here's what's happening: I load a scene consisting of around 16k triangles in my game. With some point lights added, the game runs at about 65 FPS (accoring to Fraps), but it isn't as fluid as it should be. It's like the game runs fine for a second, then hangs for a fraction, the goes fine again, then hangs, and so on. This is a bit strange, because the game is running at 65 FPS (not average) and that should be fluid enough. But that's not the weird part... What's really weird is that if I add some more polygons on top of the floor (these are decals, to simulate blood stains, etc.), then the game runs perfectly fluid!!! (Though the framerate is still around 65). So, to sum up: Adding some alpha-blended polygons to my scene (which should mean more processing due to sorting and blending) makes my game go much more fluid. How can this be possible?

Share this post


Link to post
Share on other sites
It might well be worth digging into PIX and/or respective IHV's profiling tools... you could well be CPU/GPU limited in some way.

It's a long shot, but it is possible that your GPU is CPU bound - such that any slow down on the CPU (e.g. the Anti Virus kicking in every few seconds) throttles the GPU temporarily.

Also, are you sure that VSync is disabled - disabling it in your code is pretty much just a hint these days; both ATI and NV hardware allows it to be overriden in the respective control panels - completely ignoring what you think you set it to [smile]

hth
Jack

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Look more like a fill rate problem. Clipping could also be helped a bit.

As the 3D engine rasterizes the large triangles making up the floor and the ceiling, the 3D transform engine is starving (i.e. it runs out of work as the rasterizer is fully occupied). When those large triangles finally finish rendering, the transform engine starts pulling vertex data in its pipe again. By breaking up large surfaces, you keep both the transform engine and the triangle rasterizer engine working in parallel.

You might also be overloading the clipping engine with large surfaces. HW clipping is designed to rapidly eliminate the trivial cases while spending more time building new triangles from the ones that were clipped and resubmitting them again to the rasterizer. When triangles are small and well-distributed, clipping is a rare occurence (<

Share this post


Link to post
Share on other sites
Check your timer, make sure that the time for the current frame is larger than the last (and/or check that your deltas are greater than zero), you should be able to check those with some simple asserts (and check the numbers you use to calculate stuff, ie if you convert the 64 bit int from QPC to a float and use that float to calculate a delta, put the asserts on the float and deltas instead of just the 64 bit int).

I'm not sure if this is your problem, but time delta's not being greater than zero can cause odd behavior (jerkyness whatnot). Which go away when the time per frame increases enough to keep delta > 0 (so adding some more stuff keeps the bug from poping up). I ran into a problem where someone was storing the time from QPC in floats, and using those floats to calculate the time delta. But due two consecutive times would sometimes be equal due to the loss of percision in converting to float. When the two times where subtracted a negative could come out of it (it would freeze the program in this case). Other things (flacky timer) could make the delta negative, so it's worth adding an assert for.

Or in short, put assert(timeDelta>0) somewhere in your game loop and see if the assert fails.

Share this post


Link to post
Share on other sites

This topic is 4414 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this