<div dir="ltr">gc causes unpredictabilities in performance*. With games it tends to be worst case performance that matters.<br><br>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. <br><br>auto foo = new CustomStruct();<br><br>becomes <br><br>auto foo = allocator.make!CustomStruct();<br><br>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 <a href="https://github.com/radcapricorn/alloctraits">https://github.com/radcapricorn/alloctraits</a> to get around this limitation (You will still need an allocator that doesn't use the GC, I use Mallocator for test purposes).<br><br>* The GC itself is deterministic, but it is really easy to write code that triggers GC pauses at times that is difficult track down. <br><br><br><br><br><br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Apr 7, 2018 at 7:55 AM, Chris Katko via Digitalmars-d-learn <span dir="ltr"><<a href="mailto:digitalmars-d-learn@puremagic.com" target="_blank">digitalmars-d-learn@puremagic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
Honestly, if D is that big a liability, you'll encounter it long before it's "too late" to port it to C++.<br>
<br>
Last night I had stuttering issues, but I realized there was a single, C-function, being called too many times (and never deallocating!).<br>
<br>
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.<br>
<br>
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.)<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.)<br>
</blockquote></div><br></div>