On Friday, 23 February 2018 at 01:54:07 UTC, Leonardo wrote:
> Hi, I'm new to language and games.
> Many people say that GC is bad and can slow down your project in some moments.
> What can happen if I create a game using D without worrying with memory management?
> (using full GC)

From my experience a combination of the following is necessary:
- not having the audio thread registered
- using pools aggressively for game entities

On Saturday, 24 February 2018 at 07:12:21 UTC, Guillaume Piolat wrote:
> From my experience a combination of the following is necessary:
> - not having the audio thread registered
> - using pools aggressively for game entities

I'll read the resources you gave.
Thanks for the all answers. Great community here.

On Friday, 23 February 2018 at 03:25:33 UTC, Norm wrote:
> On Friday, 23 February 2018 at 01:54:07 UTC, Leonardo wrote:
>> Hi, I'm new to language and games.
>> Many people say that GC is bad and can slow down your project in some moments.
>> What can happen if I create a game using D without worrying with memory management?
>> (using full GC)
>
> Have a look at https://github.com/gecko0307/atrium and see how memory is handled there.
>
> TBH though every game I've written I have not worried about the GC and just code it up. This works fine for 2d games, platformers etc. If it ever does bite you can always schedule the pauses (they are deterministic in the sense a collect will occur on allocation) or do pretty much what every game does in C++/C and allocate in pools.
>
> Cheers,
> Norm

Atrium game use Dlib, more specific this module to manually manage memory.
Appears to be very easy to use. Thanks.
https://github.com/gecko0307/dlib/wiki/dlib.core.memory

I'm in the same boat. I do games. But I love D's syntax and template power. So I'm doing a full experiment.

Honestly, if D is that big a liability, you'll encounter it long before it's "too late" to port it to C++.

Last night I had stuttering issues, but I realized there was a single, C-function, being called too many times (and never deallocating!).

But previously, I've also had stutter issues. Now granted, I test on a "crap" laptop 2 GB RAM / Celeron processor. But it'll be 60 FPS ... then spike down. If this happens again with my current project, what I'm going to do, is hack the open source garbage collector to fire off an event/console message EVERY TIME it actually pauses to collect. Because it's possible the GC isn't actually the problem, or, some simple change to a line of code may prevent the GC from being a problem.

That said, there's also @nogc (but that's also a bit of a lie because they never tell you that ANY THREAD running GC code can pause ALL THREADS for a collection.)

But if you're making games, you should really be using static pools anyway. What's the MAXIMUM number of objects/trees/maps your game will have at a time? It's simple (regardless of D, C, Python, or Lua). Static. Pools. Basically, you just allocate at startup a simple fixed-length array for all your objects. That way, you're never asking the OS for memory = Never needing the garbage collector. If you don't use all that memory? Who cares. RAM is cheap. And if your program CAN swell in size, that means your low-end PCs will fail without knowing why.

So you just put all your objects in fixed length arrays of size MAX_OBJECTS, MAX_ENEMIES, MAX_ITEMS, etc. And deleting an object is as simple as erasing it, or marking it as "bool is_deleted = true;" and adding a new object is simply finding the first "is_deleted" and re-running the constructor / re-using the carcass of the dead object.

99% of AAA studios use static pools. Now technically, static pools are "chunks" of fixed length arrays. So you could have one pool for a "map", and start loading another pool for the next map you're going to enter, and then when you finally transfer to the next map, you then free the static pool by marking it as deleted. And repeat as necessary. So it's a very macro-level amount of allocations. We're talking like, less than a dozen actual entities. (Depends on gametype, of course. But the order-of-magnitude helps convey it.)

gc causes unpredictabilities in performance*. With games it tends to be worst case performance that matters.

I would reccomend using std.experimental.allocator (even if you still use the default GC backed allocator). This will allow you to swap out your allocator for a more specialised one as your requirements become more concrete.

auto foo = new CustomStruct();

becomes

auto foo = allocator.make!CustomStruct();

The next thing you probably want is @nogc - Last time I checked getting IAllocator objects are a bit tricky to use in @nogc code. Currently I am using https://github.com/radcapricorn/alloctraits to get around this limitation (You will still need an allocator that doesn't use the GC, I use Mallocator for test purposes).

* The GC itself is deterministic, but it is really easy to write code that triggers GC pauses at times that is difficult track down.







