www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - "I made a game using Rust"

reply JN <666total wp.pl> writes:
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?
May 10
next sibling parent Stanislav Blinov <stanislav.blinov gmail.com> writes:
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?
7700 lines of Rust. We need a language called Nine Inch Nails or something :D
May 10
prev sibling next sibling parent Atila Neves <atila.neves gmail.com> writes:
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?
I'd like to know how it was packaged to run Rust on both iOS and Android. Atila
May 10
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
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?
Probably about the same, the author mostly complains about immature libraries for mobile and D is really in the same boat... BTW: "Add an icon to my .exe” don’t have ready-made solutions." I'd be surprised if that is any different in Rust than it is in D... which is no different than it is in C. And this is what jumps out at me: "Holy cow are the compiler error messages generally fantastic." Those of you on IRC know that I've been pushing hard for better error messages. I think that is *the* killer feature clang offered and I see it brought up again and again. D used to do well. Now we're lagging behind. No language change needed to vastly improve error messages.
May 10
parent reply Ethan Watson <gooberman gmail.com> writes:
On Wednesday, 10 May 2017 at 13:22:22 UTC, Adam D. Ruppe wrote:
 Those of you on IRC know that I've been pushing hard for better 
 error messages. I think that is *the* killer feature clang 
 offered and I see it brought up again and again.

 D used to do well. Now we're lagging behind. No language change 
 needed to vastly improve error messages.
I find it a very curious state of affairs myself that Microsoft's C++ compiler has significantly better error messages than DMD.
May 10
parent reply Adrian Matoga <dlang.spam matoga.info> writes:
On Wednesday, 10 May 2017 at 14:00:08 UTC, Ethan Watson wrote:
 On Wednesday, 10 May 2017 at 13:22:22 UTC, Adam D. Ruppe wrote:
 Those of you on IRC know that I've been pushing hard for 
 better error messages. I think that is *the* killer feature 
 clang offered and I see it brought up again and again.

 D used to do well. Now we're lagging behind. No language 
 change needed to vastly improve error messages.
I find it a very curious state of affairs myself that Microsoft's C++ compiler has significantly better error messages than DMD.
Would you mind giving some examples?
May 10
next sibling parent reply Ethan Watson <gooberman gmail.com> writes:
On Wednesday, 10 May 2017 at 14:02:38 UTC, Adrian Matoga wrote:
 Would you mind giving some examples?
My biggest bugbear with DMD is internal compiler errors giving me no meaningful information. Excepting one or two edge cases with SSE types and the .NET compiler, I can get a meaningful error message and an error code from MSVC. And you can search them all through the MSDN documentation. https://msdn.microsoft.com/en-us/library/8x5x43k7.aspx If I find the message isn't that helpful, googling for the error code usually brings up discussions on stackoverflow about it. Even user-inserted #errors have an error code. https://msdn.microsoft.com/en-us/library/y0tzt8e0.aspx
May 10
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Wednesday, 10 May 2017 at 14:13:37 UTC, Ethan Watson wrote:
 On Wednesday, 10 May 2017 at 14:02:38 UTC, Adrian Matoga wrote:
 Would you mind giving some examples?
My biggest bugbear with DMD is internal compiler errors giving me no meaningful information.
Internal compiler errors (ICEs) are bugs which are generally treated as high priority. Please report them.
May 10
parent reply Ethan Watson <gooberman gmail.com> writes:
On Wednesday, 10 May 2017 at 14:31:28 UTC, Vladimir Panteleev 
wrote:
 Internal compiler errors (ICEs) are bugs which are generally 
 treated as high priority. Please report them.
See my previous rant on this subject. http://forum.dlang.org/post/qkxyfiwjwqklftcwtcik forum.dlang.org tl;dr - Sure, we'll submit bugs, but if someone literally has to stop work for a day because they can't tell at a glance what's gone wrong when compiling code then that's a massive failure of the compiler.
May 10
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 5/10/17 10:37 AM, Ethan Watson wrote:
 On Wednesday, 10 May 2017 at 14:31:28 UTC, Vladimir Panteleev wrote:
 Internal compiler errors (ICEs) are bugs which are generally treated
 as high priority. Please report them.
