Weird problem -- DX game goes faster with more polygons on scene...
Author
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?
Well it sounds as though you havnt' disabled synchronisation with your screens refresh rate.
Try that.
ace
Try that.
ace
Author
No, that's not it. In fact, v-sync IS disabled. And anyway, v-sync wouldn't explain this strange behavior.
It might be a case of your video card being more efficient at handling the bigger render batches than the smaller ones.
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
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
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 (<
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 (<
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
