May 11, 2017
On Wednesday, 10 May 2017 at 18:20:01 UTC, zetashift wrote:
> On Wednesday, 10 May 2017 at 12:52:34 UTC, JN wrote:
>> I wonder, would it be possible for D in the current state to achieve the same? I imagine iOS isn't possible yet and Android is just getting there?
>
> Reading this thread while going through the online D book I wonder;
> Would one recommend D for gamedev? I was thinking of writing small games with the help of SFML to learn D better and try to get better at programming game logic(DLang is my second programming language).

I've been using D for little 2D games for Windows and it's an excellent choice. I never bothered to set up debugging properly, I mostly rely on printf debugging and stacktrace after crashes though. But you have access to libraries like SDL/SFML, Box2D/Chipmunk, for 2D game you don't really need much more. And it's definitely more fun than C/C++.
May 11, 2017
On Wednesday, 10 May 2017 at 12:52:34 UTC, JN wrote:
> Interesting thread I got from Reddit, someone made a game for PC and mobiles fully in Rust.
>
> https://michaelfairley.com/blog/i-made-a-game-in-rust/
>
> "Last week, I released A Snake’s Tale on iOS, Android, Windows, Mac, and Linux.".
>
> I wonder, would it be possible for D in the current state to achieve the same? I imagine iOS isn't possible yet and Android is just getting there?

DlangUI has Android support.
You can develop and debug game on desktop, then build for Android.

May 11, 2017
On Thursday, 11 May 2017 at 08:27:16 UTC, Vadim Lopatin wrote:
>
> DlangUI has Android support.
> You can develop and debug game on desktop, then build for Android.

Can we have an option to create OpenGL forward compatible context, please? This would really help with debugging graphics issues because not all tools (renderdoc for example) support multi-threaded rendering and/or multi-context programs. And running DlangUI with CodeXL shows it doesn't use deprecated functions, I assume it is, maybe except that old "gears" sample.
May 11, 2017
On 5/10/17 7:54 PM, H. S. Teoh via Digitalmars-d wrote:
> On Wed, May 10, 2017 at 07:52:53PM -0400, Steven Schveighoffer via Digitalmars-d wrote:
> [...]
>> I'll reiterate here: if the compiler's sanity is suspect, there's nothing
>> much for it to do except crash. hard. And tell you where to look.
> [...]
>
> OTOH, it's not very nice from a user's POV.  It would be nice(r) if this
> PR could be looked at and brought to a mergeable state:
>
> 	https://github.com/dlang/dmd/pull/6103

Yes, totally agree. Proper reporting of errors is a very important thing. Here's another one: https://issues.dlang.org/show_bug.cgi?id=13810

-Steve
May 11, 2017
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.

May 12, 2017
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.
May 12, 2017
On Friday, 12 May 2017 at 02:43:17 UTC, evilrat wrote:
> 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!

Ah okay. If I understand correctly, the "game" itself is just the two .d files in the Scripts folder, which get compiled then linked with the prebuilt .lib for the engine. If so, a 10-12s compile just for those two files still sounds really long to me. Either I'm misunderstanding, or there's something bizarre going on that's causing those build times.

I'm using derelict heavily in my project, and therefore most of my libraries live in DLLs. I've run into some annoyances with this, for example, bugs in the derelict interface to the DLL, either existing ones or ones I introduce myself, can be very difficult to detect and debug, since there's no type checking across the DLL boundary. But one huge advantage is that the build time overhead for these libraries is almost zero.

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

Ah, my apologies I misunderstood. Agreed, the current debugging experience for D leaves much to be desired unfortunately.

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

Yeah I agree that this limitation sucks. Even if I try to avoid using classes, there are still times where I'm forced into it. For example, Thread is a class. I have to be very cautious when working with an instance of Thread, or I risk bizarre crashes due to mismatched typeinfo.


May 14, 2017
Am Fri, 12 May 2017 05:42:58 +0000
schrieb Lewis <musicaljelly@gmail.com>:

> Ah okay. If I understand correctly, the "game" itself is just the two .d files in the Scripts folder, which get compiled then linked with the prebuilt .lib for the engine. If so, a 10-12s compile just for those two files still sounds really long to me. Either I'm misunderstanding, or there's something bizarre going on that's causing those build times.

You can't tell how long a compile takes from looking at the size of the modules you pass to the linker. Unlike C++, Dlang lacks header files that could short-circuit import chains. What this means is that all the imports in a module (except inside templates) are analyzed recursively. In the game at hand this only means parsing the entire engine code base in addition to the two modules, but projected onto LibreOffice or other big projects it would parse the code of so many libraries that compilation times would sky-rocket. (I told this story here once or twice before, but haven't actively done anything to improve the situation.)

Things you can do today:

- If an import is only used in templates, copy it inside of
  them. This works today and stops the import from being
  analyzed unless the template is instantiated during the
  compilation. Multiple instances wont pessimize compile
  times.

- Move imports from top-level into the functions that use
  them. There is no other way to say "This import not needed by
  our public interface".

- Don't turn everything and the dog into a template. Nested
  templates stretching over several modules require analysis
  of all those modules along the way, while a regular function
  may stop right there.

- Following all the above, generate .di files for your
  library's exported modules. All the imports inside
  non-template functions will be removed and only what's
  needed by the public interface (i.e. argument types and
  return types) is kept.

Several ideas spread in the past. From the top of my head:

- Walter had the idea to make imports evaluate lazily, and
  improve the situation without resorting to .di files.
- Some issued with the .di file generation stop it from being
  widely used for example by dub when installing libraries.
- The "export" keyword could be narrowed down to be the only
  visibility level that goes into the .di files created for a
  library. (Removing public and package visibility symbols and
  imports pulled in by them in turn.)

Last not least, with single-file-compilation like in C++ you may still shoot yourself in the foot in Dlang, because when you update a template and forget to recompile all modules that instantiate it, it is left in the old state there and cause conflicts at link time or runtime errors.

Disclaimer: If you find mistakes in the above or something simply isn't true any more please give an update on the current situation.

-- 
Marco

1 2 3
Next ›   Last »