D on next-gen consoles and for game development

[Flamaros]

On Thursday, 23 May 2013 at 18:13:17 UTC, Brad Anderson wrote:
> While there hasn't been anything official, I think it's a safe 
> bet to say that D is being used for a major title, Remedy's 
> Quantum Break, featured prominently during the announcement of 
> Xbox One. Quantum Break doesn't come out until 2014 so the 
> timeline seems about right (Remedy doesn't appear to work on 
> more than one game at a time from what I can tell).
>
>
> That's pretty huge news.
>
>
> Now I'm wondering what can be done to foster this newly 
> acquired credibility in games.  By far the biggest issue I hear 
> about when it comes to people working on games in D is the 
> garbage collector.  You can work around the GC without too much 
> difficulty as Manu's experience shared in his DConf talk shows 
> but a lot of people new to D don't know how to do that.  We 
> could also use some tools and guides to help people identify 
> and avoid GC use when necessary.
>
> @nogc comes to mind (I believe Andrei mentioned it during one 
> of the talks released). [1][2]
>
> Johannes Pfau's work in progress -vgc command line option [3] 
> would be another great tool that would help people identify GC 
> allocations.  This or something similar could also be used to 
> document throughout phobos when GC allocations can happen (and 
> help eliminate it where it makes sense to).
>
> There was a lot of interesting stuff in Benjamin Thaut's 
> article about GC versus manual memory management in a game [4] 
> and the discussion about it on the forums [5].  A lot of this 
> collective knowledge built up on manual memory management 
> techniques specific to D should probably be formalized and 
> added to the official documentation.  There is a Memory 
> Management [6] page in the documentation but it appears to be 
> rather dated at this point and not particularly applicable to 
> modern D2 (no mention of emplace or scoped and it talks about 
> using delete and scope classes).
>
> Game development is one place D can really get a foothold but 
> all too often the GC is held over D's head because people 
> taking their first look at D don't know how to avoid using it 
> and often don't realize you can avoid using it entirely. This 
> is easily the most common issue raised by newcomers to D with a 
> C or C++ background that I see in the #d IRC channel (many of 
> which are interested in game dev but concerned the GC will kill 
> their game's performance).
>
>
> 1: http://d.puremagic.com/issues/show_bug.cgi?id=5219
> 2: http://wiki.dlang.org/DIP18
> 3: https://github.com/D-Programming-Language/dmd/pull/1886
> 4: http://3d.benjamin-thaut.de/?p=20#more-20
> 5: http://forum.dlang.org/post/k27bh7$t7f$1@digitalmars.com
> 6: http://dlang.org/memory.html

As a game developer I will be really enjoyed to be able to 
develop our games in D, and for kind of games we do the major 
issue isn't the GC but the portability and links with 3-party 
libraries (mostly for our internal tools).

We essentially works on Point & Click games :
https://www.facebook.com/pages/Koalabs-Studio/380167978739812?ref=stream

A lot of games companies target many architectures like ARM, X86, 
or PowerPC,...

And for our internal tools we essentially use Qt, but for the 
moment I didn't try QtD. I don't have the chance for the moment 
to work on D during my work time.