How to find bottlenecks
Author
How do you guys find bottlenecks in your DX games?
I tried VTune but it looks like some important functions are disabled on my machine because I have a non-intel (K6-2) CPU.
Oooh, that''ll teach you to go for Genuine Intel next time...
Well anyhow, I know on the x86 cpu''s (Again, not sure if AMD supports these features) have 8 debug registers you can use yourself to output information and such. A nice thing I saw here on gamedev was an article on Serious Debugging with Dual Monitors and Win98, I''ve just started this right now, haven''t encorporated code yet, but the idea is that while your game is running full screen on your main monitor you can write loop times and fps and all that kind of info to the other screen in text mode. Seems like a good idea....
See ya,
Ben
P.S. Oh yah you wanted to know how we do it! I use a process of elimination, I have a main game loop which calls functions like PaintTerrain, ProcessUnits, PaintUnits, ProcessObjects, PaintObjects, ProcessMouse, PaintMouse, etc.... So I can just pull out one function at a time and compile and see how it affect the fps... Seems to work good..
Well anyhow, I know on the x86 cpu''s (Again, not sure if AMD supports these features) have 8 debug registers you can use yourself to output information and such. A nice thing I saw here on gamedev was an article on Serious Debugging with Dual Monitors and Win98, I''ve just started this right now, haven''t encorporated code yet, but the idea is that while your game is running full screen on your main monitor you can write loop times and fps and all that kind of info to the other screen in text mode. Seems like a good idea....
See ya,
Ben
P.S. Oh yah you wanted to know how we do it! I use a process of elimination, I have a main game loop which calls functions like PaintTerrain, ProcessUnits, PaintUnits, ProcessObjects, PaintObjects, ProcessMouse, PaintMouse, etc.... So I can just pull out one function at a time and compile and see how it affect the fps... Seems to work good..
I use the profiling stuff available with Visual C++ 6. It helps determines which functions are being called the most and how much time is spent in them. Also, disabling a feature and seeing how much that helps is another way I find bottlenecks.
On the subject of streamlining DirectX/3D programs, i'm having problem with a D3D program i've written (download at http://members.xoom.com/simon9987/index.htm).
In 640*480 it runs at 86 fps (theoretical maximum of 90 because of monitor refresh rate) which is obviously quite fast, but when I switch to 1024*768 the frame rate drops in a really strange way.
Depending on where you are pointing (it's first-person) the frame rate will either be 86 fps or 43 fps BUT never anything in between! I've checked and it doesn't seem to relate to the number of visible polygons, and the whole level is only 500 polygons anyway.
Does anyone have any ideas?
Also, sort of on the same subject, can someone tell me whether the standard edition of Visual C++ is a lot slower than the professional version for using DirectX/3D?
Many thanks,
Simon.
Edited by - simon_brown75 on June 7, 2000 8:16:27 PM
In 640*480 it runs at 86 fps (theoretical maximum of 90 because of monitor refresh rate) which is obviously quite fast, but when I switch to 1024*768 the frame rate drops in a really strange way.
Depending on where you are pointing (it's first-person) the frame rate will either be 86 fps or 43 fps BUT never anything in between! I've checked and it doesn't seem to relate to the number of visible polygons, and the whole level is only 500 polygons anyway.
Does anyone have any ideas?
Also, sort of on the same subject, can someone tell me whether the standard edition of Visual C++ is a lot slower than the professional version for using DirectX/3D?
Many thanks,
Simon.
Edited by - simon_brown75 on June 7, 2000 8:16:27 PM
I've noticed that myself on a project I'm working on, and I think it has to do with the amount of textures being drawn, in your case I'd guess 1 for each square of wall and floor, or for me, 1 per square of the terrain.
Do you have a version using blt I could look at? I'd love to narrow down the problem.
Edited by - jLeslie on June 7, 2000 8:27:02 PM
Do you have a version using blt I could look at? I'd love to narrow down the problem.
Edited by - jLeslie on June 7, 2000 8:27:02 PM
Does it happen in a particular location all the time? The only things I can think of is a memory issue, where you have to start paging out to disk. (Hey I know its unlikely, but you never know)
The other is are you sure that you are getting the frames right, like is it jerky under certain circumstances or does the text that displays the frame rate just drop.
Another thing is, do you ever skip updating the frame rate, say you get an error one time through, maybe you just pass by and don''t refresh and the next time, it does?
I''m just throwing darts in the dark. Some people call that the good part of programming, I think they are nuts.
The other is are you sure that you are getting the frames right, like is it jerky under certain circumstances or does the text that displays the frame rate just drop.
Another thing is, do you ever skip updating the frame rate, say you get an error one time through, maybe you just pass by and don''t refresh and the next time, it does?
I''m just throwing darts in the dark. Some people call that the good part of programming, I think they are nuts.
Potsticker gots the beginning of the solution. It has nothing to do with the resolution or the amount of texture memory, but to your screen''s vertical synchronization.
I''ll try to explain it simply: since you are using double-buffering, a frame can only be displayed every 1/90 sec. You''ll get 90 fps (or almost) if to display your frame you need less than 1/90 sec.
Now..imagine you need more than 1/90 sec to display a frame. When the "top" will occur, you''ll still be working on it. It''ll have to wait the next "top" to really display it. And that''ll happen 2* 1/90 = 1/45 sec. after you''ve started. Which explains the 45 fps (or almost) you got later.
How to fix it ?
1. Disable vertical synchronization/do not use full-screen.
2. Or use triple-buffering.
Y.
I''ll try to explain it simply: since you are using double-buffering, a frame can only be displayed every 1/90 sec. You''ll get 90 fps (or almost) if to display your frame you need less than 1/90 sec.
Now..imagine you need more than 1/90 sec to display a frame. When the "top" will occur, you''ll still be working on it. It''ll have to wait the next "top" to really display it. And that''ll happen 2* 1/90 = 1/45 sec. after you''ve started. Which explains the 45 fps (or almost) you got later.
How to fix it ?
1. Disable vertical synchronization/do not use full-screen.
2. Or use triple-buffering.
Y.
Thanks for the help everyone. When I turn off v-sync the frame-rate is much more variable and seems to depend much more on the amount of polygons visible, which confirms that the problem is indeed that the program is taking >1/90th of a second (when the frame-rate drops to 43) to draw a frame as Ysaneya said.
Looks like time for some trippple buffering. Presumably with v-sync on tripple-buffering should take the frame rate up into the seventies, but this still seems slow to me. My ''engine'' is only drawing about 450 polygons.
I was reading the feature list for the Standard and Professional editions of Visual C++ 6 (I have the standard edition), and the standard edition doesn''t have code optimization. I was wondering if anyone knows what sort of speed increase I would get with the professional edition?
Thanks again,
Simon.
Looks like time for some trippple buffering. Presumably with v-sync on tripple-buffering should take the frame rate up into the seventies, but this still seems slow to me. My ''engine'' is only drawing about 450 polygons.
I was reading the feature list for the Standard and Professional editions of Visual C++ 6 (I have the standard edition), and the standard edition doesn''t have code optimization. I was wondering if anyone knows what sort of speed increase I would get with the professional edition?
Thanks again,
Simon.
Hi
I am not using the Visual C++ Compiler for my game, but it should be the same type of opt. that the Watcom does, and there only the selfmade code gets optimized, all the DirectDraw and D3D Stuff is allready compiled with maximum Performance (i hope microsoft enabled them
).
And if you don't have any Code parts that takes many cycles like an highly detailed physics Engine or something like that, the optimizations shouldn't bring any big advantages.
And for finding Bottlenecks, i am using the Profiler to discover those little Code Parts the consume so much time. And i also try to make all the Features variable, so that i can enable and disable them in runtime (Also very good for an good filled options Menu, i love those games very you can change hundreds of Parameters)
Lars
Edited by - Lars W. on June 8, 2000 7:20:44 AM
I am not using the Visual C++ Compiler for my game, but it should be the same type of opt. that the Watcom does, and there only the selfmade code gets optimized, all the DirectDraw and D3D Stuff is allready compiled with maximum Performance (i hope microsoft enabled them
).And if you don't have any Code parts that takes many cycles like an highly detailed physics Engine or something like that, the optimizations shouldn't bring any big advantages.
And for finding Bottlenecks, i am using the Profiler to discover those little Code Parts the consume so much time. And i also try to make all the Features variable, so that i can enable and disable them in runtime (Also very good for an good filled options Menu, i love those games very you can change hundreds of Parameters
)Lars
Edited by - Lars W. on June 8, 2000 7:20:44 AM
Of course, the D3D code is all pre-compiled in .dll''s. Thanks for that, i''ll have to do some experimenting to see where the speed is all going, but it sounds like I don''t need to spend £400 on the Pro Edition.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
