Umm... Quake, and Quake II (and so will Quake III) use BSP trees. Half-Life licensed Quake II engine, which means, Half-Life uses the same thing--BSP trees.

Quake II uses OpenGL mainly, or if there is a 3Dfx Voodoo card present, then it uses 3Dfx Mini-GL Driver to do the rendering (since there is no OpenGL ICD yet for 3Dfx Voodoo's... I think).

And, the reason why its so fast, is because it uses only a part of the OpenGL. On the other hand, Unreal is so slow because of its beatiful special fx. Not that Quake II is nothing, I could *never* do such a master-piece, but it is fast because its limited.

Hmm... what type of a computer and configuration do you have? You can't really expect much on a low-end system--any Pentium first generations really. I would say second generation CPU's are the bottom line these days.

Also, are the polygons texture mapped or gouraud shaded? Any special FX enabled? (Alpha Blending, Anti-Aliasing--this is a killer, Depth cueing)? Fog is good to have--especially in Landscape stuff, but it does have a good effect on the frame rates.

Also, are you enabling back-face culling? If not, that could really help--especially in landscape apps.

- prauppl

Hi,

first thanks for your fast reply
I´ve a PII 450, a Elsa Erazor II (TNT), 256 MB SDRAM. My Engine does at 1000 Polys only 40 fp/s.
Alphablending is only activated when the player shots ...my Engine uses hardware-acceleration through direct3d, too.
All polygons have their own SetTexture (); -Calls. This means, that every polygon will be drawn with it´s correct texture. And every polygon will be draw through its own DrawPrimitive (); -Call.

But what I´m making wrong?

Andy

------------------
-------------------------
Andrew
Lead Programmer
UNITED BYTES, GERMANY
andy@unitedbytes.de
-------------------------

Hi,

Hm... your system is very good. I don't know whats wrong. Are you in full screeen mode? If you are, the video cards "synchronize" to a specific fps. If you are in windowed mode however, the fps seem to be limitless!

So, the polygons *are* visible, but the problem is that you need to make your program faster?

- prauppl

I'm no expert on 3d graphic programming, but I've read that it is always best to group polygons that have the same texture so that you don't have to call SetTexture 1000 times a frame. Also try to call the groups with DrawIndexedPrimitive, because that will avoid some overhead. Hope this helps.

My engine runs in fullscreen mode.
What´s about DrawIndexedPrimitive? Where are the changes between DrawPrimitve and DrawIndexedPrimitive? How does the other engines (Quake or Unreal) do their poly-drawing? Are there any documents or tutorials on the web about optimizing direct3d or general 3d?

Andrew

------------------
-------------------------
Andrew
Lead Programmer
UNITED BYTES, GERMANY
andy@unitedbytes.de
-------------------------

Yeah, It sounds like state changes are killing your app. Also, try and use things like triangle strips whenever you can -- I know I tripled the framerate of my opengl landscape renderer when I started using them!

--TheGoop

Well, I never tried DrawIndexedPrimitive, but it is different from DrawPrimitive() in the way your pass the vertices to be rendered. In DrawPrimitive, you pass number of vertices to be RENDERED and the pointer to the primitive structure.

But, in DrawIndexedPrimitive, you send TOTAL number of vertices, number of vertices to be RENDERED (just like DrawPrimitive) a pointer to the MASTER vertex list, AND a pointer to unsigned shorts that are the *indices* for the vertex list. The indices specify the vertices for your polygons in the master vertex list.

There is no difference I see--as long as you're careful, why you need to use DrawIndexedPrimitive instead of DrawPrimitive. I never used the indexed primitive, but D3D docs sound like its useful when you have indices to vertices of a figure in an array... which is generally not the case. You usually setup a triangle with 3 vertices, one right after the other...

In other words, they are not *seperated* with a vertex from another geometric figure after a vertex of yet another geometric figure... Meaning:

T_Vn = Triangle vertex 'n'
Q_Vn = Quad vertex 'n'

T_V1
T_V2
Q_V1
T_V3
Q_V2
Q_V3

However, I am not *totally* sure about this, if someone finds me wrong, or see that my thinking is different, please tell me... however, I am pretty sure that the above is correct...

- prauppl

I am almost sure that you need to use DrawIndexedPrimitive. It works much nicer, you can save the vertex data, and the index data separate, and then when you render, you only call one function per group of triangles. This cuts back on 10,000 pushes and pops everyframe, not to mention any other overhead the D3D does for each DrawPrimitive.
I didn't understand what you were talking about with the *seperate* part, but using DrawIndexedPrimitive lets you draw triangle that share vertices, and ones that don't...for instance:

Here are my vertices:
V0, V1, V2, V3, V4, and V5.
now my indexes could look like this:
0,1,2,1,2,3,2,4,5

That would draw 3 triangles...and you would only have to pass D3D 6 Vertices.

Also think about drawing a cube...you only have to pass the 8 verts...and the indexes. Instead of passing more verts that are in the same location.

I´ve put my engine with screenshots, info and other stuff on my website
So you can see what my engine can (or cannot) do.

The url is: http://www.unitedbytes.de

-Andrew

You made it all clear for me Pseudo. Thanks. :-) I see now... DrawIndexedPrimitive() *is* faster than DrawPrimitive() because you can draw many of the *same* geometric figures (say triangles)... I was thinking it was when you have one BIG array of D3DXXVERTEX structures, which segmented vertices data...

Sorry about that. :-) And, btw, just wanted to say that the UB's screenshots were pretty cool!

- prauppl