If you are not familiar with the Non Virtual Interface idiom I recommend that you go and read about it. D takes this idiom to the next level by allowing to have tempalted methods within interfaces if they are final. This can be very powerfull and help reducing boilerplate code.
staticassert(!is(T==const)&&!is(T==immutable),"can not read into const / immutable value");
staticassert(!is(typeof(data)==const)&&!is(typeof(data)==immutable),"can not read into const / immutable array");
If you look at the above example you can see that the IInputStream interface has two templated methods which are final. Thos methods implement the behavior needed for arrays and value types. Then they forward the read in the correct way to readImpl. As a result implementing the IInputStream interface becomes really easy. The only method that needs to be implemented is the readImpl method as you see from the FileInStream class. The correct handling of different types only has to be implemented once, inside the interface, and all implementations don’t have to care about this anymore. You could also think of something similar for serializing data. A ISerializer interface which implementes all the needed type handling as templates and forwards it to simple protected methods. Then implementing different serialization targets (e.g. json, xml, binary, etc) would be quite easy and not require writing and testing template code anymore. A further advantage of this idiom is, that it lowers the amout of code bloat because the templates only get generated once for the interface and are reused by every implementation.
D strives to prevent implicit conversion between user defined types at all costs. This is mostly because there are so many implicit conversion rules in C++ and history has shown that implicit conversions can lead to really hard to track down bugs. But sometimes you still want a user defined type A to implicitly convert to a builtin type or user defined type B. This is possible in the D programming language using a property and the “alias this” feature.
alias convHelper this;
intb=a;//implicit conversion happening here
The key to this idiom is the “convHelper” property. Which does the conversion and is callable without parentheses because it does not take any arguments (a property). Next we declare “alias convHelper this”. This causes the compiler to do a fallback to aliased symbol in case using the original type does not work. This way the compiler will automatically insert a call to convHelper in case our NumberAsString type can not be used directly. As a result we get our implicit conversion.
Unfortunately this does only work for a implicit conversion to a single type. Implicit conversions to multiple types are not possible because only a single alias this is allowed per type.
The code shown above has been tested with dmd 2.063.2
One of the biggest problems in game developement are turnaround times. Tournaround time is the time you have to wait until you can see what your change actually did. Shorter turnaround times improve productivity as you don’t spend that much time waiting for changes to become visible. Also shorter turnaround times support the creative process as humans have huge dificulties connecting an action and a result that happens with a huge delay. For mappers, 3d artists, effect artists and sound designers the turnaround times in modern 3d engines are almost zero. A lot of work is put into their tools to keep turnaround times to a minimum. Programmers however usually have very long turnaround times. Mostly this is due to the fact that compile times of the C++ language, which is mostly used in game developement, can go into multipe minutes. This problem is almost solved in the D programming language, as compile times are really quick and it usually only takes a few seconds to compile a project. But after making changes to the code you still have to restart the game, wait for it to load all the resources and then fly/walk to the spot in the level you are currently interrested in. I got really tired of this process so I decided to build a runtime reloading for certian parts of my own little game engine. Continue reading →
During the 4th Semester of my studies I wrote a small 3d spaceship deathmatch shooter with the D-Programming language. It was created within 3 Months time and allows multiple players to play deathmatch over local area network. All of the code was written with a garbage collector in mind and made wide usage of the D standard library phobos. After the project was finished I noticed how much time is spend every frame for garbage collection, so I decided to create a version of the game which does not use a GC, to improve performance.
As no one picked up the developement on the winamp plugin after I released the sourcecode and new alienware laptops keep coming out every year, so I decided to put a litte bit more work into the winamp alienfx plugin. With this update users are able to add support for new laptops themselfs by editing a xml file. I will explain here how to create the xml file.
To download the plugin go to the original post: AlienFX Winamp plugin Continue reading →
First of all don’t take this article to negative. I really like the D programming language and often when I have to go back to C++ coding im sitting in front the code thinking “Oh this would be so much easier in D” or “This could be solved much cleaner in D”.
I recently completed 3 Projects using the D 2.0 programming language:
– A implementation of the Light Propagation Volumes algorithm
– A 3d multiplayer cross platfrom (windows / linux) space shooter
– A lisp interpreter (with almost all Scheme features)
The two 3D projects have been done using OpenGL and are very performance critical. You only get to spend 16ms every frame until it has to be completely rendered otherwise you won’t reach fluent framerates. The lisp interpreter was performance critical too, but more of a test how good D is usable as a systems programming language.
With some help of Nils Reichert I was able to modifiy my AlienFX Winamp plugin so that it now supports the M17X R3. It should also support the M15X R3 now as the used AlienFX devices should be the same. You can find the download locations in my old post:
I also decided to release the source code for both the plugin itself and the led tester I’ve written, so that someone else can continue the developement as I don’t have time for it anymore. You can freely modifiy the programm under the following conditions:
you have to name me as original author
you may not use it for anything commercial
you have to distribute it under the same conditions then I do
For a university project I implemented the Light Propagation Volumes technique implemented in CryEngine 3 to simulate indirect illumination. I wrote this demo from scratch using OpenGL and the D programming language.
You can download the application for windows including the full sourcecode and documentation here: lpv-release.zip
To fly around in the scene klick into the 3d window and press M to activate the mouse, then you can fly around using the WASD keys and the mouse. To deactivate the mouse looking press M again.
For everything else you can use the GUI.
I wrote a small piece of sourcecode that generates stacktraces in D 2.0 under windows. It works both with the pdb and cv debug symbol format. For Exceptions that are derived from the Error or Exception class the trace information is automatically appended, this causes all builtin D errors to get a stacktrace information. The only point where this does not work is the Access Vioaltion error, as it does not call the stacktrace callback function for some reason.