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.
