ive an app, which is singlethreaded, and uses window messages as shown for drawing:
…
case WM_PAINT:
//draw scene
return 0;
//but this isnt the problem, because i can place the draw command somewhere else, or repeated per wm_paint and i dont get more fps
the problem is, i get only 25 fps @ 20.000 triangles/vertices textured, not light, culling enabled … that are 0.5MTris/Sec, i know i should have more than 10times more
and after profiling i found that the biggest part my app spends is the one function which set vertexpointer, texcoordpointer, normalpointer and then calls glDrawElements. When i skip drawing these objects i get about 700and more fps …
is there something ive done wrong, should i use NV-Ram (if so, how do i do it, all tutorials i have are not clear in this point)
or is my Geforce 2 GTS against me/developers ??? Games i have are running fine, except Giants …
you don’t have to specify the vertex/color/texture/index pointers every frame.
just call glDrawElements.
if your indexes are in consecutive order (0, 1, 2, 3, 4, 5, …) like for tri-strips or loose triangles, that don’t share any vertices, it’s cheaper to use glDrawArrays
i get about 5 million tps with my geforce using plain glDrawElements (~ 130k tris per frame)
perhaps locked vertex arrays may increase your performance, but it didn’t work for me ):
its not so easy, because i have mutliple objects, each has its own arrays, and i cannot use tristrips … maybe i should use one huge array, and copy the data from the arrays to prevent calls to glpointer …, i will try this …
It’s perfectly common to have one vertex array per object. Changing the pointers every time shouldn’t slow you down that much. To check, you could comment out the glDrawElements() call but not the gl*Pointer() calls.
Also check if you don’t have some other setting enabled that might cause the slowdown. Too much overdraw, FSAA or anisotropic filtering might make your app fillrate-limited, for example.
i will try it( Tom Nuydens ), but currently im not able to do so…
and i have another idea: maybe it is something with texturing, because i use linear min and mag filters instead of mipmaps … but my textures (i use glBind … ) are not very big, max of 256^2, i’ve to check out how the texcoords from the objects are …
Our friendly local NV guys have gone on record several times as saying that the perf FAQ is obsolete, and that current drivers aren’t so picky about vertex formats.
Ok, i think i’ve found something interesting:
ive additional views in my app, of which one draws an wireframe(textured …, 500k tris/sec). if i disable this view i get about 3M tris/sec, but not more, disabling other views increases only frame-rate of the mainview (but still 3mtris/sec) …
Switch off different things such as texturing and see when tps is going up. I’ve expierienced some performance problems when drawing wireframes as well, don’t know why though… With untextured tris I’m able to draw around 5 Mtris/sec, if I use GL_LINES I get less than half!
Originally posted by dbugger: With untextured tris I’m able to draw around 5 Mtris/sec, if I use GL_LINES I get less than half!
Most consumer hardware is horribly inefficient at line drawing. Typically, each “line” is actually being drawn as multiple thin triangles… sometimes as many as 10, by some rumours I’ve heard.
ive additional views in my app, of which one draws an wireframe(textured …, 500k tris/sec). if i disable this view i get about 3M tris/sec, but not more, disabling other views increases only frame-rate of the mainview (but still 3mtris/sec) …
If you aren’t using NV_vertex_array_range (or CVA’s), 3M is a pretty reasonable number.