See my previous rant on this subject. http://forum.dlang.org/post/qkxyfiwjwqklftcwtcik forum.dlang.org
And my previous answer: http://forum.dlang.org/post/nqc4tg$12im$1 digitalmars.com 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. Fortunately for the current state of affairs, if the error is in the front-end, it's D. And it should give you a stack trace. Your previous example seems to be in C++ part of it, so no stack trace. -Steve
May 10
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
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 T -- Programming is not just an act of telling a computer what to do: it is also an act of telling other programmers what you wished the computer to do. Both are important, and the latter deserves care. -- Andrew Morton
May 10
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
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
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 10 May 2017 at 14:02:38 UTC, Adrian Matoga wrote:
 Would you mind giving some examples?
What bothers me on a regular basis is overloading. Basic case: $ dmd lll lll.d(6): Error: none of the overloads of 'foo' are callable using argument types (int, double), candidates are: lll.d(1): lll.foo(int a, int a) lll.d(2): lll.foo(int a, string s) Contrast that to g++: $ g++ lll.cpp lll.cpp: In function ‘int main()’: lll.cpp:7:14: error: no matching function for call to ‘foo(int, Foo)’ foo(0, Foo()); ^ lll.cpp:7:14: note: candidates are: lll.cpp:1:6: note: void foo(int, char*) void foo(int a, char* b); ^ lll.cpp:1:6: note: no known conversion for argument 2 from ‘Foo’ to ‘char*’ lll.cpp:2:6: note: void foo(int, float) void foo(int a, float b); ^ lll.cpp:2:6: note: no known conversion for argument 2 from ‘Foo’ to ‘float’ The g++ example isn't great either... but is better because of this: "no known conversion for argument 2 from ‘Foo’ to ‘float’" It actually told me which argument didn't match! clang is similar: $ clang lll.cpp lll.cpp:7:2: error: no matching function for call to 'foo' foo(0, Foo()); ^~~ lll.cpp:1:6: note: candidate function not viable: no known conversion from 'Foo' to 'char *' for 2nd argument void foo(int a, char* b); ^ lll.cpp:2:6: note: candidate function not viable: no known conversion from 'Foo' to 'float' for 2nd argument void foo(int a, float b); With the dmd one, especially on a long function, it is hard to tell just which argument is giving trouble. The C++ errors just flat out tell me which argument didn't match for each candidate. Templates with constraints are even worse. lll.d(3): Error: template std.algorithm.sorting.sort cannot deduce function from argument types !()(int), candidates are: /home/me/d/dmd2/linux/bin32/../../src/phobos/std/algorithm/sorting.d(1830): std.algorithm.sorting.sort(alias less = "a < b", SwapStrategy ss = SwapStrategy.unstable, Range)(Range r) if ((ss == SwapStrategy.unstable && (hasSwappableElements!Range || hasAssignableElements!Range) || ss != SwapStrategy.unstable && hasAssignableElements!Range) && isRandomAccessRange!Range && hasSlicing!Range && hasLength!Range) What a mess! Just formatting that output might help, but I'd especially love it if it told me which individual boolean elements failed, passed, and were short-circuited. The compiler knows this, it had to evaluate that to figure out it didn't match, but it doesn't tell me. At a glance, can you even tell what I passed to the function? Bonus points would be it telling me why, for example, `isInputRange` failed, but I understand that is an even bigger problem to solve. Of course, C++ doesn't have constraints so there's no comparison there. Lastly, check this out: lll.d(5): Error: function lll.foo (Color c) is not callable using argument types (Color) WTF, right? Well, I have a locally defined `struct Color` and an imported one. Same name, but different type. The error message doesn't tell me which one is which. These are the top 3 dmd error messages that bother me regularly. At runtime, little drives me more nuts than RangeError not telling me the index and the length. Again, it knows, the code checked it, but it didn't report it.
May 10
parent reply Adrian Matoga <dlang.spam matoga.info> writes:
On Wednesday, 10 May 2017 at 15:03:19 UTC, Adam D. Ruppe wrote:
 On Wednesday, 10 May 2017 at 14:02:38 UTC, Adrian Matoga wrote:
 Would you mind giving some examples?
