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... ... ...)
