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