On 25 May 2013 04:20, Benjamin Thaut <c...@benjamin-thaut.de> wrote: > Am 23.05.2013 20:13, schrieb Brad Anderson: > >> 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<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<https://github.com/D-Programming-Language/dmd/pull/1886> >> 4: >> http://3d.benjamin-thaut.de/?**p=20#more-20<http://3d.benjamin-thaut.de/?p=20#more-20> >> 5: >> http://forum.dlang.org/post/**k27bh7$t7f$1...@digitalmars.com<http://forum.dlang.org/post/k27bh7$t7f$1...@digitalmars.com> >> 6: http://dlang.org/memory.html >> > > Besides my studies I'm working at havok and the biggest problems most > likely would be (in order of importance) > > - Compiler / druntime for all 9 plattforms we have to support simply do > not exist >
Yup. > - 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. > Win64 works for me out of the box... ? > - SIMD: core.simd is just not there yet. The last time I looked really > basic stuff like unaligned loads where missing. > I'm working on std.simd (slowly >_<) .. It'll get there. > - The GC. A no go, a GC free version of the runtime (non leaking) should > be provided. > 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. But we certainly don't have a GC that fits the bill. > - 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. > As with everyone in games! We need DLL's urgently.
