I was wide-eyed and curious. And much before the year 2000, I only owned Windows-based computers, purchased most of my software for money, and also purchased a license of 3D Game Studio, some version of which is still being sold today. The version that I purchased well before 2000 was using the ‘A4′ game engine, where all the 3DGS versions have a game engine specified by the latter ‘A’ and a number.
That version of 3DGS was based on DirectX 7 because Microsoft owns and uses DirectX, and DirectX 7 still had as one of its capabilities to switch back into software-mode, even though it was perhaps one of the earliest APIs that offered hardware-rendering, provided that is, that the host machine had a graphics card capable of hardware-rendering.
I created a simplistic game using that engine, which had no real title, but which I simply referred to as my ‘Defeat The Guard Game’. And in so doing I learned a lot.
The API which is referred to as OpenGL, offers what DirectX versions offer. But because Microsoft has the primary say in how the graphics hardware is to be designed, OpenGL versions are frequently just catching up to what the latest DirectX versions have to offer. There is a loose correspondence in version numbers.
Shortly after the year 2000, I upgraded to a 3D Game Studio version with their ‘A6′ game engine. This was a game engine based on DirectX 9.0c, which was also standard with Windows XP, which no longer offered any possibility of software rendering, but which gave the customers of this software product their first opportunity to program shaders. And because I was playing with the ‘A6′ game engine for a long time, in addition owning a PC that ran Windows XP for a long time, the capabilities of DirectX 9.0c became etched in my mind. However, as fate would have it, I never actually created anything significant with this game engine version – only snippets of code designed to test various capabilities.
The way OpenGL versions parallel DirectX versions and their capabilities, is roughly like so:
- OpenGL 2 -> DirectX 9
- OpenGL 1.1 -> DirectX 7
- OpenGL 1.4 -> DirectX 8
- OpenGL 3 -> DirectX 10
- OpenGL 4 -> DirectX 11
Further, the computer which is presently acting as my Web-server, which I name ‘Phoenix’, only has as its graphics chip an NVIDIA GeForce 6150SE, that offers the Linux world OpenGL 2.1.2 . Even though Microsoft had once made DirectX 9 a standard, on Windows 10 computers, this graphics chip is no longer supported, just because its hardware-rendering capabilities do not live up to what is expected of any modern graphics chip. The lowest version of DirectX which I know any Microsoft computers to provide backwards-compatibility for, is DirectX 8 – nowadays through an emulation. And so the only way I can make ‘Phoenix’ work today is literally, by installing Linux on it.
All the way up to and including DirectX 9, graphics cards and chips were organized into Vertex Pipelines, and Pixel Pipelines, while with DirectX 10 / OpenGL 3, Unified Shader Model was introduced, in which any GPU shader core can be made to work as either type of shader.
What gets called a Pixel Shader under DirectX, is called a Fragment Shader under OpenGL.
And eventually my computing preferences changed such, that I prefer working with Linux computers over Windows, and therefore, I also have a greater curiosity these days, for how to use OpenGL, even though its features closely parallel those of DirectX, at least, as long as the user has sufficiently powerful graphics hardware installed, so as to support OpenGL 4.5… Which corresponds to DirectX 11…
There may be some truth to the rumour, that the latest DirectX capabilities have not been fulfilled by the latest OpenGL versions, but because the game works as I wrote above, I see this as a temporary situation, which will keep repeating itself.
I also began to examine other game engines, such as “OGRE” and “Unity 3D”.
I suppose that there exists a substantial difference between DirectX and OpenGL which I should elaborate – apart from the fact that they are two completely different APIs, that access the same H/W capabilities.
One of the two standards stores its 4×4 matrices as a sequence of elements that proceed row-by-row, while the equivalent matrices in the other API store them as a sequence of 4 columns. I forget which does which. But the net effect is, that either matrix is meant to be written the same way, and to be multiplied by a position vector the same way, to result in an equivalent, transformed position vector.
Regardless of whether a vector is to be a (more-normal) column vector, or a row vector, in computing, any vector is stored the same way – essentially as a list of elements. And so in one system, 4 dot-products need to be computed, while in the other system, 4 scalar products need to be computed, and because each is in turn a vector, the 4 resulting vectors need to be added.
I personally believe that the reason for this difference between how DirectX and OpenGL work, is not for any technical advantage, but only to avoid possible copyright lawsuits. The GPU supports computing a dot-product, as easily as it supports computing the scalar product between a vector and a real number, as easily as a vector-addition. But because these two systems store the matrices in a different order, the actual shader code needs to be different at the hardware-level, in order finally to arrive at the same, correct result.
(Edited 5/04/2019, 19h10 : )
Further, because in Algebra, to multiply a column vector by a matrix requires that the vector be on the Right-Hand-Side of the matrix, while to multiply a row-vector by it, requires that the vector be on the Left-Hand-Side of the matrix, High-Level Shader code for DirectX puts the vector in question on the LHS, while the High-Level Shader code for OpenGL puts this vector on the RHS, so that DirectX computations written in the correct syntax proceed left-to-right, even though algebraically, Matrix and Vector multiplications ‘normally’ proceed right-to-left.
(End Of Edit. )
Under Linux, there exists an emulator named “Wine”, which is a recursive acronym that stands for Wine Is Not An Emulator. And its purpose is to allow Windows software to run under Linux – more or less. And the type of Windows software Linux users use it for, is often, ‘Games that were designed to run under DirectX’.
Well at some point I carried out the experiment of running the ‘A6′ version of 3D Game Studio under Wine. The result I obtained was, that the animations rendered correctly, but certain windows within the 3DGS Editors, the purpose of which were, to display the matrices for the game-dev to see, would actually show me the transpose of the matrix which I knew to be correct.
So, instead of showing [ 0.0, 0.0, 0.0, 1.0 ] as the last row of such a matrix, the program, running under Wine, would show me this sequence as the last column of the matrix. But this was just a side effect of how Wine generally translates what Windows programs presume to be DirectX calls, into OpenGL calls, that need to be supported natively on the Linux host-computers, by the Linux-installed graphics hardware.