## A bit of my personal history, experimenting in 3D game design.

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.

## OGRE 1.11.5 Working on ‘Phosphene’

One of the open-source software projects which has often fascinated me, is called OGRE, which stands for Open-Source Graphics Rendering Engine. It’s a very powerful set of libraries, that allows good coders to design 3D graphics applications, which take full advantage of hardware-accelerated – i.e., GPU-based – rendering, of virtual 3D scenes designed by such users, into simulated 2D camera views, within the same scene. This is one of the most common modes in which 3D Graphics is operated.

One of the things that OGRE is not, is a full-fledged game engine unto itself. This is due to:

• Lack of sound implementation (Additionally linking applications to the SDL Library may solve that),
• Lack of scripting support, without some sort of add-on. I think I compiled it with Python support, which would supply scripting, if my coding was good enough.

Modern builds of OGRE break with the past, in that they no longer use ‘OIS’ as their input system. Instead, at least their Sample Browser uses the ‘SDL library’ to do the same.

One of the feats which I have now accomplished on the computer named ‘Phosphene’, which is a Debian / Stretch, Debian 9 system, was to compile version 1.11.5 of this engine because I’m curious about Game Design, which I have been for a long time. And one of the reasons I feel that this software is stable on Phosphene, is due to the information which I already provided in This past posting. The past posting announced observations which I made, when this same hardware was called the computer ‘Plato’, but already running Debian Stretch.

What my observation essentially suggests is, that running 3D, OpenGL applications can in fact break the compositor because they suspend it, but that there is a work-around.

(Updated 2/20/2019, 19h00 … )

## Why R2VB Should Not Simply be Deprecated

The designers of certain graphics cards / GPUs, have decided that Render-To-Vertex-Buffer is deprecated. In order to appreciate why I believe this to be a mistake, the reader first needs to know what R2VB is – or was.

The rendering pipeline of DirectX 9 versus DirectX 11 is somewhat different, yet also very similar, and DirectX 9 was extremely versatile, with a wide range of applications written that use it, while the fancier Dx 11 pipeline is more powerful, but has less of an established base of algorithms.

Dx 9 is approximated in OpenGL 2, while Dx 10 and Dx 11 are approximated in OpenGL 3(+) .

## d3dcompiler_47.dll

Microsoft has stipulated, that in the future, all DirectX applications will need to use a DLL named D3DCOMPILER_47, if not of some greater version. What this driver does seems quite useful.

In the past, it had always been a limitation in the design of raster-based graphics, that actual shader code needed to be fed to the graphics drivers directly as text. As an alternative, D3DCOMPILER allows for the shader code to be compiled into bytecode, which DirectX drivers can understand. This also has uses in obfuscating copyrighted content. But mainly, it provides performance improvements in fact, because many games today have highly complex “Compute Shaders” etc..

When we install the Windows SDK on a Windows 7 or a Windows 10 computer, not the same libraries and header files will install each time.

(Some Text Deleted Because Erroneous Before.)

Dirk

(Edit 09/18/2016 : )

I have learned, that the library D3DCOMPILER_47.DLL is supposed to reside in both the System32 and the SysWOW64 folders (on a 64-bit Windows system), and is auto-generated there, much as D3DX9_43.DLL was, by the DirectX system on the computer, which is supposed to be running the game in question.

Because the DirectX system on Windows 7 will generate at maximum, D3DCOMPILER_43.DLL , some game developers have been including their own version of the _47 DLL, in the same directory as the EXE File, which is also the first directory the EXE File tends to search for it.

But a problem with that is, that some version of this library will be built specifically for Windows 8.1 for example, and will therefore not run properly on Windows 7. This produces an obscure error message, which I do not recall the exact spelling of.

Yet, the onus is not on the OGRE developers to supply their own version of this library. They do supply a version with their SDKs specifically, but that one is now built to run on Windows 8.1 as well.

Further, version _47 may only be needed for DirectX 11 applications, while _43 may still be good enough for Legacy DirectX 9. Yet, if OGRE was coded to use _47, then it will use that version throughout, even if I was only to try building their DirectX 9 rendering system.

The correct Path on my Windows 7 box ‘Mithral’ for this DLL, is


C:\Program Files (x86)\Windows Kits\8.1\Redist\D3D\x86



Contrarily to what the spelling of this Path may suggest, the DLL version I find there does load correctly on Windows 7. And, I am based on the conventional 32-bit build of OGRE. The above Path is related to one, which will also reveal the 64-bit DLL.

As for OGRE still requiring the Legacy DirectX SDK to build, this is a question of which version of the header files it has been programmed to expect, as well as of providing both the DXGUID and D3DX Static Libraries, whose file-names end in .LIB, as opposed to any DLL Files, which are the Dynamically Linked Libraries.

It is common, for the compilation of software to rely on such static libraries, whereas to run the software should only require the DLL Files, under Windows.