On Friday, 6 July 2018 at 15:07:41 UTC, wjoe wrote:
> On Friday, 6 July 2018 at 13:15:43 UTC, Ecstatic Coder wrote:
>> Just by curiosity, can you tell me how many successful commercial games based on a D game engine are released each year ?
>
> Just out of curiosity, how many games have been released based on a C++ game engine in 1998 ?
>
>
> The original Unreal engine was almost completely written in asm, back in the late 90ies.
>
> The first C++ game engine I found was the Object Oriented Graphical Redering Engine, started some time around 2001.
>
> Carmack resisted C++ for a longer time and I believe I read something about the engine was  ported to C++ when they developed Id Tech 4 around 2004.

Actually, as I said, even today many game engines are still written in a C-inspired manner, i.e. C + classes, templates and polymorphism, mainly for performance reasons (cache friendly data oriented designs, etc).

On 7/6/18 11:19 AM, Ecstatic Coder wrote:
> On Friday, 6 July 2018 at 14:52:46 UTC, 12345swordy wrote:
>> On Friday, 6 July 2018 at 14:11:05 UTC, Ecstatic Coder wrote:
>>>
>>> Just one silly question.
>>>
>>> Can the following "naive" D code trigger a garbage collection stall ?
>>>
>>> score.Text = point_count.to!string() ~ " POINTS";
>>>
>> The correct answer is: I don't know, as I don't know what "point_count" is in the first place, as it never been defined.
>>
> 
> Actually you answer was right even if the point count was not stored as an integer ;)

The real answer is what rikki says.

Note that what point_count is is irrelevant, the concatenation operator is going to trigger a GC allocation.

We could go further and say "Well, you haven't defined `to` or `string`" and then we can say we have no idea what this means at all!

> 
> For C++, the answer is : never.

Of course, the answer in C++ is that it won't compile, this is D code! ;)

And yes, you can have @nogc code in D, and it's less pleasant than normal D code, but still WAY more pleasant that most C++ code. So will people put up with this who want to just write games? Given the current state of the landscape, probably not.

At some point, someone is going to make a fantastic game engine in D, and then we will have a ballgame. Maybe it happens after D gets better support for reference counting, maybe before. Nothing inherent in D makes it impossible or unlikely. But people aren't going to switch "just because", there needs to be a compelling reason that causes someone to champion it.

-Steve

> Of course, the answer in C++ is that it won't compile, this is D code! ;)

Seriously ?

I wrote : "And what about the same code in C++ ?"

I thought people on this forum were smart enough to understand "the C++ port of this D code".

I'm sorry to have been wrong on this.

Anyway, what nobody here *wants* to understand, is that such "NAIVE" C++ string code may not be performant, but in C++, even if you make allocations/deallocations during the game loop, this won't be good for the game performance, but that's all.

With D, ANY forgotten allocation during the game loop (and I really mean even JUST ONE hidden allocation somewhere in the whole game or engine), may cause the game to regularly freeze at the wrong time, because of an unwanted GC. Hence the phobia.

Anyway, I know I'm on a D forum here, so "those who don't want to understand won't, and those who want will", to paraphrase a former poster here.

On 07/07/2018 3:53 AM, Ecstatic Coder wrote:
> With D, ANY forgotten allocation during the game loop (and I really mean even JUST ONE hidden allocation somewhere in the whole game or engine), may cause the game to regularly freeze at the wrong time, because of an unwanted GC. Hence the phobia.

Disable the GC, boom! Done.
No risk at all.

On Friday, 6 July 2018 at 14:14:27 UTC, rikki cattermole wrote:
> On 07/07/2018 2:11 AM, Ecstatic Coder wrote:
>> On Friday, 6 July 2018 at 13:50:37 UTC, 12345swordy wrote:
>>> On Friday, 6 July 2018 at 13:15:43 UTC, Ecstatic Coder wrote:
>>>> LOL
>>>>
>>>> Ok, if I'm wrong, then this means D is already a perfect replacement to C++, especially for game development.
>>>>
>>>> Just by curiosity, can you tell me how many successful commercial games based on a D game engine are released each year ?
>>>>
>>>> Or just this year maybe...
>>>
>>> No triple AAA engine is going to switch to D for the following reasons:
>>> 1.)Cost vs benefit from converting C++ to D.
>>> 2.)Gamers do not care how things are implemented, they want results.
>>> 3.)There are high abundance of c++ programmers for employees to hired. I can't say the same thing for D.
>>> 4.)GC phobia.(The notorious culprit)
>>>
>>>
>>> -Alex
>> 
>> +1
>> 
>> Just one silly question.
>> 
>> Can the following "naive" D code trigger a garbage collection stall ?
>> 
>> score.Text = point_count.to!string() ~ " POINTS";
>
> If the GC has been disabled (which any sane performance caring application should do) no.

