Sunday, June 21, 2009

An OpenGL DirectQ?

This seems to be a time when crazy ideas come out, but it's just occurred to me that - given the degree to which I have now abstracted out a lot of the rendering in DirectQ - porting it back to OpenGL should not really be that difficult. I'm not going to do it, of course, but if anyone really wanted to, all of the rendering code now lives in the Effect class in d3d_hlsl.cpp; aside from that it's really just state changes, setup and texture loading elsewhere.

What would this give you? A port back to OpenGL wouldn't give you multiple platform support; there is just too much Windows API in DirectQ, well beyond what was in the original Quake. The sound code is exclusively DirectSound, the XInput and DirectInput code would need to go, and there have been some changes to the network code (to make it more happy with the new cvar system, primarily), meaning that you just can't drop in the original code files and expect it to work. The issue of porting to C++ would need to be addressed also; I don't think there was a single code file I didn't touch when doing this; if nothing else, switching from qboolean to bool would disrupt a lot.

But it could be an interesting thing for someone to do, and if anyone wants to take my code and port it back, or use it as the basis for a D3D implementation of their own Q1 engine, they have my blessing.

Meanwhile, I've come across a very good paper discussing differences between the two APIs in a pragmatic real-world setting; it's more focussed on CAD applications than on games, but a lot of it connects perfectly with my original reasons for porting to D3D. This extract sums the whole situation up very nicely.

When we use OpenGL, we have found over the past many years (and still today) that we need to invest in a large, significant amount of QA that simply verifies that the OpenGL graphics driver supports the OpenGL API on the level that we use (which is actually rather dated, to be consistent with OpenGL GDI Generic, from circa 1997). In spite of the fact that we do not use any new fancy OpenGL extensions and use OpenGL almost on the level of 1997 graphics HW technology, we routinely encounter OpenGL graphics drivers that do not work correctly and as a result, we have our extensive OpenGL graphics HW certification process which involves a serious amount of testing effort on our part that does not actually test Inventor, it merely tests the OpenGL graphics driver. In fact, we currently have 44 (and counting) OpenGL "Workarounds" that we can invoke in our OpenGL graphics layer to "workaround" various OpenGL graphics driver problems.

The opposite situation exists for Direct3D. If a Direct3D graphics driver is Microsoft WHQL (Windows Hardware Quality Lab) certified, then it works correctly as far as Direct3D itself is concerned. This is the purpose of the WHQL testing and certification suite at Microsoft, to enforce compliance with the Direct3D specification. No such process exists in the graphics community for OpenGL and the quality of OpenGL graphics drivers suffers greatly as a result. With Direct3D, our QA team can focus on testing _our_ code and finding defects in _our_ graphics code, instead of having to spend all their time just verifying that the graphics HW vendors have done their job correctly to produce an OpenGL graphics driver that actually works.
I'm not so sure about the "no such process exists in the graphics community for OpenGL" remark: there is conformance testing, after all; but I have personally felt for some time that OpenGL conformance testing is not as tight as it should be, perhaps to avoid antagonising a certain major GPU vendor who is known to produce poor OpenGL implementations? Whatever, I'm going to let it stand without further argument or comment.

You can grab the full thing here.

0 comments: