"I made a game using Rust"

[evilrat via Digitalmars-d]

On Wednesday, 10 May 2017 at 22:13:29 UTC, Lewis wrote:
> On Wednesday, 10 May 2017 at 12:52:34 UTC, JN wrote:
>
> PROS
>
>
> The Rust article mentions build times as a downside. In 
> contrast, that has been one of the upsides of D for me. My 
> build time is ~1.75s for a usual-case rebuild (all the game 
> files), and ~4.5s for a full rebuild (the game, plus all heavy 
> templates (like regexes), and all library glue code (like 
> derelict)). Rapid build times are one of the killer features of 
> DMD, and it makes me happy to know it will continue to be a 
> focus as development continues.

I have played recently with one D game engine and result was 
frustrating. My compile time was about 45 sec! Engine split in 
core and actual game module, every time i build game module it 
recompiles the engine. Great compile times, yay! The engine 
itself is just ~12k LOC, "game" roughly 200 lines. For example 
UE4 project with same line count compiles within 50 secs! Of 
cource whole D engine takes just 20 secs on single core, while 
C++ project takes all my 8 cores. (and for example building whole 
UE4 takes almost hour on SSD)

Every changed line of code triggers full rebuild in D (remember, 
it does this twice, one for engine, second for game). As C++ user 
I find it unacceptable, simply because with PCH such changes is 
usually takes 2-3 secs if one don't touch the headers (well okay, 
more like 10 secs, still twice faster than D on edit-build-debug 
runs).


>
> CONS
>
> The debugger. Rainers is doing great work with Mago, I suspect 
> it simply needs more developers giving it some love. It's 
> currently a far cry from the MSVC debugger.

There is no sane x64 debugging on Windows. structs doesn't shows 
at all, that just top of the list... But I remember what's was 
back in 2011, now we at least can do full debug for x86! And last 
time I used OS X(in 2013) that was... well I prefer not to 
comment, there was simply no debugging at all.


> DLL support. I've made a handful of hacks to druntime to allow 
> me to implement hot-reloading via a DLL (a la Handmade Hero). 
> My problems all stem from the fact that a D DLL has its own 
> copy of the runtime and GC. I use the GC proxy to redirect 
> calls from the DLL's GC to the EXE's GC, and have hacked 
> together a similar solution for redirecting the spawning of 
> threads. On top of that I had to completely disable finalizers, 
> and pretty much avoid using classes altogether (at least any 
> that might need to outlive a frame or survive a hot reload). 
> I'll bet it's no easy task to implement, but if D supported 
> "light" DLLs (ie DLLs that just work out of the executable's 
> druntime), probably 2/3 my hacks to
> D would evaporate. This all being said, the hot reloading works 
> marvellously with these changes, and it combined with a <2s 
> build time makes day-to-day development far more of a joy than 
> at work.

How did you managed using classes from DLL? I mean in its current 
state D unable to cast anything that comes through process/shared 
lib boundaries(except on Linux) due to missing type info, right?
And this is serious issue, this is really blocks D from 
commercial usage, simply because there is no way to add plugin 
support (from user's point of view).

And realistically this is also not so trivial, this requires 
making special 'core' library with common classes and interfaces 
to include in every DLL and app itself, because one would need to 
use both .d and compiled module .obj (for type info, that 
annoying unresolved _ClassZ and others) and current build systems 
doesn't helps with that all, so all by hand it seems...


Overall, I really like D, but its like feeding on cactus...