On Sat, Apr 7, 2018 at 7:55 AM, Chris Katko via Digitalmars-d-learn < digitalmars-d-learn@puremagic.com> wrote:

> I'm in the same boat. I do games. But I love D's syntax and template power. So I'm doing a full experiment.
>
> Honestly, if D is that big a liability, you'll encounter it long before it's "too late" to port it to C++.
>
> Last night I had stuttering issues, but I realized there was a single, C-function, being called too many times (and never deallocating!).
>
> But previously, I've also had stutter issues. Now granted, I test on a "crap" laptop 2 GB RAM / Celeron processor. But it'll be 60 FPS ... then spike down. If this happens again with my current project, what I'm going to do, is hack the open source garbage collector to fire off an event/console message EVERY TIME it actually pauses to collect. Because it's possible the GC isn't actually the problem, or, some simple change to a line of code may prevent the GC from being a problem.
>
> That said, there's also @nogc (but that's also a bit of a lie because they never tell you that ANY THREAD running GC code can pause ALL THREADS for a collection.)
>
> But if you're making games, you should really be using static pools anyway. What's the MAXIMUM number of objects/trees/maps your game will have at a time? It's simple (regardless of D, C, Python, or Lua). Static. Pools. Basically, you just allocate at startup a simple fixed-length array for all your objects. That way, you're never asking the OS for memory = Never needing the garbage collector. If you don't use all that memory? Who cares. RAM is cheap. And if your program CAN swell in size, that means your low-end PCs will fail without knowing why.
>
> So you just put all your objects in fixed length arrays of size MAX_OBJECTS, MAX_ENEMIES, MAX_ITEMS, etc. And deleting an object is as simple as erasing it, or marking it as "bool is_deleted = true;" and adding a new object is simply finding the first "is_deleted" and re-running the constructor / re-using the carcass of the dead object.
>
> 99% of AAA studios use static pools. Now technically, static pools are "chunks" of fixed length arrays. So you could have one pool for a "map", and start loading another pool for the next map you're going to enter, and then when you finally transfer to the next map, you then free the static pool by marking it as deleted. And repeat as necessary. So it's a very macro-level amount of allocations. We're talking like, less than a dozen actual entities. (Depends on gametype, of course. But the order-of-magnitude helps convey it.)
>

On Saturday, 24 February 2018 at 07:12:21 UTC, Guillaume Piolat wrote:
> From my experience a combination of the following is necessary:
> - not having the audio thread registered
> - using pools aggressively for game entities

Also you can save a lot of clockcycles if you put @nogc everywhere you don't allocate on the heap, the stack will be automatically cleaned up.

I'm currently thinking on restructuring the way my engine handles display lists on sprites (dynamic array contains the priority, multiple associative arrays for Coordinates, sprites, attributes), however if enabling exception handling in @nogc parts will enable associative array indexing, I'll just skip the whole procedure, otherwise probably moving the whole thing to rbtree.

On Monday, 9 April 2018 at 00:25:21 UTC, solidstate1991 wrote:
> On Saturday, 24 February 2018 at 07:12:21 UTC, Guillaume Piolat wrote:
>> From my experience a combination of the following is necessary:
>> - not having the audio thread registered
>> - using pools aggressively for game entities
>
> Also you can save a lot of clockcycles if you put @nogc everywhere you don't allocate on the heap, the stack will be automatically cleaned up.
>
> I'm currently thinking on restructuring the way my engine handles display lists on sprites (dynamic array contains the priority, multiple associative arrays for Coordinates, sprites, attributes), however if enabling exception handling in @nogc parts will enable associative array indexing, I'll just skip the whole procedure, otherwise probably moving the whole thing to rbtree.

Why... associative arrays? Wouldn't that become expensive when you hit 1,000s, or 10,000's of objects, for something as tiny as a coordinate (two or three floats) lookup?

On Monday, 9 April 2018 at 01:01:18 UTC, Chris Katko wrote:
> Why... associative arrays? Wouldn't that become expensive when you hit 1,000s, or 10,000's of objects, for something as tiny as a coordinate (two or three floats) lookup?
Well, that's the other reason why I was looking for a different solution. Currently it's quite fast, maybe because it uses integers for the most part (only transformation effects use floats due to easier workarounds with vectorization), might replace the multiple associative arrays with a single auto-sorting one.