Triangles per second

I would do my best to infer the counts. As an example with per pixel processing I would add the number of pixels rather than incrementing once for each pixel. If you are doing some test in the loop then you may have no choice but to count, but if the loop builds a list then chances are you have the count already without adding in an increment. I make a habit of keeping counts of how many entries are in a data structure. If it is a tree then I also count how many leaves there are below a node. If you are just inserting at the start or appending to the end of a linked list then that degenerates into counting the entries, but with a BSP tree that can quickly tell you how many polygons are in front of the plane or behind it. Compared to adding a polygon to a BSP tree that is pretty trivial. The idea is to be as unintrusive as possible in the measurement process. Rather than navigating the entire sub tree just to count the entries maintain the count and use it. Rather than incrementing 4,096 times just add 4,096. Rather than add code to count the entries in an array use the count the code is already using to maintain the array.

Within this type of application I would most likely use a seperate thread to read the counters as well. Since you are just reading syncronization can be glossed over. If you are worried about it then you can lock the structure during the entire frame loop and have the monitoring thread only lock it long enough to copy it. You don''t need 100% accuracy so I wouldn''t worry about it. Also remember you don''t need to know what happened every microsecond interval. Once a second is most likely good enough for recording and ten times a second for finding max/mins will most likely catch anything the user notices. If you are displaying it to the screen instead of logging it to a file that doesn''t make much sense, but you should always have the option of logging to a file. I''ve done performance tuning for many years and monitoring does not beat tracking. You can track far more statistics and do a much more indepth analysis using a log than some text flashed on a screen. Matching up what you saw on the screen to a sampling profiler is inaccurate to say the least. If you can keep the maintenance of the counters to a minimum then turning on logging is just a matter of starting that thread rather than recompiling your program or constantly checking if a flag is set.

Sorry about that, most likely far more than you want to know about performance tuning in general and not much about your specific question. It''s just that performance is my speciality and I''m new to games.

Hehe, Blackstream, the previous post was probably more information than you needed to know, eh? (Kinda interesting, though) It sounds like you''re more curious about the methodology of counting polys, as opposed to implementation of the counting. I''m just BSing here, but I think your first suggestion is more likely: they pick "average-sized" tri''s, or maybe a range of typical sizes, and render a bunch. I say this because the people doing benchmarks are usually chip-makers or 3D engine developers; they''re not making a game, so they don''t have a "scene" to render "as normal". But I don''t think size is really that important for a poly-count benchmark. To measure per-pixel things, I think they have a separate benchmark called fill-rate or something.

Render as many random sized and colored triangles and count the number in one second.

---

Please state the nature of the debugging emergency.

sharewaregames.20m.com

if u talk about tris per second its all open to iterpretation. i remember some of the 3dfx cards talking about 6 milion tris a second. the small print was these tris r not actually drawn on the screnn . the nvidia guys talk a bout a tri being 25pixels big. me myself talk about tris in a scene in me program some big some are small just your ordinary scene ya know

http://members.xoom.com/myBollux