On Wednesday, 5 August 2015 at 15:08:46 UTC, Rick wrote:
> On Wednesday, 5 August 2015 at 09:03:47 UTC, John Colvin wrote:
>> On Tuesday, 4 August 2015 at 19:14:51 UTC, Rick wrote:
>>> Unfortunately I'm regrettably having to reconsider my decision to start a game project (or any project requiring significant time investment) in D.  Not because of the language or compiler, but rather because of the lack maturity in the supporting tools; specifically, a debugger.  I should say upfront that this seems to be more gravely affecting OSX than other platforms, but scouring forums and wikis has made it apparent that no platform is completely devoid of obstacles when it comes to functionally debugging D programs.
>>>  To a certain extent, one can alternatively diagnose and fix bugs with verbose logging, assertions, and exceptions; but memory related bugs become exponentially more difficult to work through without being able to properly breakpoint, step through execution, and observe all variables in the current scope.
>>
>> gdb works fine on OS X and has D support.
>
> Can you enlighten me as to what configuration you've confirmed this on?  I'm on
> OSX: 10.9.5 (Mavericks)
> GDB: GNU gdb 6.3.50-20050815 (Apple version gdb-1824) (building newer from source tends to fail to compile)
> DMD: DMD64 D Compiler v2.067
> GCC: Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)
>
> At best, I can _sometimes_ hit breakpoints when using Mono-D, it's inconsistent.  Even when a breakpoint is hit however, GDB only recognizes the current 'this' value; it doesn't recognize any frame / local variables other than 'this', global variables, etc., though it does recognize the call-stack at least.  When using GDB directly from a terminal, the only D source file it recognizes for the purpose of setting breakpoints or listing source code is app.d (which contains the main() entry-point).
>
> Also have tried compiling with all combinations of -g, -gc, -debug, -gs, and -cov.  None seem to improve the situation.

Yeah that's apple messing with you, that gdb is old. See http://ntraft.com/installing-gdb-on-os-x-mavericks/ for proper installation instructions.

P.s. I help maintain homebrew packages for a bunch of D stuff, its generally more up to date than macports and even has the current betas/rcs as well as support for building from master.

On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:
> D is really cool and makes a good candidate for developing a game. Are there any guys out there using D for indie games?
>
> For some time I have been seeing some cool game engine being developed in the DUB repo. What more is happening? I don't see derelictSDl and derelictSFML activities much. Whatup?

One thing I would really like for D would be an opengl binding in phobos, there was some momentum a while ago to try to get graphics into phobos with Aurora, but literally nothing came of that. People want an all D gui, and graphics support but literally nothing will ever happen until we at least get some basic graphics interfaces like a simple windowing library and some opengl. We are already getting color and images, full on hw supported graphics is the next step.

Also a thing I would really like is if all the new graphics related things went into a std.graphics, it would be nice if it was std.graphics.color, std.graphics.image, std.graphics.opengl, std.graphics.window, std.graphics.gui, ect...

That and some simple linear alg into phobos, gl3n pls?

We literally have most of the needed parts already just laying around on dub and in other places.

On Thursday, 6 August 2015 at 00:05:34 UTC, Tofu Ninja wrote:
> One thing I would really like for D would be an opengl binding in phobos, there was some momentum a while ago to try to get graphics into phobos with Aurora, but literally nothing came of that.

As I recall it wasn't for lack of trying. Binding D to the existing C++ was just too difficult, and those issues were what spurred the greater push for improving C++ compatibility.

On Thursday, 6 August 2015 at 01:13:04 UTC, Meta wrote:
> On Thursday, 6 August 2015 at 00:05:34 UTC, Tofu Ninja wrote:
>> One thing I would really like for D would be an opengl binding in phobos, there was some momentum a while ago to try to get graphics into phobos with Aurora, but literally nothing came of that.
>
> As I recall it wasn't for lack of trying. Binding D to the existing C++ was just too difficult, and those issues were what spurred the greater push for improving C++ compatibility.

What existing c++? Wasn't Aurora supposed to be an all D solution.

