D for Game Development

[Manu via Digitalmars-d]

On 6 August 2015 at 21:46, Rikki Cattermole via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On 6/08/2015 11:30 p.m., Manu via Digitalmars-d wrote:
>>
>> On 6 August 2015 at 21:23, Rikki Cattermole via Digitalmars-d
>> <digitalmars-d at puremagic.com> wrote:
>>>
>>> On 6/08/2015 11:18 p.m., Manu via Digitalmars-d wrote:
>>>>
>>>>
>>>> On 5 August 2015 at 05:13, Rikki Cattermole via Digitalmars-d
>>>> <digitalmars-d at puremagic.com> wrote:
>>>>>
>>>>>
>>>>> On 5/08/2015 6:59 a.m., develop32 wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> D is really cool and makes a good candidate for developing a game.
>>>>>>> Are
>>>>>>> there any guys out there using D for indie games?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Not an indie game, but Remedy is making Quantum Break using D.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Got a source for that? As I can't find it.
>>>>
>>>>
>>>>
>>>> Hi. I dunnit, and I did a talk about it at dconf2013.
>>>
>>>
>>>
>>> I knew you were involved with them back then. I was more interested in
>>> anything that happened after that.
>>
>>
>> It took a lot longer for us to get the compiler to a sufficiently
>> stable state that we were able to build reliably than we'd liked. In
>> the mean time, code pegged for D was forced to be written in C, so a
>> lot of D code ended out being C code on account of 'couldn't wait'.
>> When I left, there were a couple of critical systems running in D, and
>> a few toolchain issues left to work out (Windows DLL's + GC). It was
>> left with Ethan who occasionally appears here.
>> I'm not sure where it went after that. There was much enthusiasm among
>> the team, but the toolchain progressed slower than we could afford,
>> and we just had to get on with it in some cases. Hopefully there's
>> still some D code in there, and (if the problems were fixed!) there's
>> no good reason why it wouldn't have scaled out from where I left it.
>
>
> Yeah I hope it had. Although would be nice to hear from Remedy what they
> currently use / think of D.
> I kinda hoped that they had released e.g. a blog post about it, which they
> haven't.

Our experience wasn't really positive. Can't/don't-want-to write a
blog post about that.
Trust me, we were very enthusiastic to stand at GDC and give a lecture
about our experience, but it didn't really go according to plan,
mostly blocked by trivial shit that's been known problems for at least
as long as I've been around here.
It's not so much language problems, it's tooling problems. It's the
most important and perhaps most neglected aspect of the D ecosystem.

1. DMD has unsatisfactory codegen for anything other than debug builds.
2. DMD generates x87 code, and uses real everywhere. We can't be
generating new x87+real instructions in 2015. It's deprecated
hardware!
2. LDC has a lot more bugs than DMD (which still has quite a few
bugs), and the Windows build is new and even more immature still.
3. LDC has no debuginfo. **biggest practical issue by far!**
4. LDC/GDC are always a few versions behind DMD. This creates an
awkward/almost-impossible situation when you rely on DMD to build
debug code, and LDC to build releasable code. Depending on 2 flaky
compilers is even less fun than one.
5. DLL's were really flakey at the time, I'm not sure how they are
now, but I'm concerned they may not be much better.
6. Shared druntime; we were loading D code from DLL's, lots of them.
It's not really reasonable for each DLL to have it's own druntime
instance, they need to share one provided by the host app.
7. D binaries are *gigantic*, I don't know why. D seems to link the
world, and I'm certain that most of the crap that's linked is never
referenced or executed... it just makes gigantic binaries for some
reason, even with line-for-line translations of C/C++ code. That's not
real good on games consoles where icache is king.


I tried to use D in my current workplace on 3 occasions now, and ran
into a different set of problems.
In the first attempt I tried to write a simple vibe.d webserver app,
but it kept crashing randomly when I was using the API's exactly as
intended (apparently a client was posting `/n` instead of `/r/n`, or
maybe the inverse of that, and it didn't like it). The IDE/debugging
situation is basically impossible; vibe.d throws exceptions all over
the place, with no really good tools for debugging this sort of thing.
My colleagues freaked out and thought I was crazy, and my credibility
was diminished.

In my second attempt, progress was interrupted by some ICE's, linking
with some C++ code caused various problems.

I investigated making another attempt to use D where we have some web
front-end code that's built using Emscripten. D would have been
perfect for this job, but LDC can't target Emscripten and/or NaCl. I
don't see that coming along any time soon. I briefly looked at trying
to make an Emscripten build of LDC, but it requires probably weeks
worth of research and expert knowledge to approach it.

A final recent attempt was basically a non-starter on account of no Qt
bindings that work &&/|| are up to date.

I'm using C++11 now, it's horrible. Let me repeat, it's HORRIBLE, but
it's *possible* to get my work done... and that's more important than
literally anything else.

I'm getting pretty close to calling it a day. Is 6 years enough time
to repeatedly prove to myself that I'm chasing a fantasy?
People keep talking about Rust, I'm thinking of giving it a shot.

I think D needs a budget, and paid programmers employed to do boring
shit that makes the whole thing more stable and robust. Mozilla seems
to have this(?)
D seems to consistently offer 95% solutions to problems. 95% is not a
solution, it's just another problem.

Oops, I ranted. Sorry! :)