D on next-gen consoles and for game development

[Manu]

On 25 May 2013 04:20, Benjamin Thaut <code at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130525/7ffb93a5/attachment.html>