MH's Direct3D 8.1 Wrapper

[Baker]

[Baker]

[mh]

[Spike]

[mh]

[mh]

A note on performance and other characteristics of the wrapper

Direct3D is very sensitive to primitive batching. Previous versions of this wrapper (pre April 2010) didn't attempt to batch at all, and performance suffered as a result. In April 2010 I rewrote it to use batching everywhere, detecting state changes as they happen and beginning a new batch on every state change.

All batches use indexed primitives with 16-bit indexes and the triangle list primitive type, except for if the requested OpenGL primitive type is GL_TRIANGLES, in which case it will use an unindexed triangle list. Strips and fans don't exist in it at all.

In many cases this will get performance that comes close to (or occasionally exceeds) OpenGL (which seems to batch up polygons internally within the driver), but it's dependent on the data that it's fed. If it's given polygons that are not grouped by state (the worst offender is R_DrawSequentialPoly or anything similar to/derived from it) it won't be able to batch them, and we get performance drop off.

A further optimization would be to detect if hardware T&L is available and use a dynamic vertex buffer if so. This is the approach used by DirectQ, which batches very agressively, and is able to draw the entire first scene of start.bsp, including the status bar, in 24 draw calls. It may not be viable for use with the wrapper as feeding a dynamic vertex buffer with polygons that aren't grouped by state will slow things down further. Some reworking of the surface refresh (especially getting rid of R_DrawSequentialPoly - a thing of true evil - and grouping bmodel surfs by texture) would be definitely required before it would be worthwhile doing this. Alias models and everything else are probably OK to leave as they are, but GLQuake's default surface refresh (especially the multitexture path) is embarrassingly suboptimal, even for OpenGL.

The wrapper supports a subset of baseline OpenGL 1.1 (similar to the old 3DFX mini GL) with some extensions available. Multitexture is exported, but combine modes are not. This isn't because D3D can't do combine modes (it can, and it's API is considerably more sensible than OpenGL here) but rather because the OpenGL API introduced a heavy layer of complexity in implementing them which caused other things to break.

It doesn't attempt to do much in the way of parameter validation, assuming that your OpenGL code is at least reasonably correct to begin with. I'm not sure if this was a wise decision but it certainly helped to speed up the development process. It does mean that you should test and confirm correct operation using native OpenGL rather than relying on this, however.

[Baker]

[mh]

[Baker]

[mh]

[Baker]

[Spike]

[mh]

[Baker]

[Baker]