In the past days is struggeled compiling MinGW-GDC on Windows, so here is a full list of instructions what needs to be done:
Continue reading
Category Archives: D programming
Runtime code reloading in D, part 1
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
Real World Comparison, GC vs. Manual Memory Management
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.
Suggestions for the D 2.0 Programming Language
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.
Light Propagation Volumes Implementation
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.
The paper about the alogrithm can be found here:
http://www.vis.uni-stuttgart.de/~dachsbcn/download/lpv.pdf
The model and textures have been taken from the crytek site: http://www.crytek.com/cryengine/cryengine3/downloads
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.
Implementation of Light Propagation Volumes von Benjamin Thaut steht unter einer Creative Commons Namensnennung 3.0 Unported Lizenz.
Beruht auf einem Inhalt unter www.vis.uni-stuttgart.de.
D 2.0 Stacktrace
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.