What bothers me on a regular basis is overloading. Basic case: $ dmd lll lll.d(6): Error: none of the overloads of 'foo' are callable using argument types (int, double), candidates are: lll.d(1): lll.foo(int a, int a) lll.d(2): lll.foo(int a, string s) Contrast that to g++: $ g++ lll.cpp lll.cpp: In function ‘int main()’: lll.cpp:7:14: error: no matching function for call to ‘foo(int, Foo)’ foo(0, Foo()); ^ lll.cpp:7:14: note: candidates are: lll.cpp:1:6: note: void foo(int, char*) void foo(int a, char* b); ^ lll.cpp:1:6: note: no known conversion for argument 2 from ‘Foo’ to ‘char*’ lll.cpp:2:6: note: void foo(int, float) void foo(int a, float b); ^ lll.cpp:2:6: note: no known conversion for argument 2 from ‘Foo’ to ‘float’ The g++ example isn't great either... but is better because of this: "no known conversion for argument 2 from ‘Foo’ to ‘float’" It actually told me which argument didn't match! clang is similar: $ clang lll.cpp lll.cpp:7:2: error: no matching function for call to 'foo' foo(0, Foo()); ^~~ lll.cpp:1:6: note: candidate function not viable: no known conversion from 'Foo' to 'char *' for 2nd argument void foo(int a, char* b); ^ lll.cpp:2:6: note: candidate function not viable: no known conversion from 'Foo' to 'float' for 2nd argument void foo(int a, float b); With the dmd one, especially on a long function, it is hard to tell just which argument is giving trouble. The C++ errors just flat out tell me which argument didn't match for each candidate.
In this simple case above, I actually prefer DMD's messages, as there's simply less text for my eyes to read and brain to parse, so I can quickly spot where the problem is. I agree, though, that with longer argument lists, especially with const vs. non-const or template constraints, trying to figure out what's wrong could be at least frustrating.
 Templates with constraints are even worse.

 lll.d(3): Error: template std.algorithm.sorting.sort cannot 
 deduce function from argument types !()(int), candidates are:
 /home/me/d/dmd2/linux/bin32/../../src/phobos/std/algorithm/sorting.d(1830):   
    std.algorithm.sorting.sort(alias less = "a < b", SwapStrategy ss =
SwapStrategy.unstable, Range)(Range r) if ((ss == SwapStrategy.unstable &&
(hasSwappableElements!Range || hasAssignableElements!Range) || ss !=
SwapStrategy.unstable && hasAssignableElements!Range) &&
isRandomAccessRange!Range && hasSlicing!Range && hasLength!Range)


 What a mess! Just formatting that output might help, but I'd 
 especially love it if it told me which individual boolean 
 elements failed, passed, and were short-circuited. The compiler 
 knows this, it had to evaluate that to figure out it didn't 
 match, but it doesn't tell me.

 At a glance, can you even tell what I passed to the function?

 Bonus points would be it telling me why, for example, 
 `isInputRange` failed, but I understand that is an even bigger 
 problem to solve.
It's indeed painful, but I found UDAs to be useful in dealing with it. First, I'm sure you know Atila's concepts [1]. I also use UDAs in flod [2], so instead of checking whether the implementation satisfies a constraint, I only check if it's explicitly tagged with a specific UDA. Now, I immediately see whether it's a method that I forgot to implement or just a typo, instead of being forced to guess by a "missing overload" message.
 Of course, C++ doesn't have constraints so there's no 
 comparison there.


 Lastly, check this out:

 lll.d(5): Error: function lll.foo (Color c) is not callable 
 using argument types (Color)

 WTF, right? Well, I have a locally defined `struct Color` and 
 an imported one. Same name, but different type. The error 
 message doesn't tell me which one is which.
Yeah, that one was funny. :)
 These are the top 3 dmd error messages that bother me 
 regularly. At runtime, little drives me more nuts than 
 RangeError not telling me the index and the length. Again, it 
 knows, the code checked it, but it didn't report it.
Same with assertions. I usually end up adding wrappers like assertEqual, and the more I use them, the more I feel like switching to something like [3] or [4], as much as I normally prefer to keep the number of dependencies low. I think RangeError could be solved without much effort by changing the compiler/runtime interface at _d_arraybounds*. Assertions are probably harder. [1] http://forum.dlang.org/post/eoxerbkaowxpgjubhdqq forum.dlang.org [2] https://github.com/epi/flod/blob/develop/source/flod/package.d [3] https://code.dlang.org/packages/fluent-asserts [4] http://code.dlang.org/packages/unit-threaded
May 10
next sibling parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 05/10/2017 11:50 AM, Adrian Matoga wrote:
 On Wednesday, 10 May 2017 at 15:03:19 UTC, Adam D. Ruppe wrote:
 lll.d(5): Error: function lll.foo (Color c) is not callable using
 argument types (Color)

 WTF, right? Well, I have a locally defined `struct Color` and an
 imported one. Same name, but different type. The error message doesn't
 tell me which one is which.
Yeah, that one was funny. :)
It's not so funny when you're new to that error and don't already know to look for two types from different modules with the same name. :(
 Same with assertions. I usually end up adding wrappers like assertEqual,
 and the more I use them, the more I feel like switching to something
 like [3] or [4], as much as I normally prefer to keep the number of
 dependencies low.

 [3] https://code.dlang.org/packages/fluent-asserts
 [4] http://code.dlang.org/packages/unit-threaded
Unit-threaded rocks my world. First I've heard of fluent-asserts but it looks interesting.
May 10
prev sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 10 May 2017 at 15:50:06 UTC, Adrian Matoga wrote:
 In this simple case above, I actually prefer DMD's messages, as 
 there's simply less text for my eyes to read and brain to 
 parse, so I can quickly spot where the problem is.
Well, even here, I'd prefer a small tweak: lll.d(6): Error: none of the overloads of 'foo' match given: foo(int , double) lll.d(1): lll.foo(int a, int a) lll.d(2): lll.foo(int a, string s) The alignment would make it easier to eyeball the matches and options... though that fails on longer lines too. Another option is using colors (or something) to highlight which ones in the candidates matched and which didn't. The difference is small in a short case like this... but even here, I'd call it slightly better, and in a big case, it is much better.
 It's indeed painful, but I found UDAs to be useful in dealing 
 with it.
Oh, that's on the declaration side, but this error message is on the call side. Suppose I pass an input range to sort(). I prove it is an input range with UDAs or static asserts or whatever, yet the call to sort fails. Why? It is because sort requires more than just an input range, but just whate is difficult to determine from the error message. So a legible error message tells you WHAT you need to test on the declaration ("must be random access"), then the udas can handle those error messages (so like "it is not a random access range because opIndex is not implemented") Of course, the sort() function could check `isSortable` instead of everything it lists in its constraint... and I think I'd like that, but still, a more readable error message would be a big win. The llvm people are just annihilating us in the error messages and that's a bigger day-to-day boost than it seems. So yeah, we should do both: make the decls nicer with UDAs, but also make the error messages nicer for all cases. oh another class of error messages that suck: " nogc function cannot call non- nogc function map". but map is inferred so why did it fail? wrote this up in bugzilla: https://issues.dlang.org/show_bug.cgi?id=17374
 I think RangeError could be solved without much effort by 
 changing the compiler/runtime interface at _d_arraybounds*. 
 Assertions are probably harder.