Yeah, I know, I'm not silly.

I meant, "if you use standard D code in a game (i.e. with GC enabled), the game may stole, but if you use standard C++ code in a game, the game may be a bit less performant".

In C++ you don't have to disable anything, and you can still use the standard C++ library to make your game if you want to.

With D, I CAN'T use the language and its standard library as usual, just because of the GC "phobia".

Which would be the #1 problem for me, because "standard" D is perfect to me, as much as "standard" C++ is nice to me.

That's my point.

On 7/6/18 11:53 AM, Ecstatic Coder wrote:
>> Of course, the answer in C++ is that it won't compile, this is D code! ;)
> 
> Seriously ?

No, not seriously! I realized what you meant.

> I wrote : "And what about the same code in C++ ?"
> 
> I thought people on this forum were smart enough to understand "the C++ port of this D code".

It was a point that we are delving into the absurd, saying "it depends on what type point_value is".

> I'm sorry to have been wrong on this.

Sorry I made it seem like I was serious, my humor can be very dry sometimes.

> Anyway, what nobody here *wants* to understand, is that such "NAIVE" C++ string code may not be performant, but in C++, even if you make allocations/deallocations during the game loop, this won't be good for the game performance, but that's all.

This is the reason why most game people shy away from D code. Because the GC is so inherent in the language, it's difficult to prove that you can call any function without incurring a possible GC cycle.

The two ways around this are to use @nogc, or to turn off the GC when you don't want it to run.

The blog has a whole series on working with and without the GC in D.

> 
> With D, ANY forgotten allocation during the game loop (and I really mean even JUST ONE hidden allocation somewhere in the whole game or engine), may cause the game to regularly freeze at the wrong time, because of an unwanted GC. Hence the phobia.

This is why you use @nogc. You then can't forget such things. But then of course, you need to avoid a lot of D niceties.

-Steve

On Friday, 6 July 2018 at 15:19:33 UTC, Ecstatic Coder wrote:
> For C++, the answer is : never.

...Yeah I had already figure out what your aiming at. For C++ the correct answer is "I do not know as I don't know how it is implemented". You act like there isn't any GC libraries for C++.

-Alex

> But then of course, you need to avoid a lot of D niceties.

Unfortunately, in my case this is the exact moment where D looses a LOT of its shininess compared to C++.

The balance is no more that much in favor of D as it was before, because it's "standard" D code which is so much more convenient than C++ in many situations, especially when implementing file processing scripts.

This is why I think that even C++ developers who use D as a file processing language (like me) will still stick to C++ for their game engine, even if they would probably be more than happy to be able to use *STANDARD* D code instead...

On Friday, 6 July 2018 at 16:33:19 UTC, 12345swordy wrote:
> On Friday, 6 July 2018 at 15:19:33 UTC, Ecstatic Coder wrote:
>> For C++, the answer is : never.
>
> ...Yeah I had already figure out what your aiming at. For C++ the correct answer is "I do not know as I don't know how it is implemented". You act like there isn't any GC libraries for C++.
>
> -Alex

LOL

Unless you implement your game in managed-C++, I don't think there is much to worry about that though...

On Friday, 6 July 2018 at 16:10:04 UTC, Ecstatic Coder wrote:
[...]
> With D, I CAN'T use the language and its standard library as usual, just because of the GC "phobia".
>
> Which would be the #1 problem for me, because "standard" D is perfect to me, as much as "standard" C++ is nice to me.
>
> That's my point.

Uhm... have you actually *tried* to do this in D?

I have a project where, for various reasons, I need to control exactly when the GC runs a collection cycle.  The code is not @nogc; in fact there are array allocations and AA allocations all over the place. And it's idiomatic D code with heavy Phobos use. But all I need to do is:

import core.memory;
GC.disable();
... // tons of code, including allocating code, Phobos calls, etc.
if (okToCollect)
   GC.collect();
... // more allocating code
GC.enable();

No collection cycles will run in the code marked "...", because the GC has been disabled. That means you can happily allocate stuff away and there will NOT be any GC stop-the-world pauses.  Of course, I don't want memory to leak away freely either, so at strategic points in the code, I call GC.collect() to clean up. IOW, I can predict, and *control*, when exactly I want to spend time to clean up my memory.

Then when I'm in a less-critical part of the code, I just re-enable the GC and let it do its job.

I know what you're going to say next.  There are cases where this level of control is not fine enough.  That's true, and that's where things like @nogc will help you.  But the blanket statement that you "can't use the language and its standard library as usual" just because of GC-phobia is, at best, inaccurate.