Games people play

[Wolfgang Draxinger]

Georg Wrede wrote:

> We only have to become the _preferred_ language in _one_ area!
> After that it'll automatically follow that we gain other areas
> and a huge general interest. ("If C is good enough for Unix
> itself, it has to be a good language. -- If D is good enouhg
> for some of the best games shops, it has to be a good
> language.")

Two years ago I was struggling with getting reflection and
introspection done with C++ for the 3D engine I'm developing and
was looking for how other systems are doing it; I also came
across the D homepage, but not considered it an alternative yet.
However 3 unsuccessfull months later I completely dropped the
idea of getting my module system working with C++. Obj-C seemed
like a good alternative, though I don't like the mix of
Smalltalk with the constraints of plain C. Then I remembered an
language called D. Some google and a compiler install later I
fell in love with it, though it took me a while to fully
understand it's full power.

For example I got a whole bunch of OCaml code, that I used to
generate C code with for certain mathematical operations (I got
that idea from the FFTW project). But now it seems that D's
metaprogramming features, together with the optimization
algorithms of modern compilers can do the same whilst keeping it
all in the same language.

So I decided to do a hard cut, venturing a huge project
conversion, which of course requires me to learn a lot of D, and
I'm far finished from grasping all possibilities.

However using D for a game engine also brings a bit development
overhead with it. For example my engine has a global virtual
file system, memory management, garbage collection etc. i.e.
systems that could run in parallel to a language runtime, but
it's cleaner to have a unique runtime covering all parts. So I
provide my own version of Phobos, stripped down to the minimal
required subset of features. The rest is covered by engine
specific modules. One might ask, why a propritary runtime
environment is neccesary at all; this is a quite complicated
topic, among the reasons is, that one might want to deliver
binary modules within packages, that are to be unpacked at
runtime tepending on the executing environment, aka universal
binary. Another reason is, that only a very small codebase is
actually plattform dependent, and it makes no sense to recompile
the whole stuff for different plattforms. Funny enough the
OpenGL API, which by itself is plattform independent, requires
different binaries for Windows and the whole rest, which is due
to different calling conventions. I was thinking of developing a
runtime trampoline code generator, that would load and link the
OpenGL stuff upon startup. But since there are also some
plattform dependent thing to do prior to initializing OpenGL I
would have to plattform dependent compile the OpenGL module
anyway.

Apropos plattform dependency. Also here D is great: Just
segregate the code with version statements and you're done, no
ifdefs and similair hard-to-debug-if-you've-forgot-an-endif
stuff.

But there's still a lot of work to be done.

Wolfgang Draxinger

¹some graphic cards can do float/multisample within one buffers
others have it mutually exclusive.
-- 
E-Mail address works, Jabber: hexarith at jabber.org, ICQ: 134682867
GPG key FP: 2FC8 319E C7D7 1ADC 0408 65C6 05F5 A645 1FD3 BD3E