On Tuesday, 4 August 2015 at 19:14:51 UTC, Rick wrote:
>
> After leaving C++ behind for a few years to work in some higher-level languages for job-related coding, I was excited when I stumbled upon D ...

This is a typical path ...

> I spent several weeks tearing through the language reference and standard APIs ...
>

... of a new user, who becomes very impressed

> Unfortunately I'm regrettably having to reconsider my decision to start a game project (or any project requiring significant time investment) in D.

... but the story usually continues with disillusionment
(let me guess: buggy toolchain, not everything is ready)

> Not because of the language or compiler, but rather because of the lack maturity in the supporting tools; specifically, a debugger.

Yep.

On Tuesday, 4 August 2015 at 19:13:44 UTC, Rikki Cattermole 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.

http://remedygames.com/job_offer/senior-tools-programmer/

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?

D bindings to C++ is a little problematic, am I safe to learn bindings to SFML? Or is it that the D bindings is done with CSFML(C bindings).

On Tuesday, 4 August 2015 at 20:22:05 UTC, karabuta 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?
>
> D bindings to C++ is a little problematic, am I safe to learn bindings to SFML? Or is it that the D bindings is done with CSFML(C bindings).

 I mean both DSFML and derelictSFML

On Tuesday, 4 August 2015 at 20:25:07 UTC, karabuta wrote:
>
>> D bindings to C++ is a little problematic, am I safe to learn bindings to SFML? Or is it that the D bindings is done with CSFML(C bindings).
>
>  I mean both DSFML and derelictSFML

DerelictSFML2 [1] binds to CSFML [2].

DSFML [3] binds against a custom SFML wrapper called DSFML-C [4].

[1] https://github.com/DerelictOrg/DerelictSFML2
[2] http://www.sfml-dev.org/download/csfml/
[3] https://github.com/Jebbs/DSFML
[4] https://github.com/Jebbs/DSFML-C

On Thursday, 30 July 2015 at 13:44:41 UTC, deadalnix 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?
>
> GC's up.

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

Kind Regards
Benjamin Thaut

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.

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.

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?

On Wednesday, 5 August 2015 at 15:08:46 UTC, Rick wrote:
> GCC: Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)
>

I'm afraid apple is fucking with you...