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.
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 :)
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.
