The One With D

DSSS and I

After Gregor stopped posting Rebuild binaries separately from DSSS, I downloaded the dsss-light version for Windows, which is DSSS without all of the net stuff. All I really wanted was access to the Rebuild executable without building it myself. I don’t care how they do it in the Linux world, I want my binaries without having to compile them first, thank you.

So I don’t really need, or want, DSSS to manage my libraries for me. I’ve got my own system that works just fine. That, actually, is one of the reasons I never bothered to use DSSS before nor wanted to use it when I downloaded it. I also didn’t like that it generated .di files for everything. Nor did I like the idea that I had to learn how to create dsss.conf files in order to make it do what I wanted with my own projects. I was quite happy with using the simple response files I use for Bud and Rebuild.

Recently, I came to realize that it would be a good idea to add a dsss.conf file to the Derelict trunk. Since more and more people are using Tango with Derelict, and since the provided build script cannot be run by DMD when using Tango (at least on Windows, it has to be compiled into an executable first), DSSS seemed like it could potentially be a solution to the problem. So it was time to buckle down and dig into dsss.conf files.

As it turns out, creating a dsss.conf file is not nearly as complicated as the docs make it seem (Gregor did say doc writing isn’t one of his strengths). It wasn’t long before I had DSSS doing my bidding and building all of the Derelict libraries. There are still a few nits to work out, like I’m fairly certain that the DerelictSDL stuff is being compiled into every single DerelictSDL* library. I’d prefer that not to happen, but I haven’t yet seen any obvious way to exclude entire packages (nor have I really dug around for one or asked Gregor). There’s also a bug with library names that Gregor has already fixed for the next release. So when Gregor does release the next version, Derelict will be getting a dsss.conf file.

My intent was to provide dsss.conf alongside buildme.d, so that people who prefer can still run the build script. Some time ago I had refactored it to allow support for multiple build tools. That idea has now gone the way of the dodo, so I streamlined it and cleaned it up a bit just to support bud only. But now, I’m thinking, do I really need the build script? Providing two different methods of building the same project could potentially lead to confusion. I get enough confusion from just the single build script as it is. The majority of Derelict users don’t bother reading the docs, judging by the majority of support requests I get in the forum. I may very well drop the build script and just require dsss if you want to build the libraries.

Today, I set some time aside to get started on the new, reinvented Smoothie. The first thing I would normally do is set up a couple of response files for Rebuild (or Bud as the case may be) for debug/release configurations. This time, I decided to go with a dsss.conf file instead. I still don’t like that it generates .di files (is there a way to turn that off?) or creates extra files that I don’t need, but it’s not a big deal. Besides, a ‘dsss distclean’ solves that problem.

Still, if that were all, I’d see no real reason to give up Rebuild for DSSS. The big things for me are the ability to set up multiple builds in a single config file and the variety of hooks and commands available. I tend to configure my projects in such a way that I often have multiple test apps set up in their own packages. Using Rebuild or Bud, I’d need to configure a separate response file for each app. Also, I can already see how some of the hooks are going to be very useful for setting up a complex build process that involves manipulating more than just D source files.

I’ve said before in a NG post that DSSS solves problems I don’t have. That’s true, to an extent, but I see now that there’s so much more to it than just library management and easy project compilation. To say I’ve warmed up to it is an understatement. I’ll be replacing the response files for my game, and any other projects I have lying around, with DSSS configuration files. Color me converted.

Technorati Tags: D Programming Language, DSSS

Posted in Derelict, Discussion | 3 Comments »

On Closures in D

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 »

Ooops! That’s Not a Feature!

In a recent post, I described a problem with DMD 1.018 and Derelict. I assumed it was a bug with the new compiler. As it turns out, the old behavior was a bug and the compiler is now working as intended. It’s not a big deal for me, as the workaround isn’t too painful. I’ll be able to get Derelict patched up in due course and users of the library will be able to use Derelict with 1.018 and all future versions of DMD. Though, the fix I’m considering makes use of string mixins, so it won’t work with pre-CTFE versions of DMD. Though I might use template mixins instead. We’ll see.