yeah, I actually tried to implement it one time and failed though - the compiler code is a bit more fragile than I thought. Still shouldn't be too hard, if I had a few hours to spend on it I could prolly do it.
May 10
prev sibling next sibling parent reply zetashift <rskaraya gmail.com> writes:
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).
May 10
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 10/05/2017 7:20 PM, 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).
Well, I wouldn't be working on[0] and [1] if I didn't think D could be used for game dev. Yes it has some work to do to make it nice, but over all its workable. [0] http://spew.cf [1] https://github.com/rikkimax/ogl_gen
May 10
prev sibling parent JN <666total wp.pl> writes:
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 10
prev sibling next sibling parent Joakim <dlang joakim.fea.st> writes:
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?
iOS is possible, though that cross-compiler hasn't been updated in a year: https://github.com/smolt/ldc-iphone-dev/releases Cross-compiling for Android has been available for awhile, and I got JNI working late last year: https://github.com/joakim-noah/android/releases That game programmer mentions wanting more control over optimizing methods in Rust. Funnily enough, I've been messing with pragma(inline, true) just today to track down a bug related to inlining, and Johan added an attribute called optStrategy to ldc last summer, which lets you selectively turn on or off optimizations for a method: https://github.com/ldc-developers/ldc/pull/1637 Radu used it when debugging ldc on an ARMv5 microcontroller recently. Not available standardized across D compilers obviously, but could be some day.
May 10
prev sibling next sibling parent reply Lewis <musicaljelly gmail.com> writes:
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?
I've been developing a small 2D PC-only game in my free time over the last year or so (10 kLOC so far). It's very much still in the early stages, but I'll add some of my experiences here in case it's useful. For context, I'm a developer of 2.5 years at a medium-sized studio that ships full-price games. At work we use C++ (msvc) for the engine, Lua for scripting, and C# for tools. TLDR: You can totally make a game in D right now. However, it's definitely not ideal. Be ready to deal with untested tools/libraries, wrangling with how you call out to C libraries, and a couple hacks to the D source to make things work the way you want. PROS I'll skim this section, because you all know the pros of D at this point :) No header files, sane templates, way better introspection, the list goes on. D is one of the nicest programming languages I've had the pleasure of working in. It's not without its faults, but my experience so far is that it's the language I most want to be developing a game in right now. We'll see if Jai might take that throne some day, but I reserve judgement until I can actually get my hands on it, and even that might still be years out. 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. 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. Mago crashes/hangs regularly for me, doesn't step in and out of functions consistently (and you can't reposition the instruction pointer by dragging if you miss a function call you want to re-run), is inconsistant about which variables I can see and which I can't, and lacks features I miss greatly (like data breakpoints). This is *by far* my biggest pain point. I'd like to look at it at some point and try to improve some of the low-hanging fruit, but debugging a debugger is a daunting proposition. 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. The GC. This is an issue in games for reasons already tread many times over. It's lower on my list because it's relatively straightforward for me to intercept GC calls and do my own memory management instead. I've hacked in a setup that lets me swap allocators at runtime. For example, I can add a line at the top of a scope that says "for the duration of this scope, allocate into the scrapheap" (a bump-the-pointer stack that gets wiped at the end of each frame). I currently use the GC by default, and manually specify an allocator to use anywhere I'm generating excessive garbage, but this strategy will likely change as development continues and performance constraints start becoming more strict. Library support. Basically the same as mentioned in the Rust article. I regularly try out libraries where I find a critical bug within an hour of using the library. I've used libraries (plural) that interface to C but use the wrong calling convention, so before I discovered the problem, every function I called was a crapshoot as to whether or not some subtle misbehaviour or outright crash would occur. For reference, the libraries I'm using are: - SFML (graphics/windowing, misc utilities) - FMOD (audio) - dear imgui (debug UI) - msgpack-d (save game/state serialization) - OpenGL (just tiny bits here and there for stuff SFML and imgui don't handle out of the box) - speech4d (TTS for placeholder dialogue, I heavily modified this library to fix some critical bugs and make it work better for my purposes) Any questions, ask away!
May 10
parent reply evilrat <evilrat666 gmail.com> writes:
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...
May 10
parent reply Lewis <musicaljelly gmail.com> writes:
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 11
parent reply evilrat <evilrat666 gmail.com> writes:
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 11
parent reply Lewis <musicaljelly gmail.com> writes:
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 11
parent Marco Leise <Marco.Leise gmx.de> writes:
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
May 14
prev sibling parent reply Vadim Lopatin <coolreader.org gmail.com> writes:
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
parent evilrat <evilrat666 gmail.com> writes:
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