On 6/08/2015 12:05 p.m., Tofu Ninja wrote:
> On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:
>> D is really cool and makes a good candidate for developing a game. Are
>> there any guys out there using D for indie games?
>>
>> For some time I have been seeing some cool game engine being developed
>> in the DUB repo. What more is happening? I don't see derelictSDl and
>> derelictSFML activities much. Whatup?
>
> One thing I would really like for D would be an opengl binding in
> phobos, there was some momentum a while ago to try to get graphics into
> phobos with Aurora, but literally nothing came of that. People want an
> all D gui, and graphics support but literally nothing will ever happen
> until we at least get some basic graphics interfaces like a simple
> windowing library and some opengl. We are already getting color and
> images, full on hw supported graphics is the next step.
>
> Also a thing I would really like is if all the new graphics related
> things went into a std.graphics, it would be nice if it was
> std.graphics.color, std.graphics.image, std.graphics.opengl,
> std.graphics.window, std.graphics.gui, ect...
>
> That and some simple linear alg into phobos, gl3n pls?
>
> We literally have most of the needed parts already just laying around on
> dub and in other places.

Here is what we need to do going forward (beyond what me and Manu are doing):

1. Derelict-Util needs to be put into Phobos. This is not optional
2. Derelict-GL3 needs to be put into Phobos. Optional, but might be a damn good idea!
3. Windows API needs to be moved into either Phobos or druntime. Not optional.
4. X11 bindings added to Phobos. Not optional.
5. Cocoa bindings added to Phobos. Not optional.

This all needs to happen _before_ we start working on a window library for Phobos.
Let alone a GUI.

We're mostly got problems with Cocoa. X11 bindings just need to be changed to dynamically bound.

Windows API bindings if gone into druntime wouldn't need to go through the review cycle luckily. But would need some decent review on e.g. Github.

On 06-Aug-2015 09:29, Rikki Cattermole wrote:
> On 6/08/2015 12:05 p.m., Tofu Ninja wrote:
>> On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:
[snip]
>> Also a thing I would really like is if all the new graphics related
>> things went into a std.graphics, it would be nice if it was
>> std.graphics.color, std.graphics.image, std.graphics.opengl,
>> std.graphics.window, std.graphics.gui, ect...
>>
>> That and some simple linear alg into phobos, gl3n pls?
>>
>> We literally have most of the needed parts already just laying around on
>> dub and in other places.
>
> Here is what we need to do going forward (beyond what me and Manu are
> doing):
[snip]
> 3. Windows API needs to be moved into either Phobos or druntime. Not
> optional.
FYI
https://github.com/D-Programming-Language/druntime/pull/1076

-- 
Dmitry Olshansky

On 6/08/2015 8:27 p.m., Dmitry Olshansky wrote:
> On 06-Aug-2015 09:29, Rikki Cattermole wrote:
>> On 6/08/2015 12:05 p.m., Tofu Ninja wrote:
>>> On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:
> [snip]
>>> Also a thing I would really like is if all the new graphics related
>>> things went into a std.graphics, it would be nice if it was
>>> std.graphics.color, std.graphics.image, std.graphics.opengl,
>>> std.graphics.window, std.graphics.gui, ect...
>>>
>>> That and some simple linear alg into phobos, gl3n pls?
>>>
>>> We literally have most of the needed parts already just laying around on
>>> dub and in other places.
>>
>> Here is what we need to do going forward (beyond what me and Manu are
>> doing):
> [snip]
>> 3. Windows API needs to be moved into either Phobos or druntime. Not
>> optional.
> FYI
> https://github.com/D-Programming-Language/druntime/pull/1076

Hopefully in the next major release! :)

On Wednesday, 5 August 2015 at 16:44:03 UTC, jmh530 wrote:
> On Wednesday, 5 August 2015 at 08:53:39 UTC, Benjamin Thaut wrote:
>>
>> Regarding D's GC and Games written in D you can also take a look at a old project of mine and the results that came out of it.
>>
>> http://3d.benjamin-thaut.de/?p=20
>
> Towards the end you list some performance and memory leaking issues in D. Have you seen improvement in these areas?


- Comparision of TypeInfo objects in druntime is done by building two strings and then comparing those two strings. This will always leak memory and do a lot of unneccesary allocations which are a performance bottleneck. I reworte the comparison so it does not allocate a single byte.

