That’s right!, from now on htq2 will be using OpenGL directly, QGL only exists solely for the purpose of dealing with OpenGL extensions, all of this will be available for the 0.2 release!.
For those who still don’t know, QGL is the Quake GL system, an abstraction of the OpenGL subsystem used by the Quake II refresher. OpenGL functions and extensions are not called directly, instead, they’re called through analogous functions
glVertex3f). This brings up a question …
Why did QGL exist in the first place?
There are a bunch a reasons, those who’re obvious and those that I found while I was digging through it. Before I begin, I would like to tell you that what you’re about to read is only based on my own deductions, not actual facts, in fact, there is not much documentation about development chronicles and details for Quake II at 1996-1997, these are mainly theories (I want to really leave that clear). Back in around 1996, id Software (a.k.a. The Carmack Bunch) had certain issues around the ongoing development of the Q2 engine (not to mention OpenGL implementations immaturity at that time which led the development of the infamous
ref_soft implementation). The biggest issue around it was porting it to other platforms like those free-spirit Linux distributions, taking their particular OpenGL implementations in mind. The need of bringing up a binary who could easily link with virtually any OpenGL implementation without releasing/relinking any source code made the way for one solution: John Carmack (or someone else maybe) probably came to the conclusion that OpenGL was meant to be dynamically used at runtime, that means that the best way of using OpenGL was to take their function pointers (via
GetProcAddress on Windows or
dlsym on *nix) and then use them. It would be hard to implement but at the end of the day, the final user could easily switch his/her q2 binary to whatever OpenGL implementation had available on his/her OS by just setting the
gl_driver cvar on the command line, whether it was at
/usr/lib/libGL-mesa.so.4 or whatever. In that way, Q2 would still depend on OpenGL but without having the resulting binary tighten up (linked) with a specific OpenGL dynamic library, there are clearly other methods for cheating the dynamic loader at the target platform, we all know that, but it seems that from Carmack’s
fov, not every gamer had that enough knowledge (at least back in those days when Linux distros were much more difficult to use and manipulate). Times change, operating systems change, and since a long time the Q2 source code was released under GPL terms, and now that QGL necessity basically …. deceased, the QGL code would still be there, but it’s like looking at your NES Action Set more or less, it’s got no practical use today. The other reason of QGL existence is discussed at this article by Oliver McFadden on the Q3A engine:
I’m sure having the qgl API made sense at some point in time (GL 1.x) however now it’s just a pain for doing any kind of porting.
It seems that QGL found its way to be more useful for OpenGL call tracing, you would set
gl_log cvar to 1 and that was it, you would get a nice and really big file filled with text that basically tells you all the OpenGL calls that were made during execution, I did that one time for 15 seconds and I got a 100 Mb file and a big performance hit on the rendering pipeline! .
Like I said before, this is also no longer necessary, there are dedicated technologies like apitrace, who flawledsly traces all OpenGL calls made by an executable and much more. So, with all that in the table, I came to my own conclusion: it was time to get rid of QGL, I did it in the style of ioquake3, leaving only qgl pointers to functions related with OpenGL extensions.
- qgl extension pointers are the only thing left. Just like in ioquake3.
QGL_GetProcAddress(as an abstraction of
SDL_GL_GetProcAddress) will now handle the assignment of qgl extension function pointers
QGL_Initnow only brings up the qgl extension pointers and
QGL_Shutdowntear them down (to
gl_logcvar and GL logging system are now purged
gl_drivercvar is now purged
- Severe code cleanup
You can watch all of those changes in my
noqgl branch on GitHub, it’ll be merged into
master around this weekend.
Je vous dis adieu, 😉