Archive for the ‘D Programming’ Category
Wednesday, September 12th, 2007
Slow news day for D, but there’s a blog post over at hans-eric.com titled, D doesn’t have real closures. Hans-Eric talks about D’s delegates, how they are similar to closures, and how they aren’t quite real closures because they don’t keep surrounding variables alive after the scope has changed. His conclusion is that it’s not a big deal, but at least one commenter so far disagrees with him.
Personally, I don’t see it as a big deal either. For my purposes, I don’t really need true closures in D. I do like to see them implemented in scripting languages, though. They are very handy for game AI. Since Lua added closures, that has become one of its major selling points for game developers. If I do come across a case where a true closure would come in handy, I have no problem making use of an inner class instead. D just has so many other useful features, such as anonymous delegates and lazy evaluation (two among many), that not having true closures doesn’t bother me a bit.
Technorati Tags: D Programming Language, delegates, closures
Posted in D Programming, Discussion | No Comments »
Tuesday, May 8th, 2007
When I first started following D, it was out of curiosity. When I started Derelict (which turned 3 years old last Friday, by the way — Happy Birthday, Derelict!), I did so with the goal of one day using it for my own personal projects. At the time, however, I was reluctant to start using D for anything else. Even after I started this blog over a year ago, I still was hesitant to pick up D for any production code. I toyed around with simple programs for some Derelict tests, or to try out new language features, but nothing more. Even while I was evangelizing D in other forums and communities, I was waiting for the ‘right moment’ to start using it on a serious project myself.
For a long while now I’ve been working sporadically on a commercial game project using C. Progress has been slow primarily because I only spend a few hours a week working on it (if that). But there have been other speed bumps along the way, things that any C developer worth his salt will have encountered more often than he would like (as an example, I spent three days chasing down a memory corruption bug not too long ago). I love C, with all of its foibles and weaknesses, but there certainly are days when I feel like throwing my computer out of the window.
Not too long ago, with one of the more recent DMD releases, I started to get this nagging feeling that the time for D had arrived. The more I ignored it, the stronger it got. Seeing in the NG those glowing reviews by the team0xf guys made it stronger still. So I decided to put it to the test on something other than Derelict and more than just a 10 minute test case. I quickly came up with a project idea and got to work.
After a several hours scattered over 2 days, I’ve already made great progress. Derelict requires only a small subset of D features, so though I’ve been aware of the benefits of using many of them, I’ve not actually seen any in production code until now. The more D I use on this project, the more I never want to see a line of C code again. In fact, I’ve already come to two decisions. For one, I’m going to move this test project forward into a production library. Second, I’m going to drop the C game project completely. I’ll eventually start over using D (it may seem to others like a waste of months of effort, but it’s really not a big deal). Before that, though, this new project has given me a couple of other ideas to work on.
Yeah, I’m going all out on this. I’ve typed up design documents, set up milestones and tasks on my local copy of activeCollab, and I actually sat down and blocked off large chunks of time on my calendar for development. My game business has been something that I wanted to get up and running sometime in the next few years (i.e., no solid plan), but now the worm has turned and I’m focusing on it exclusively. I’ll continue teaching English, but I’m going to stop taking contract software development work completely. Contract work was the real time killer for me and it’s never been something I really enjoy (mostly J2EE stuff). There are a few other minor distractions I’m cutting out as well. From here on, I’ll consider myself a full time D game programmer!
There are two side-effects. The first is that I’ll be able to set aside more time to work on Derelict than I ever have been able to before. Since I’ll now be a Derelict user myself, I’ll get to see first-hand any warts that crop up (at least, on a subset of the packages). The second is that the little test project that started this enlightenment will be made publicly available under a BSD license.
The point of this post is to proclaim to the world that D has set me free! My old reluctance to use it for production code was warranted way back when, but I can see no justifiable reason not to use D in its current state. I can’t remember the last time I had this much fun typing code into a text editor. Thanks, Walter, for bringing D to where it is today.
Technorati Tags: D Programming Language
Posted in D Programming, Derelict, Discussion | 8 Comments »
Wednesday, March 21st, 2007
Howard Berkey has opened up a site aimed at helping newcomers to D:
I have put up a web site where I have started collecting information I wish I had found in one place when I started learning D
If you are currently in the phase of wrapping your head around D, you most likely should have D-Riven in your bookmarks.
Technorati Tags: D Programming Language
Posted in D Programming, News | No Comments »
Sunday, March 11th, 2007
Sometimes you need to execute different code paths depending upon certain runtime parameters. For example, in graphics applications it is quite common to create different rendering paths based upon the graphics API features supported by the user’s graphics card. In simple cases, this can be handled with an if…else block, or perhaps a switch. More complex cases need more. In C, you might set function pointers during app startup. In C++ or Java, you might use different implementations of an interface or of an abstract class. In D, you can do many of the same things as other languages. You can also put all of your variable code paths in one class, rather than subclasses or different interface implementations, and let instances configure themselves in the constructor using delegates.
Here’s a simple example that configures an instance of a class based upon the value of a static counter:
// selfdelegate.d
import std.stdio;
class Printer
{
public:
this()
{
if(count++ == 0)
print = ¬hingPrinter;
else
print = &somethingPrinter;
}
void delegate() print; // delegate configured during instantiation
private:
void nothingPrinter()
{
writefln(”Nothing.”);
}
void somethingPrinter()
{
writefln(”Something”);
}
static int count = 0;
}
void main()
{
Printer p1 = new Printer;
Printer p2 = new Printer;
p1.print();
p2.print();
}
Here’s a sample execution:
C:\projects\D\tests>dmd -run selfdelegate
Nothing.
Something
If you have many methods that need to be configured, you may prefer to use a factory and instantiate different implementations of an interface. That approach limits you to some extent, however.
For example, consider an OpenGL renderer interface that has three implementations: an advanced version, an intermediate version requiring at least version 1.x of OpenGL, and a legacy version for OpenGL 1.1. What if the user’s graphics card doesn’t support a few of the extensions used by the advanced version, but does support most of them? With the set up described, you’d have no choice but to fall back to the intermediate or legacy version. Wouldn’t it be better if you could make use of the advanced features that are supported and use fallbacks only for those that aren’t? There are several different ways to mix and match like that. Using delegates for a class to configure itself at runtime is one you might not have thought of.
Technorati Tags: D Programming Language, delegates
Posted in Code, D Programming | No Comments »
Friday, March 9th, 2007
Well, I just learned something new. There’s a feature over at The Independent Gaming Source (which I found via Jay Barnson) on Japanese indie shmups (shoot’em ups). The main article is a great introduction to the genre and, of course, mentions Kenta Cho. But the really interesting from the perspective of a D user comes in the Addendum regarding the technology used in many of these games:
Development of homebrew shmups has been led by a number of diverse
technologies. A lot of the Japanese developers use the D language,
perhaps inspired in part by Kenta Cho’s games and the D source included
with many of them. Developers such as Isshiki, HIZ, and Kenmo all use
D, and ABA games’ influence is apparent. Game Maker is more dominant in
the west, with very active forums and many good shmups being created.
However, a wide variety of technologies are being used, as witnessed by
the volume of threads and visitors at Shmup-Dev, a site dedicated to
shooter development and help. One of the more interesting, and useful
technologies helping out shmup developers is Kenta Cho’s BulletML.
Created as an XML markup to describe bullet behaviour, there have been
numerous bindings to programming languages such as D, C/C++, Java, and
even Flash.
I had no idea so many Japanese indies were using D for their games. Looks like Kenta Cho as become a sort of unofficial ambassador for D in Japan. I’ve not looked at the games linked from the article to see which use D, so you’ll have to check them out for yourself to see which is which.
Technorati Tags: D Programming Language, games, game programming, Japan, Kenta Cho, shmups
Posted in D Programming, Gamedev/Games, News | 1 Comment »