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

- Full Visual Studio integration needed. Inclusive a really good code completion and a very nice debugging experience for all plattforms. VisualD is quite nice and debugging using the visual studio debugger works quite well but its a real pita that you have to patch dmd and compile it from source so you can debug in x64 on windows.<br>
</blockquote><div><br></div><div style>Win64 works for me out of the box... ?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- SIMD: core.simd is just not there yet. The last time I looked really basic stuff like unaligned loads where missing.<br></blockquote><div><br></div><div style>I'm working on std.simd (slowly >_<) .. It'll get there.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- The GC. A no go, a GC free version of the runtime (non leaking) should be provided.<br></blockquote><div><br></div><div style>See, I have spend a decade on core tech/engine code meticulously worrying about memory allocation. I don't think a GC is an outright no-go.</div>
<div style>But we certainly don't have a GC that fits the bill.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Better windows support. All of the developement we do happens on windows and most of D's community does not care about windows support. I'm curious how long it will take until D will get propper DLL support.<br>
</blockquote><div><br></div><div style>As with everyone in games!</div><div style>We need DLL's urgently.</div></div></div></div>