Atomic Game Engine Installed – twice

One of the projects which I have recently undertaken, is to compile and install Atomic Game Engine, both on my Linux laptop ‘Klystron’, and on my Windows 7 machine ‘Mithral’. This was originally a closed platform, but has received renewed interest, because it is now available under the MIT license, which is a form of Open-Source licensing, more permissive than GPL v3 is.

This platform has the eventual capability, to deploy 3D applications and games, to Windows, OS/X, Linux, Android, iOS and WebGL recipient-platforms, while some forms of it will run under Windows and Linux, in my own experience.

I have to say though, that my ability to get the Linux version of this game-design platform working, was not due to my own prowess, but rather to the fact that the development team at Atomic Game Engine, provided dedicated and consistent technical support to me, every time I ran into a problem. I would guess they are rather tired of answering my many questions for the moment, so it is also good news, that both under Linux and Windows, my installations of this platform are complete – to my own satisfaction.

I have exported a 3D application to Android from my Windows platform, but have not reproduced this success under Linux, mainly because the platform requires that I specify where my Android SDK and where my Ant executable are located – sensibly – and I do not have any Android SDK presently, installed on ‘Klystron’. I do have the Android SDK installed on ‘Mithral’, which as I said is required, and so the export to Android worked there.

Installation under Windows was much more straightforward than it was under Linux, which is often the case, because the Windows version comes as an available binary SDK, while under Linux it still needs to be custom-compiled. And whenever we custom-compile anything, we can run into dependency issues.

One major issue I faced under Linux, was the fact that the Mono packages that are standard for my Debian distribution, are not adequate in what they provide, for development in C# to be enabled. And so what I needed to do, was to subscribe to another Mono repository, managed by Mono project, to upgrade my whole Mono installation, and after that, C# also worked.

So, Atomic Game Engine allows for 3D applications and games to be designed, using the languages C#, JavaScript, and TypeScript, according to my own experience… But, a C# Project cannot be exported for WebGL playing.

Also, I have discovered along the way, that We are no longer expected to install ‘Visual Studio 2015 Express’, but rather “Visual Studio 2015 Community Edition”, and in order to get C# support to work properly on my Windows 7 machine, I needed to do an in-place upgrade, from ‘VS Express’ to ‘VS Community’.

I am pleased that all the installation and upgrading seems to have gone well, and seems to have left me with no major reliability issues, either on ‘Klystron’ or on ‘Mithral’.

However, because the build of Mono now on ‘Klystron’ is non-standard, I cannot vouch for it in general. On my actual server-box ‘Phoenix’, I must choose to stick with the more conservative Mono packages, that are meant to go with Debian, because this box needs to run reliably 100% of the time. OTOH, on ‘Klystron’, I had nothing else depending on Mono, for which reason I was also willing to do the upgrade.



OGRE 1.10 and Geometry Shader Support

On my Debian / Jessie laptop ‘Klystron’, I gave up some time ago, in compiling OGRE 1.10, this just resulting in a mess. Instead, on that platform I was only able to build OGRE 1.9 from source code, which is fully stable, as long as we stick to the OpenGL (2) Render System.

On the Windows 7 desktop ‘Mithral’, my first attempt to build OGRE 1.10 also failed, resulting in a successful compile, but then a silent crash of the Sample Browser, indicating that something was not built right.

If I have OGRE installed on several machines, it makes most sense for them to be the same OGRE version, so next I compiled OGRE 1.9 on ‘Mithral’, successfully, using Visual Studio 2015.

In response to my observation, that I had not set up the dependencies correctly on the ‘Mithral’ build attempt of OGRE 1.10, I now re-attempted that, paying closer attention to all the details, specified within CMake 3.6.2 .

I found that I could not only build OGRE 1.10 on this machine but also run it. And I found, that contrarily to how it was with OGRE 1.9, the OpenGL3+ Render System of OGRE 1.10 is capable of producing working Geometry Shaders. At least this gives me some access to Geometry Shaders, and casts doubt back onto the MESA Drivers of ‘Klystron’, which would cause the X-Server to crash, if I ran the Geometry Shader example of OGRE 1.10 .

What I still cannot do, is build the DirectX 11 Render System that is supposed to work under OGRE 1.10 , due to errors I have not yet pinned down. But what that was supposed to bring me, is now being provided successfully by the OpenGL3+ Render System. Both of these two are stated by the OGRE Team, to be experimental render systems, for version 1.10 still.

I suspect that OGRE 1.10 is being neglected by their team, in favor of OGRE 2.1, which is their effort to port OGRE to Android.



Caveat in using Visual Studio Express 2015

On my Windows 7 computer ‘Mithral’, I recently installed and started using “Visual Studio Express 2015″, which has Update 3.1, and am happy with it overall.

However, there is a type of malfunction which can take place, and apparently did. This IDE detected that I have 8 cores, and decided as a default that it would try to build as many as 8 targets concurrently, to maximize its speed. It did not detect that my 8 cores are threaded as 4, which is of minor significance. I changed the setting to 6 simultaneous builds, which means to me, that for each of the 6 targets, only one source file should be in the process of being compiled at once.

A type of condition seems to be possible, in which for an unknown reason, the application starts to build an extreme number of targets, which on my system meant maybe 15-20 targets. In the Task Manager, I saw up to 20 ‘cl.exe’ processes running at once. This was what led to an ‘OOM’ (‘Out-Of-memory’) condition, and required me to force the application to close from the Task Manager, as the IDE window had also stopped responding.

After that, I was not sure of the status of my build, so that I Cleaned the build, and also rebooted my machine, because the worst thing to my mind, would have been a not-clean shutdown. It seems that the actual reboot may not have been necessary.

After the reboot, I was able to build my Solution again, with no ill effects.

I am not sure what triggers this error, but do remember that on that occasion, I had Minimized the IDE application window and Restored it again. The whole thing gave me a bigger scare than was necessary, since no long-term corruption resulted.




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.)


(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.