I did a pull request to improve this once, but it was rejected. So this issue still remains. Comparing two type info objects still produces garbage.

- Calls to the druntime invariant handler are emitted in release build also and there is no way to turn them off. Even if the class does not have any invariants the invariant handler will always be called, walk the class hirarchy and generate multiple cache misses without actually doing anything.

Afaik this has been fixed.

- The new statement will not free any memory if the constructor throws a exception. So you are forced to replace both the new and the delete statement. But you can not replace the new statement with similar nice syntax especially for inner classes and arrays.

This issue still remains, although might improve soon with std.allocator. The language is not designed to make it possible for new/delete to be replaced in a nice way so most likely

new int[3] will become allocator.makeArray!int(3)

- Inlining of DMD. Inlining of DMD seems to be very minimal. Most of my overloaded operators are not inlined by dmd at all.

This somewhat improved, especially with pragma(inline) but dmd is still really bad at inlining and I still can't compile all my projects with the -inline switch because dmd produces invalid function calls if I do so. And don't tell me to use a different compiler, on windows the only viable option still is dmd. Gdc for windows is no longer maintained and ldc is not there yet (but might be soon).

- Array literals. They always allocate, even if they don’t have to. For example when asiging to a fixed size array, or when passing to a function with a scope parameter.

This greatly improved. Thanks to Kenji you can now have non allocating array literals.

- D-Style variadic functions. Same as array literals, because internaly they are rewrote to one. Especially for these kind of functions I don’t see any reason why they should allocate on the heap.

I'm not sure about this one, I would have to investigate.

Kind Regards
Benjamin Thaut

On 6 August 2015 at 11:18, Benjamin Thaut via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Wednesday, 5 August 2015 at 16:44:03 UTC, jmh530 wrote:
>>
>> On Wednesday, 5 August 2015 at 08:53:39 UTC, Benjamin Thaut wrote:
>>>
>>>
>>> Regarding D's GC and Games written in D you can also take a look at a old project of mine and the results that came out of it.
>>>
>>> http://3d.benjamin-thaut.de/?p=20
>>
>>
>> Towards the end you list some performance and memory leaking issues in D. Have you seen improvement in these areas?
>
>
>
> - Comparision of TypeInfo objects in druntime is done by building two strings and then comparing those two strings. This will always leak memory and do a lot of unneccesary allocations which are a performance bottleneck. I reworte the comparison so it does not allocate a single byte.
>
> I did a pull request to improve this once, but it was rejected. So this issue still remains. Comparing two type info objects still produces garbage.
>
> - Calls to the druntime invariant handler are emitted in release build also and there is no way to turn them off. Even if the class does not have any invariants the invariant handler will always be called, walk the class hirarchy and generate multiple cache misses without actually doing anything.
>
> Afaik this has been fixed.
>
> - The new statement will not free any memory if the constructor throws a exception. So you are forced to replace both the new and the delete statement. But you can not replace the new statement with similar nice syntax especially for inner classes and arrays.
>
> This issue still remains, although might improve soon with std.allocator. The language is not designed to make it possible for new/delete to be replaced in a nice way so most likely
>
> new int[3] will become allocator.makeArray!int(3)
>
> - Inlining of DMD. Inlining of DMD seems to be very minimal. Most of my overloaded operators are not inlined by dmd at all.
>
> This somewhat improved, especially with pragma(inline) but dmd is still really bad at inlining and I still can't compile all my projects with the -inline switch because dmd produces invalid function calls if I do so. And don't tell me to use a different compiler, on windows the only viable option still is dmd. Gdc for windows is no longer maintained and ldc is not there yet (but might be soon).
>

There are binaries that are released every so often (and announced in the GDC channel), but not one seems to give feedback on them.

http://gdcproject.org/downloads

On 5 August 2015 at 05:13, Rikki Cattermole via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 5/08/2015 6:59 a.m., develop32 wrote:
>>
>> On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:
>>>
>>> D is really cool and makes a good candidate for developing a game. Are there any guys out there using D for indie games?
>>
>>
>> Not an indie game, but Remedy is making Quantum Break using D.
>
>
> Got a source for that? As I can't find it.

Hi. I dunnit, and I did a talk about it at dconf2013.