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

On 05/23/2013 08:13 PM, Brad Anderson wrote:
> 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.

As a starting point, do we have a list of the Phobos functions that allocate using GC when there's no need to?  That's a concern of Manu's that it ought to be possible to address relatively swiftly if the information is to hand.

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

May I ask where this intel comes from? Do you have any more
details on how D is used in the project?

On Thu, May 23, 2013 at 08:22:43PM +0200, Joseph Rushton Wakeling wrote:
> On 05/23/2013 08:13 PM, Brad Anderson wrote:
> > 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.
> 
> As a starting point, do we have a list of the Phobos functions that allocate using GC when there's no need to?  That's a concern of Manu's that it ought to be possible to address relatively swiftly if the information is to hand.

I listened to Manu's talk yesterday, and I agree with what he said, that Phobos functions that don't *need* to allocate, shouldn't. Andrei was also enthusiastic about std.algorithm being almost completely allocation-free. Maybe we should file bugs (enhancement requests?) for all such Phobos functions?

On the other hand, perhaps functions that *need* to allocate should be labelled as such (esp. in the Phobos docs), so that users know what they're getting into.


T

-- 
My program has no bugs! Only unintentional features...

On Thursday, 23 May 2013 at 18:43:01 UTC, Szymon Gatner wrote:
> 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
>
> May I ask where this intel comes from? Do you have any more
> details on how D is used in the project?

You can watch Manu's talk from DConf here:

http://www.youtube.com/watch?v=FKceA691Wcg

tl;dw They are using it as a rapid turn around scripting language for their C++ engine.

On Thursday, 23 May 2013 at 18:22:54 UTC, Joseph Rushton Wakeling wrote:
> On 05/23/2013 08:13 PM, Brad Anderson wrote:
>> 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.
>
> As a starting point, do we have a list of the Phobos functions that allocate
> using GC when there's no need to?  That's a concern of Manu's that it ought to
> be possible to address relatively swiftly if the information is to hand.

I think that's where Johannes Pfau's -vgc can come in and help.  The phobos unit tests have pretty good coverage so building those with -vgc would, in theory, point out the vast majority of places in phobos that use the gc.

On Thursday, 23 May 2013 at 18:50:11 UTC, Brad Anderson wrote:
> On Thursday, 23 May 2013 at 18:43:01 UTC, Szymon Gatner wrote:
>> 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
>>
>> May I ask where this intel comes from? Do you have any more
>> details on how D is used in the project?
>
> You can watch Manu's talk from DConf here:
>
> http://www.youtube.com/watch?v=FKceA691Wcg
>
> tl;dw They are using it as a rapid turn around scripting language for their C++ engine.

Ah I did watch it. Didn't realize Manu works at Remedy. Being small indie game dev I totally agree on the industry needing salvation from C++.

I am watching D closely for few years now but until compiler is more stable (tho this is less and less of a problem) and there is decent ARM support I still can't allow myself to switch. And the day of the switch will be glorious one.

On 2013-05-23 20:43, H. S. Teoh wrote:

> On the other hand, perhaps functions that *need* to allocate should be
> labelled as such (esp. in the Phobos docs), so that users know what
> they're getting into.

Perhaps using a UDA.

-- 
/Jacob Carlborg

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


Without official confirmation, I think it's rather early to assume D's
being used in Quantum Break. D might compile on the new consoles, but
what about druntime/phobos/etc ?

That said, I support this idea.

When I get time I'll try looking at Phobos if there is some low-hanging fruit with regards to GC usage and submit pull requests (I didn't make any non-doc contribution to Phobos yet, but I have a general idea of how its source looks).

I also think that many people overreact about GC too much. @nogc is certainly a good idea, but I think strategically using malloc, disabling/reenabling GC, using GC.free and even just using standard GC features *while taking care to
avoid unnecessary allocations* is vastly better than outright removing GC.

It'd be good to have an easy-to-use way to manually allocate classes/structs in Phobos (higher-level than emplace, something close in usability to C++ new/delete), preferably with a way to override the allocation mechanism (I assume the fabled "allocators" have something to do with this? Maybe we'll get them once DNF is released... ... ...)

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.