Unfortunately, this issue goes beyond Derelict. There are several OpenGL bindings out there that are affected by this. If you are using one of them and have not yet upgraded your compiler, you will be in for a bit of a shock when you do. Here’s a list of the bindings I know of that use the same, no-longer-legal technique:

Bindings - both the gl and glu modules are affected

D-porting - both opengl.d and openglu.d, found in the opengl.zip file, are affected

GLFW - three modules (in support/d/imports in the directory tree) are affected: gl.d, glu.d and glfw.d

If you are using any of the above modules, you will have to update them (or ask a maintainer to) to use them with DMD 1.018 and later. The old OpenGL binding at DedicateD is not affected, as it is not cross-platform (and is actually quite outdated by now, anyway).

There may be other D modules out there, bindings to libraries other than OpenGL or perhaps OpenGL bindings I’m unaware of, that are affected. If you find yourself using one of them, the offending code looks like, or similar to, this:

version(Windows)
{
    extern(Windows):
}
else
{
    extern(C):
}

// function, or function pointer, declarations follow here

Walter outlines some alternative solutions in a newsgroup post. Choose an option that works for you and roll with it.

Technorati Tags: D Programming Language, DMD, Digital Mars, Derelict, OpenGL bindings

Posted in Derelict, Discussion | 1 Comment »

My New Project

In a recent post I mentioned that I am working on a new project that I will eventually release as open source. I wanted to wait until I had a solid outline of the entire project before I talked about it. Well, I have so I am.

Not too long ago, Kevin Glass let loose the first point release of his 2D Java game library, Slick. I’ve been following his progress with Slick for a while now and thought it would be nifty to port to D. I didn’t bother with it though, because I didn’t see it as something I had time for. Besides, the D community already has Clay Smith’s ArcLib. When I decided to sit down and work on a test case as described in the post linked above, I thought about what would constitute a good project. Slick immediately came to mind. So I worked on it for a couple of days and then had the epiphany I wrote about.

All projects need a name. I thought about this for a bit and wanted to derive something from Slick. Eventually, I settled on Smoothie. I couldn’t find any other game libraries with the same name. Plus, I love drinking them.

While Smoothie is based on Slick, it is not a direct port. I’m going in a different direction with much of the design, though I am certainly using some of Slick verbatim. Like Derelict, I’m primarily writing this for me. I’ll also be developing a commercial game in tandem with the library, so that’s going to drive most of the design decisions for a while. But I do have milestones set out where I will make point releases of Smoothie under the BSD license.

The first milestone will allow the creation of simple 2D games, such as Pong, Asteroids, or Space Invaders. The second milestone will add special effects, simple GUI components, support for tile-based games, and more. Each milestone is set up to be an incremental improvement over the last. Though I haven’t gotten more than the first two milestones completely fleshed out, I am looking farther down the road. I’ve structured the framework such that it can, eventually, support different windowing APIs for OpenGL context creation (SDL, DFL, SWT, or what have you). It will also be able to support 3D rendering in addition to 2D, together or separately. For example, in a 2D game you could easily create a GUI component that rendered a 3D model such that it’s not part of the game world, but part of the UI. Or in a 3D game you could easily create a 2D GUI component for the player to play a mini-game (like, maybe, tetris) while waiting for the game to load, or as part of a challenge. You could then use the same code for the mini-game and release it as a completely separate game with very few changes.

I’m a long way off from the 3D bits yet, so you won’t be seeing that any time soon. I’ve got a couple of 2D game ideas I want to pump out first. But this should give you an idea of what Smoothie is and what my goals for it are. Once I’m ready for the first point release, I’ll ask Brad for a DSource project. I expect that to be early next month. Starting soon, I’ll be keeping a devlog detailing the progress of Smoothie and the games I make with it, over at my game blog.

Comments and questions are welcome!
 

Technorati Tags: D Programming Language, Slick, Smoothie

Posted in Discussion, Gamedev/Games, News, Smoothie | 7 Comments »

Making the Move to D

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 »