"I made a game using Rust"

[evilrat via Digitalmars-d]

On Thursday, 11 May 2017 at 17:38:26 UTC, Lewis wrote:
> On Thursday, 11 May 2017 at 03:17:13 UTC, evilrat wrote:
>> I have played recently with one D game engine and result was 
>> frustrating. My compile time was about 45 sec!
>
> Interesting. What game engine were you using? To me this sounds 
> like a problem in the build process. DMD isn't a build system 
> and doesn't handle build management, incremental builds, or 
> anything else like that. You'll need an external tool (or roll 
> a python script like I did). At the end of the day, you hand a 
> bunch of files to DMD to build, and it spits out one or more 
> exe/dll/lib/obj. This process for me has been quite fast, even 
> considering that I'm pretty much rebuilding the entire game 
> (minus libs and heavy templates) every time.
>
> My python script basically separates the build into four parts, 
> and does a sort of poor man's coarse incremental build with 
> them. The four parts are:
>
> - D libs
> - Heavy templates
> - Game DLL
> - Game EXE (which is pretty much just one file that loads the 
> DLL then calls into it)
>
> For example, if a lib changes, I rebuild everything. But if a 
> file in the Game DLL changes, I only rebuild the game DLL.
>

I use just dub and generated Visual D project.

Well in my case the problem is that engine is built as static 
lib, and there is not much i can do with this. I've started 
moving things around and turn lib to executable, at least now 
build time cut in half, down to 20-22 sec.

And speaking about build time i mean exactly it, compile+link. 
Compiling without linking is just 10-12 sec. That's really good 
for single-threaded build!


As for the engine...
Here, take a look.
https://github.com/Superbelko/Dash

And you also need the "game" itself, add it to the engine as 
submodule.
https://github.com/Circular-Studios/Sample-Dash-Game

>
>> There is no sane x64 debugging on Windows. structs doesn't 
>> shows at all, that just top of the list...
>
> In C++, I've generally had a very good experience with the 
> visual studio debugger, both with x86 and x64. When I program 
> C++ at home, literally the only thing I use visual studio for 
> is the debugger (the rest of the program is pretty bloated and 
> I use almost none of the other features). When you debugged on 
> x64 in windows, what debugger were you using? Even back in 2011 
> things were good enough that I could see into structs  :)
>

Everything I said about debugging was related to D, and on 
Windows Visual D specifically.
C++ had it for ages.

>> How did you managed using classes from DLL?
>
> I pretty much don't. If a class is created in the DLL from a 
> class defined in the DLL and is never touched by the EXE, 
> things seem fine. But I don't let classes cross the EXE/DLL 
> boundary, and even then I keep my usage of classes to a bare 
> minimum. Thankfully though my programming style is fairly 
> procedural anyway, so it's not a huge loss for me personally.

I see. This could even be benefit for low-level stuff like 
renderer or physics system, especially when keeping required data 
in large single array. But for the game part itself this is no 
go, not for business at least.

The real issue is that you can pass classes both ways, but any 
casts will fail due to no type info, I have not tested it myself 
but they said on Linux(only) it works as it should.
So this problem had to be resolved as soon as possible, for the 
sake of D future.