Re: D for Game Development
On Wednesday, 12 August 2015 at 14:57:17 UTC, jmh530 wrote: Regardless, my point is more about the importance of a seamless installation on Windows than necessarily about what is required or not. This isn't unique to D. I just tried to install the Clang Windows binary and I got a message about MSVC integration failing. I have Visual Express 2008, The express versions of Visual Studio do not include everything needed to do Windows development. You also need download a version of the Windows SDK. My recommendation is that you just uninstall the Express version and install Visual Studio Community 2013. Then go ahead and remove every trace of DMD from your system. Make sure it's not in your system PATH. After that, download the latest installer and run it. It will find your VS installation automatically and will configure sc.ini appropriately. It has worked for me every time I've tried it. I don't think DMD is able to work with 2015 just yet, because of the C Runtime changes. I had trouble with it when VS 2015 was first released, so I deleted it and reverted to 2013.
Re: D for Game Development
On Wednesday, 12 August 2015 at 13:32:10 UTC, kink wrote: Afaik DMD for Win64 requires the MS linker, so good luck without Visual Studio then. Same goes for LDC on Win64, although an LLVM COFF linker is under development. Serious system programming on Windows without MSVC and its C runtime? Not really an option; MinGW appears to be a dead end and never really fitted the Windows eco-system. MSVC toolchain is required to link 3rd-party C++ code compiled with MSVC, mingw links c runtime just fine.
Re: D for Game Development
On Wednesday, 12 August 2015 at 13:32:10 UTC, kink wrote: Afaik DMD for Win64 requires the MS linker, so good luck without Visual Studio then. Same goes for LDC on Win64, although an LLVM COFF linker is under development. Serious system programming on Windows without MSVC and its C runtime? Not really an option; MinGW appears to be a dead end and never really fitted the Windows eco-system. Well I'm not sure what percent serious system programming is done by other people, but I don't do any. I'll take your word that the MS linker is required. Regardless, my point is more about the importance of a seamless installation on Windows than necessarily about what is required or not. It is easy to get started with DMD on Windows, roughly equivalent to python or R (what I more commonly program in). This makes it easy for people to get started learning D and playing around with RDMD. That's a good thing. By contrast, it seems quite complicated to get LDC or GDC working on Windows. I see explanations of how to build from source. There also appears to be a binary on the github page, but I haven't gotten it working (I didn't exactly try that hard though). I just hope that if DMD is replaced or moved to using LLVM, then care is taken to ensure that installation remains as simple as it currently is. This isn't unique to D. I just tried to install the Clang Windows binary and I got a message about MSVC integration failing. I have Visual Express 2008, so I figure maybe a newer version is required, but it doesn't say anywhere on the download page what version is required (the building page says VS 2013 is, but shouldn't the download page clearly explain that?). Moreover, it doesn't bring up any kind of option for me to download and install what is missing. I would consider the installation of Lyx to be a good example of a seamless installation. Lyx requires MiKTeX, so if it detects it's missing during installation, then it will download it. It might also update your version of MiKTeX also.
Re: D for Game Development
On 2015-08-11 09:08, Timothee Cour via Digitalmars-d wrote: on OSX I only see libphobos2.a (including dmd 2.068) It's not supported on OS X. -- /Jacob Carlborg
Re: D for Game Development
On Wednesday, 12 August 2015 at 14:57:17 UTC, jmh530 wrote: Well I'm not sure what percent serious system programming is done by other people, but I don't do any. I understand your points. I meant to say that D is a system programming language (too), so it's tightly coupled to some internals of the OS. And Windows being a proprietary OS, Visual Studio or more precisely at least its runtime is likely to be required in the future as well. Almost ;) proper support for Win64 in LDC is about to be completed with the next release. It will most likely require Visual Studio 2015. But that's about it, you'll just need to extract an LDC archive. When invoking ldc2.exe, you'll need to make sure some environment variables are properly set up (e.g., by using a Visual Studio command prompt), for it to find the linker, libs etc. Last time I built clang (from source, using Visual Studio) I was amazed by how painless that was. LLVM requires VS 2013 atm (at least for building), but Windows/MSVC support is still being finalized (native MSVCRT exception handling etc.). VS 2008 is really quite old by now, so I'd really recommend upgrading (VS 2015 Community is free btw).
Re: D for Game Development
On Tuesday, 11 August 2015 at 00:56:57 UTC, Manu wrote: On 11 August 2015 at 01:15, jmh530 via Digitalmars-d digitalmars-d@puremagic.com wrote: One big positive for DMD is that it is very easy to install on Windows. Just about anyone can get up and running quite easily. It doesn't require the installation of MSVC (which I can't stand) or Min-GW at all. If DMD and LDC are sort of merged in the way that you say, I just hope care is taken to ensure that it is easy for people to get started with it. I think some care would be taken to bundle the distribution so it's both minimal and convenient for users to install and get started with. Afaik DMD for Win64 requires the MS linker, so good luck without Visual Studio then. Same goes for LDC on Win64, although an LLVM COFF linker is under development. Serious system programming on Windows without MSVC and its C runtime? Not really an option; MinGW appears to be a dead end and never really fitted the Windows eco-system.
Re: D for Game Development
On 8/11/2015 12:57 AM, Benjamin Thaut wrote: Also the front end transition from C++ to D hits me hard also. It's going to hit everyone hard who works on the front end.
Re: D for Game Development
On Monday, 10 August 2015 at 05:23:20 UTC, Walter Bright wrote: On 8/9/2015 9:26 PM, Tofu Ninja wrote: On Sunday, 9 August 2015 at 20:51:32 UTC, Walter Bright wrote: On 8/9/2015 4:38 AM, Manu via Digitalmars-d wrote: On 9 August 2015 at 15:31, Walter Bright via Digitalmars-d I agree, and now we ship a Phobos DLL, resolving that issue. Really? Where is it? (I can't see it in the distribution). Should be in the bin directory. There is no Phobos dll, only Phobos lib. There's linux/lib32/libphobos2.so, for example. But that is linux. You can't say phobos dll because everyone then expects dlls to work on windows, which still isn't the case. Its correct that we have a shared library version of phobos on linux, but a shared library version of phobos on windows is still in the future. I'm currently working on it, but there are so many issues with the language design, the export keyword, the module level visibility system the unittests etc etc that its going to take some more time. Also the front end transition from C++ to D hits me hard also.
Re: D for Game Development
On Monday, 10 August 2015 at 19:31:55 UTC, David Gileadi wrote: …[insert your language here] has a long way to go… :) Yes, the real culprit is getting really good IDE support, and for that one need to write a high quality analyzer that can provide more information than a compiler. As far as the language goes, I'd prefer a minimalistic core language backed up with a normalizing and caching solver. I don't really think fast initial compile time is all that important, if he compiler caches intermediate results intelligently I think one can get decent compilation speeds still.
Re: D for Game Development
On Monday, 10 August 2015 at 19:34:26 UTC, rsw0x wrote: On Monday, 10 August 2015 at 19:31:55 UTC, David Gileadi wrote: On 8/10/15 12:25 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: [...] …[insert your language here] has a long way to go… :) Which is why I think people are attracted towards D. It's very close to being there. The large elephant in the room is the garbage collector. Every way to work around it feels like a massive, ugly hack. Yes, it is not a good fit for D. Although, I find the Pony-lang approach interesting, but that is an actor language so it should not be compared to D, but to vibe.d. Pony uses a per heap GC, a cross actor GC, and actor collection (collecting the whole actor and heap when the actor cannot receive more messages). Each actor (fiber in D) does not have a stack, the stack is per thread so I believe you yield when the stack has been unwound, they only use C-ABI when calling C functions. But they also have an advanced pointer type system that can distinguish between at least 6 different reference-aliasing situations (or was it 12?). https://www.youtube.com/watch?v=KvLjy8w1G_U Anyway, it is refreshing. Maybe D can pick up some ideas from Pony.
Re: D for Game Development
On Sun, Aug 9, 2015 at 12:33 AM, Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 8/9/2015 12:18 AM, Iain Buclaw via Digitalmars-d wrote: If the libraries were shared, this would reduce linking time, which in various benchmarks I've done is where most small projects spend the majority of their time doing. But no one has as of yet come up with a feasibly implementable idea to do that. We ship Phobos as a shared library on Linux, OSX and FreeBSD. on OSX I only see libphobos2.a (including dmd 2.068)
Re: D for Game Development
On 10/08/15 14:25, Manu via Digitalmars-d wrote: I wonder how .so files to work on those platforms? I expect iOS would leverage OSX support almost verbatim? Shared libraries are not supported on OS X, at least not with DMD, not sure about LDC. On Android, all binaries are .so files; but I fear there will be a problem when a program is comprised of many .so files working together... will that mean as many instances of phobos and druntime? On Posix, when using shared libraries, there's only one shared Phobos and druntime. I assume it would be implemented the same way on Andriod. -- /Jacob Carlborg
Re: D for Game Development
On Sunday, 9 August 2015 at 02:41:00 UTC, Manu wrote: People keep talking about Rust, I'm thinking of giving it a shot. I feel there is something wrong with the Rust and Go agendas, both languages have interesting features, but then they seem to get too moralistic/political. Is there a way to turn off bounds-checks in Rust? Apparently not? And apparently the same misguided obsession with iterators (aka ranges): https://users.rust-lang.org/t/c-has-vector-n-value-c-has-calloc-rust-has-uh/146 …Rust has a long way to go… …Go is frozen… …D has a long way to go… …C++ is fit, moving and annoying… I guess the only way forward is to write your own language.
Re: D for Game Development
On Monday, 10 August 2015 at 14:13:53 UTC, Manu wrote: I really hope this is a top-priority goal for the switch to DDMD. My understanding is that 2.069 is supposed to bring DDMD support. I think there has been a lot of heated discussion about something that really isn't that far away. Nevertheless, I think you've made your case well about sort of merging LDC and DMD. One big positive for DMD is that it is very easy to install on Windows. Just about anyone can get up and running quite easily. It doesn't require the installation of MSVC (which I can't stand) or Min-GW at all. If DMD and LDC are sort of merged in the way that you say, I just hope care is taken to ensure that it is easy for people to get started with it.
Re: D for Game Development
On Monday, 10 August 2015 at 14:44:42 UTC, Jacob Carlborg wrote: Shared libraries are not supported on OS X, at least not with DMD, not sure about LDC. Shared libraries works well here on OS X with LDC 0.15.2-beta2 (and only with LDC).
Re: D for Game Development
On 8/10/15 12:25 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: On Sunday, 9 August 2015 at 02:41:00 UTC, Manu wrote: People keep talking about Rust, I'm thinking of giving it a shot. I feel there is something wrong with the Rust and Go agendas, both languages have interesting features, but then they seem to get too moralistic/political. Is there a way to turn off bounds-checks in Rust? Apparently not? And apparently the same misguided obsession with iterators (aka ranges): https://users.rust-lang.org/t/c-has-vector-n-value-c-has-calloc-rust-has-uh/146 …Rust has a long way to go… …Go is frozen… …D has a long way to go… …C++ is fit, moving and annoying… I guess the only way forward is to write your own language. …[insert your language here] has a long way to go… :)
Re: D for Game Development
On Monday, 10 August 2015 at 19:34:26 UTC, rsw0x wrote: On Monday, 10 August 2015 at 19:31:55 UTC, David Gileadi wrote: On 8/10/15 12:25 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: [...] …[insert your language here] has a long way to go… :) Which is why I think people are attracted towards D. It's very close to being there. The large elephant in the room is the garbage collector. Every way to work around it feels like a massive, ugly hack. I am hoping once std.allocators gets done, language support for it will get added. Some way to get new and delete to forward to specific allocators. And some way to define a scope that uses an allocator such that every thing in that scope that gets allocated uses that allocator, including allocations down the call tree.
Re: D for Game Development
On Monday, 10 August 2015 at 20:20:36 UTC, Tofu Ninja wrote: On Monday, 10 August 2015 at 19:34:26 UTC, rsw0x wrote: On Monday, 10 August 2015 at 19:31:55 UTC, David Gileadi wrote: On 8/10/15 12:25 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: [...] …[insert your language here] has a long way to go… :) Which is why I think people are attracted towards D. It's very close to being there. The large elephant in the room is the garbage collector. Every way to work around it feels like a massive, ugly hack. I am hoping once std.allocators gets done, language support for it will get added. Some way to get new and delete to forward to specific allocators. overload new. It's deprecated but I used it the entire time I was required to use D without Phobos because it was just a massive pain. And some way to define a scope that uses an allocator such that every thing in that scope that gets allocated uses that allocator, including allocations down the call tree. This exists, you can use a proxy GC.
Re: D for Game Development
On Monday, 10 August 2015 at 19:25:45 UTC, Ola Fosheim Grøstad wrote: On Sunday, 9 August 2015 at 02:41:00 UTC, Manu wrote: People keep talking about Rust, I'm thinking of giving it a shot. I feel there is something wrong with the Rust and Go agendas, both languages have interesting features, but then they seem to get too moralistic/political. Is there a way to turn off bounds-checks in Rust? Apparently not? To keep it short, this is the reason I am not using Rust.
Re: D for Game Development
On Monday, 10 August 2015 at 19:31:55 UTC, David Gileadi wrote: On 8/10/15 12:25 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: [...] …[insert your language here] has a long way to go… :) Which is why I think people are attracted towards D. It's very close to being there. The large elephant in the room is the garbage collector. Every way to work around it feels like a massive, ugly hack.
Re: D for Game Development
On 11 August 2015 at 01:15, jmh530 via Digitalmars-d digitalmars-d@puremagic.com wrote: On Monday, 10 August 2015 at 14:13:53 UTC, Manu wrote: I really hope this is a top-priority goal for the switch to DDMD. My understanding is that 2.069 is supposed to bring DDMD support. I think there has been a lot of heated discussion about something that really isn't that far away. Nevertheless, I think you've made your case well about sort of merging LDC and DMD. One big positive for DMD is that it is very easy to install on Windows. Just about anyone can get up and running quite easily. It doesn't require the installation of MSVC (which I can't stand) or Min-GW at all. If DMD and LDC are sort of merged in the way that you say, I just hope care is taken to ensure that it is easy for people to get started with it. I think some care would be taken to bundle the distribution so it's both minimal and convenient for users to install and get started with.
Re: D for Game Development
On Sunday, 9 August 2015 at 05:31:41 UTC, Walter Bright wrote: I agree, and now we ship a Phobos DLL, resolving that issue. I think most people these days associate DLL exclusively with windows. I certainly do.
Re: D for Game Development
On Monday, 10 August 2015 at 01:26:44 UTC, Walter Bright wrote: On 8/9/2015 2:03 PM, ponce wrote: Once I get back to Windows I will post the report. Thank you. https://issues.dlang.org/show_bug.cgi?id=14896
Re: D for Game Development
On 10/08/15 10:43, John Colvin wrote: I think most people these days associate DLL exclusively with windows. I certainly do. Exactly. DLL on Windows and shared library on Posix. Although I think it's dynamic library on OS X. -- /Jacob Carlborg
Re: D for Game Development
On 10 August 2015 at 12:29, Jacob Carlborg via Digitalmars-d digitalmars-d@puremagic.com wrote: On 10/08/15 10:43, John Colvin wrote: I think most people these days associate DLL exclusively with windows. I certainly do. Exactly. DLL on Windows and shared library on Posix. Although I think it's dynamic library on OS X. So many competing standards! We should invent a new name for them that will be universally used by all platforms. https://xkcd.com/927
Re: D for Game Development
On 8/10/2015 3:32 AM, ponce wrote: On Monday, 10 August 2015 at 01:26:44 UTC, Walter Bright wrote: On 8/9/2015 2:03 PM, ponce wrote: Once I get back to Windows I will post the report. Thank you. https://issues.dlang.org/show_bug.cgi?id=14896 Good!
Re: D for Game Development
On 10 August 2015 at 05:00, Jacob Carlborg via Digitalmars-d digitalmars-d@puremagic.com wrote: On 09/08/15 13:38, Manu via Digitalmars-d wrote: In fact, we've been discussing for a few months that we'd have have another very promising opportunity to use D at work in a really appropriate context if I could rely on Android and iOS appearing within 6-12 months or so. There's been quite a lot of activities lately in improving the Andriod and iOS support by Joakim and Dan. Indeed, I've been watching with great interest. I wonder how .so files to work on those platforms? I expect iOS would leverage OSX support almost verbatim? On Android, all binaries are .so files; but I fear there will be a problem when a program is comprised of many .so files working together... will that mean as many instances of phobos and druntime?
Re: D for Game Development
On 10 August 2015 at 06:51, Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 8/9/2015 4:38 AM, Manu via Digitalmars-d wrote: On 9 August 2015 at 15:31, Walter Bright via Digitalmars-d But waiting for someone else to discover the same thing on some other piece of code means you'll be waiting a long time. I understand, but that's not sustainable. We can't be in a situation where I'm at work with a deadline, and I need to invoke the community to address a codegen issue that's blocking a release. Unexpected surprises like that with unknown/long turn-around times aren't a practical commitment. It will NEVER get fixed if you don't file bug reports, and you'll continue to be frustrated (and me too, because there's NOTHING I can do to improve things based on what you post here). I think you misunderstood my point again. I'm trying to say that it's precarious to make a commitment to something you know (or suspect) has unknown issues. The practical outcome is that there's a strong pressure against making such a commitment (ie, not use D), and then certainly no bugs will be found or reported. The thing is, whatever bugs may or may not be discovered are almost certainly already 'fixed' in LLVM/GCC. There's no work to do there, those backends have legions of developers working on them every day. There is literally nothing DMD can ever to do catch up. It may be sad to admit, but it's just how it is. Maintaining and fixing the DMD codegen just takes time away from other things (I understand you argue that it's very little time in practical terms, but that's not really a great argument; it just admits that DMD is not progressing), and it has lead to a fragmented experience, which is the biggest practical issue I've been finding with D in recent times. DMD as a frontend to LLVM seems like the most practical and reliable option as the default offering. You did a lot of work to make debugging in DMD work well, and the work really paid off! DMD is the only windows compiler that produces a workable debugging experience. The consequence of that though, is to have created a situation where people necessarily rely on a tooling situation where they use 2 different compilers for debug and release, and because the other compilers are always a few versions out of date, you're behind on all the latest developments. If that effort to reverse engineer Microsoft's debuginfo were contributed to LLVM, almost every native developer, D or any language otherwise, would all be better off. So the point is, many of my modern D issues aren't issues that I can bug. I can't log on bugzilla: using DMD for debug and LDC for release builds sucks; fix debuginfo in LLVM. That's obviously outside the scope of DMD, but I suggest that maybe it shouldn't be? DMD has become fairly reliable for me, I don't fight it much anymore (or maybe I'm just much better at knowing what works well?), but the larger ecosystem seems to be the biggest cause of friction now. These aren't problems that are easily directed to a particular bug tracker, they represent a conjunction of tooling, and maybe strategies need to be considered where core developers are aware of these issues. Leveraging the world of LLVM tooling is the most practical and bang-for-buck solution I can imagine. The other advantage of core dev using an LLVM backend, would be that port/architecture related bugs would become the business of core development. CI would necessarily have to build for many architectures, and PR's blocked until they work on ARM/iOS/etc. Last time I was concerned with this, x87 was destroying DMD performance. Floats were x87, moved to XMM (according to x64 ABI) when passed to functions, then moved back into x87 on the other side when they're operated on. Float code was overwhelmed with shuffling values between registers. Basically all hot code is float code in my line of work. All I really need is a bugzilla issue with just ONE example of needlessly using the x87 where a SIMD instruction would be better. Like I said, it's not a problem I have today. I was answering a question and discussing historical problems. I think Ethan was in discussions with you about this some time back? It was a problem at the time I left Remedy. As I recall, I heard from Ethan just once since you left. That's a bummer. Sorry to hear that. I should catch up with those guys and see where they're at. In contrast, I hear regularly from Sociomantic when they've got an issue, and I'm able to consequently help them be successful with D. Thing is, most of my 2015 blockers are outside the scope of DMD unless DMD decides to adopt LLVM as it's backend. DMD is in pretty good shape these days, it's just a shame it can't be used to compile software that runs on modern computers (arm, iOS, Android, web). We all need Android, iOS, Emscripten. We need equal confidence the ports work well as that DMD is released to a high quality. I think they should be
Re: D for Game Development
On 09-Aug-2015 12:33, Manu via Digitalmars-d wrote: On 9 August 2015 at 13:34, Rikki Cattermole via Digitalmars-d digitalmars-d@puremagic.com wrote: On 9/08/2015 2:40 p.m., Manu via Digitalmars-d wrote: [snip] Even though it is hard for you to still be here, I hope you do continue to help D grow. This is a good community, we just need time before real adoption. E.g. we are only just now starting to unify projects. Cheers, but don't get me wrong; I've barely contributed anything of value other than advocacy and little bits and pieces here and there. I don't deserve any credit, I just complain about things that make it impossible for me to get on with my work. std.simd though would be awesome to have ;) You'll know D is on good shape when you don't hear a peep from me anymore ;) -- Dmitry Olshansky
Re: D for Game Development
On 09/08/15 11:04, Johannes Pfau wrote: Do you support shared libraries on OSX with that emulated TLS system for all use cases? Shared libraries are not supported at all on OS X. -- /Jacob Carlborg
Re: D for Game Development
On 9 August 2015 at 15:31, Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 8/8/2015 7:40 PM, Manu via Digitalmars-d wrote: 1. DMD has unsatisfactory codegen for anything other than debug builds. Do you mean the codegen is slower? But consider that the bottleneck in most programs is a small section of code. Taking a good look at the generated code for that and comparing with another compiler can often hint at an easy improvement to dmd that can address that bottleneck. But waiting for someone else to discover the same thing on some other piece of code means you'll be waiting a long time. I understand, but that's not sustainable. We can't be in a situation where I'm at work with a deadline, and I need to invoke the community to address a codegen issue that's blocking a release. Unexpected surprises like that with unknown/long turn-around times aren't a practical commitment. Last time I was concerned with this, x87 was destroying DMD performance. Floats were x87, moved to XMM (according to x64 ABI) when passed to functions, then moved back into x87 on the other side when they're operated on. Float code was overwhelmed with shuffling values between registers. Basically all hot code is float code in my line of work. I think Ethan was in discussions with you about this some time back? It was a problem at the time I left Remedy. Also, I think one of the big issues is the optimiser in general. The inliner's just not fantastic, and D depends on it perhaps even more than C++, especially when using the modern lazy code style. I'm sure I can hand-assist DMD to produce the assembly I expect for some hot function with some work, but traditional hand-assisted code generation all falls apart when you start stacking lazy-ranges and generally using the modern D style. DMD's backend has almost no development, it's advancing at near-zero velocity compared to LLVM. We need to get out of the situation where LDC and GDC are perpetually 1-2 versions behind. Incidentally, In my recent (dead-end) experience with LDC, I get endless ICE's whenever I try to do anything mildly complex. When you have your Debug and Release build straddling language versions and compilers with different ICE characteristics, it's just not a practical workflow. Only green-fields projects or the simplest of simple apps can hope not to trigger bugs constantly in that environment. 2. DMD generates x87 code, and uses real everywhere. Less so now than it used to. For float and double, it uses SIMD. Okay, is this fairly recent? My last set of comprehensive tests are probably out of date. We can't be generating new x87+real instructions in 2015. It's deprecated hardware! x87 works on every x86 CPU, and I doubt it will ever go away, deprecated or not. Why was it a problem for you? Massive register swapping was the issue. I'd like to think register swapping should never be implicitly generated unless I *explicitly* type the real keyword, I don't want to see x87 opcodes. 2. LDC has a lot more bugs than DMD (which still has quite a few bugs), and the Windows build is new and even more immature still. 3. LDC has no debuginfo. **biggest practical issue by far!** 4. LDC/GDC are always a few versions behind DMD. This creates an awkward/almost-impossible situation when you rely on DMD to build debug code, and LDC to build releasable code. Depending on 2 flaky compilers is even less fun than one. 5. DLL's were really flakey at the time, I'm not sure how they are now, but I'm concerned they may not be much better. 6. Shared druntime; we were loading D code from DLL's, lots of them. It's not really reasonable for each DLL to have it's own druntime instance, they need to share one provided by the host app. I agree, and now we ship a Phobos DLL, resolving that issue. Really? Where is it? (I can't see it in the distribution). 7. D binaries are *gigantic*, I don't know why. D seems to link the world, and I'm certain that most of the crap that's linked is never referenced or executed... it just makes gigantic binaries for some reason, even with line-for-line translations of C/C++ code. That's not real good on games consoles where icache is king. Yes, that's an ongoing problem. I need to spend some time on that one. That'll be nice. Bear in mind, I'm just giving an account here of why we were unable to produce blog posts and hype from our experience using D at Remedy, at least up until the time I left, I'm not sure where they are with it now. I hope it didn't fizzle, but there were more problems than we initially hoped for, and I think that damaged confidence a lot. In the short term? I struggle to imagine the ddmd transition taking less than 3-6 months. Personally, if I were to pin a #1 ticket related to my 2015 workload, it would be Emscripten support, and LDC as default D compiler ;) I tried to use D in my current workplace on 3 occasions now, and ran into a different set of problems.
Re: D for Game Development
On Sunday, 9 August 2015 at 10:21:06 UTC, NVolcz wrote: There seems like there are many problems with DMD and many problems asked here in the newsgroup are answered with don't use DMD. Maybe it's time to deprecate DMD? Maybe at least make sure it's up to date with the ecosystem. Sorry didn't read the whole thread before posting! Also I meant to write bring LDC (and/or GDC) into the release cycles
Re: D for Game Development
On 09/08/15 09:33, Walter Bright wrote: We ship Phobos as a shared library on Linux, OSX and FreeBSD. No on OS X. -- /Jacob Carlborg
Re: D for Game Development
On Sunday, 9 August 2015 at 02:41:00 UTC, Manu wrote: snip / It's not so much language problems, it's tooling problems. It's the most important and perhaps most neglected aspect of the D ecosystem. 1. DMD has unsatisfactory codegen for anything other than debug builds. 2. DMD generates x87 code, and uses real everywhere. We can't be generating new x87+real instructions in 2015. It's deprecated hardware! 2. LDC has a lot more bugs than DMD (which still has quite a few bugs), and the Windows build is new and even more immature still. 3. LDC has no debuginfo. **biggest practical issue by far!** 4. LDC/GDC are always a few versions behind DMD. This creates an awkward/almost-impossible situation when you rely on DMD to build debug code, and LDC to build releasable code. Depending on 2 flaky compilers is even less fun than one. snip / There seems like there are many problems with DMD and many problems asked here in the newsgroup are answered with don't use DMD. Maybe it's time to deprecate DMD? Maybe at least make sure it's up to date with the ecosystem.
Re: D for Game Development
On 9 August 2015 at 20:04, Dmitry Olshansky via Digitalmars-d digitalmars-d@puremagic.com wrote: On 09-Aug-2015 12:33, Manu via Digitalmars-d wrote: On 9 August 2015 at 13:34, Rikki Cattermole via Digitalmars-d digitalmars-d@puremagic.com wrote: On 9/08/2015 2:40 p.m., Manu via Digitalmars-d wrote: [snip] Even though it is hard for you to still be here, I hope you do continue to help D grow. This is a good community, we just need time before real adoption. E.g. we are only just now starting to unify projects. Cheers, but don't get me wrong; I've barely contributed anything of value other than advocacy and little bits and pieces here and there. I don't deserve any credit, I just complain about things that make it impossible for me to get on with my work. std.simd though would be awesome to have ;) Yeah, I keep coming back to it, and getting myself stuck with various troubles making it work good. I'm perpetually unhappy with my code, and I just need a really good block of time to get through it. If people want to review std.color and help get that off my short-list, I promise I'll make std.simd my top priority :P I also haven't had need for it in my recent work, so it's not being motivated by necessity since I haven't been game-dev-ing much.
Re: D for Game Development
On 9 August 2015 at 13:34, Rikki Cattermole via Digitalmars-d digitalmars-d@puremagic.com wrote: On 9/08/2015 2:40 p.m., Manu via Digitalmars-d wrote: [...] Don't worry about it! But I see your point. All we can do is truck on. You will enjoy my latest blog post I think[0]. I reiterate one thing, if it's hard, it's probably wrong. So, lets make things easy. Build a wide range a libraries to make certain programs easy to write. Something I'd like to say is that I do really appreciate you and your work. If I could I would love to learn from you directly. I cannot give a higher respect or appreciation then that. Even though it is hard for you to still be here, I hope you do continue to help D grow. This is a good community, we just need time before real adoption. E.g. we are only just now starting to unify projects. Cheers, but don't get me wrong; I've barely contributed anything of value other than advocacy and little bits and pieces here and there. I don't deserve any credit, I just complain about things that make it impossible for me to get on with my work. You'll know D is on good shape when you don't hear a peep from me anymore ;)
Re: D for Game Development
Am Sun, 9 Aug 2015 02:17:11 -0700 schrieb Walter Bright newshou...@digitalmars.com: On 8/9/2015 2:07 AM, Johannes Pfau wrote: DMD has the advantage that whenever a frontend pull request requires glue layer changes you get at and once by the contributor. But for LDC and GDC the glue layer changes have to be implemented by GDC/LDC devs. If LDC were the default, then the GDC devs would still have to do the same work. Sure. I'm not arguing that LDC or GDC should be the default, just wanted to explain why we could really need some more contributors for GDC/LDC ;-)
Re: D for Game Development
On 8/9/2015 2:33 AM, Johannes Pfau wrote: Sure. I'm not arguing that LDC or GDC should be the default, just wanted to explain why we could really need some more contributors for GDC/LDC ;-) We could use more contributors in general!
Re: D for Game Development
On 8/9/2015 2:25 AM, Iain Buclaw via Digitalmars-d wrote: Now we have the testsuite, which seems to be a good enough gauge for finding problems. However if there's been a change (eg: refactor) between what codegen is lowered in the frontend vs. glue, then it becomes a commit hunt trawling through thousands of changes to work out which one is relevant to the new wrong-code-on-previously-working test. One day turns into a week, turns into a month, turns into half a year. Would git bisect help with that?
Re: D for Game Development
On 9 Aug 2015 11:35 am, Johannes Pfau via Digitalmars-d digitalmars-d@puremagic.com wrote: Am Sun, 9 Aug 2015 02:17:11 -0700 schrieb Walter Bright newshou...@digitalmars.com: On 8/9/2015 2:07 AM, Johannes Pfau wrote: DMD has the advantage that whenever a frontend pull request requires glue layer changes you get at and once by the contributor. But for LDC and GDC the glue layer changes have to be implemented by GDC/LDC devs. If LDC were the default, then the GDC devs would still have to do the same work. Sure. I'm not arguing that LDC or GDC should be the default, just wanted to explain why we could really need some more contributors for GDC/LDC ;-) I'd just like to add (before I disappear for the day). That I spent the first 4 years developing gdc on a netbook which had a single core Atom chip clocked at 1.6ghz, with 4GB memory (upgraded from 2GB after building libphobos unittester started consuming far too much memory). Just incase anyone pulls out the 'takes too long to build' rabbit from their hat. Iain.
Re: D for Game Development
On 9 August 2015 at 07:31, Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 8/8/2015 7:40 PM, Manu via Digitalmars-d wrote: 1. DMD has unsatisfactory codegen for anything other than debug builds. Do you mean the codegen is slower? But consider that the bottleneck in most programs is a small section of code. Taking a good look at the generated code for that and comparing with another compiler can often hint at an easy improvement to dmd that can address that bottleneck. But waiting for someone else to discover the same thing on some other piece of code means you'll be waiting a long time. Sometimes just using the wrong CPU can have adverse effects: https://issues.dlang.org/show_bug.cgi?id=5100 2. DMD generates x87 code, and uses real everywhere. Less so now than it used to. For float and double, it uses SIMD. We can't be generating new x87+real instructions in 2015. It's deprecated hardware! x87 works on every x86 CPU, and I doubt it will ever go away, deprecated or not. Why was it a problem for you? I know that at least for the benefit of std.math, we should allow any precision without expensive casting to and from real, which has been found to be a performance problem on various benchmarks (GDC, LDC, DMD, doesn't matter). Iain.
Re: D for Game Development
On Sunday, 9 August 2015 at 05:18:33 UTC, rsw0x wrote: On Sunday, 9 August 2015 at 02:41:00 UTC, Manu wrote: ... This pretty much hit the nail on the head on why dmd needs deprecated. I'm tired of seeing 'BUT IT WORKS ON WINDOWS' as an excuse. I don't care if it works on windows, it produces code slower than interpreted lua. Exactly what use is that? It may as well not work on windows at all as far as release builds are concerned. dmd not being deprecated continues the cycle of gdc/ldc lagging versions behind and being understaffed in manpower. I think another point to look at is how far gdc and ldc have come while still having so few people working on them. Clearly they are able to get more done faster because they can leverage the work of the llvm and gcc devs. Seems silly that the majority of our talent is focused on dmd when it is the slowest of the bunch. D's not made here syndrome strikes again! Also I really wish we had 1 main editor that was THE D editor. Something that was officially maintained and packaged with the rest of D. VisualD is cool, but not cross platform. monoD is nice, but no windows debugging support. DDT is also nice, it says it can do debugging in windows, but I was never been able to get it to work. They all have problems. If I had to vote, I would vote for monoD or DDT as they are both the closest to being complete solutions. But one really needs to be the focus and packaged with D, make it complete and let the others die. D debugging is in a laughable state. It really sucks and it seems to not be a concern at all by the core D people. That alone is a huge problem. If only we could get a cross platform D debugger that just worked and was officially maintained. Again tooling is D's biggest problem. Just my 2c
Re: D for Game Development
On 9 August 2015 at 08:36, Tofu Ninja via Digitalmars-d digitalmars-d@puremagic.com wrote: On Sunday, 9 August 2015 at 05:18:33 UTC, rsw0x wrote: On Sunday, 9 August 2015 at 02:41:00 UTC, Manu wrote: ... This pretty much hit the nail on the head on why dmd needs deprecated. I'm tired of seeing 'BUT IT WORKS ON WINDOWS' as an excuse. I don't care if it works on windows, it produces code slower than interpreted lua. Exactly what use is that? It may as well not work on windows at all as far as release builds are concerned. dmd not being deprecated continues the cycle of gdc/ldc lagging versions behind and being understaffed in manpower. I think another point to look at is how far gdc and ldc have come while still having so few people working on them. Clearly they are able to get more done faster because they can leverage the work of the llvm and gcc devs. Seems silly that the majority of our talent is focused on dmd when it is the slowest of the bunch. D's not made here syndrome strikes again! Also I really wish we had 1 main editor that was THE D editor. Something that was officially maintained and packaged with the rest of D. VisualD is cool, but not cross platform. monoD is nice, but no windows debugging support. DDT is also nice, it says it can do debugging in windows, but I was never been able to get it to work. They all have problems. If I had to vote, I would vote for monoD or DDT as they are both the closest to being complete solutions. But one really needs to be the focus and packaged with D, make it complete and let the others die. (Neo)Vim? :o) D debugging is in a laughable state. It really sucks and it seems to not be a concern at all by the core D people. That alone is a huge problem. If only we could get a cross platform D debugger that just worked and was officially maintained. Not sure which environment you refer to, but most times I've been pinged into discussion, the problem was less the debugger (GDB) and more the compiler (DMD) which does not produce enough (or wrong) information to even allow some basics to work properly. So your idea of a debugger tool to fix all problems is a non-starter project because from DMD there is not much information present to begin with. You can't magically build a debug environment that represents a program state in its entirety from nothing! Iain.
Re: D for Game Development
On Sunday, 9 August 2015 at 06:59:15 UTC, Iain Buclaw wrote: On 9 August 2015 at 08:36, Tofu Ninja via Digitalmars-d digitalmars-d@puremagic.com wrote: [...] (Neo)Vim? :o) [...] Not sure which environment you refer to, but most times I've been pinged into discussion, the problem was less the debugger (GDB) and more the compiler (DMD) which does not produce enough (or wrong) information to even allow some basics to work properly. So your idea of a debugger tool to fix all problems is a non-starter project because from DMD there is not much information present to begin with. You can't magically build a debug environment that represents a program state in its entirety from nothing! Iain. +1, gdb works just fine with both gdc and ldc(gdc moreso.) Another area that dmd falls flat on its face in. The only real problem I have with GDC is that it's slow.
Re: D for Game Development
On 9 August 2015 at 09:03, rsw0x via Digitalmars-d digitalmars-d@puremagic.com wrote: On Sunday, 9 August 2015 at 06:59:15 UTC, Iain Buclaw wrote: On 9 August 2015 at 08:36, Tofu Ninja via Digitalmars-d digitalmars-d@puremagic.com wrote: [...] (Neo)Vim? :o) [...] Not sure which environment you refer to, but most times I've been pinged into discussion, the problem was less the debugger (GDB) and more the compiler (DMD) which does not produce enough (or wrong) information to even allow some basics to work properly. So your idea of a debugger tool to fix all problems is a non-starter project because from DMD there is not much information present to begin with. You can't magically build a debug environment that represents a program state in its entirety from nothing! Iain. +1, gdb works just fine with both gdc and ldc(gdc moreso.) Another area that dmd falls flat on its face in. The only real problem I have with GDC is that it's slow. Well I have no control over the sheer number of optimization passes in GCC backend, nor the sheer number of functions the D frontend wants to send to compile. :o) If the libraries were shared, this would reduce linking time, which in various benchmarks I've done is where most small projects spend the majority of their time doing. But no one has as of yet come up with a feasibly implementable idea to do that. Iain.
Re: D for Game Development
On 8/8/2015 11:38 PM, Iain Buclaw via Digitalmars-d wrote: I know that at least for the benefit of std.math, we should allow any precision without expensive casting to and from real, which has been found to be a performance problem on various benchmarks (GDC, LDC, DMD, doesn't matter). I thought that had largely been done.
Re: D for Game Development
On 8/9/2015 12:18 AM, Iain Buclaw via Digitalmars-d wrote: If the libraries were shared, this would reduce linking time, which in various benchmarks I've done is where most small projects spend the majority of their time doing. But no one has as of yet come up with a feasibly implementable idea to do that. We ship Phobos as a shared library on Linux, OSX and FreeBSD.
Re: D for Game Development
On 8/8/2015 11:36 PM, Tofu Ninja wrote: On Sunday, 9 August 2015 at 05:18:33 UTC, rsw0x wrote: dmd not being deprecated continues the cycle of gdc/ldc lagging versions behind and being understaffed in manpower. I think another point to look at is how far gdc and ldc have come while still having so few people working on them. Clearly they are able to get more done faster because they can leverage the work of the llvm and gcc devs. Seems silly that the majority of our talent is focused on dmd when it is the slowest of the bunch. D's not made here syndrome strikes again! There's pretty much no talent focused on the dmd back end. I do most of the (very) occasional bug fixes, and sometimes Martin or Daniel correct something, and that's about it. The idea that it is sucking up resources is incorrect.
Re: D for Game Development
On 9 August 2015 at 09:28, Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 8/8/2015 11:38 PM, Iain Buclaw via Digitalmars-d wrote: I know that at least for the benefit of std.math, we should allow any precision without expensive casting to and from real, which has been found to be a performance problem on various benchmarks (GDC, LDC, DMD, doesn't matter). I thought that had largely been done. What about intrinsics? https://github.com/D-Programming-Language/phobos/blob/94f718e5c69939f595fb839d3aae24878f126d78/std/math.d#L630
Re: D for Game Development
On 9 August 2015 at 09:33, Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 8/9/2015 12:18 AM, Iain Buclaw via Digitalmars-d wrote: If the libraries were shared, this would reduce linking time, which in various benchmarks I've done is where most small projects spend the majority of their time doing. But no one has as of yet come up with a feasibly implementable idea to do that. We ship Phobos as a shared library on Linux, OSX and FreeBSD. ... By inventing your own storage section? This doesn't work where TLS is not natively supported. (Though, no one has really told me how it works after years repeatedly asking, but this is what I assume is being done).
Re: D for Game Development
On 8/9/2015 12:36 AM, Iain Buclaw via Digitalmars-d wrote:
What about intrinsics?
https://github.com/D-Programming-Language/phobos/blob/94f718e5c69939f595fb839d3aae24878f126d78/std/math.d#L630
There isn't a simd cosine instruction, so making cos(double) builtin
accomplishes nothing. However, the casting in those functions go away when code
is generated.
For example:
import std.math;
double foo(double d) {
return cos(d);
}
generates:
_D3foo3fooFdZd:
fld qword ptr 4[ESP]
fcos
ret 8
Re: D for Game Development
On 9 August 2015 at 09:53, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 8/9/2015 12:36 AM, Iain Buclaw via Digitalmars-d wrote:
What about intrinsics?
https://github.com/D-Programming-Language/phobos/blob/94f718e5c69939f595fb839d3aae24878f126d78/std/math.d#L630
There isn't a simd cosine instruction, so making cos(double) builtin
accomplishes nothing. However, the casting in those functions go away when
code is generated.
For example:
import std.math;
double foo(double d) {
return cos(d);
}
generates:
_D3foo3fooFdZd:
fld qword ptr 4[ESP]
fcos
ret 8
This is on Windows? I'm not seeing this on Linux. http://goo.gl/58yhwU
Re: D for Game Development
On 8/9/2015 12:51 AM, Iain Buclaw via Digitalmars-d wrote: On 9 August 2015 at 09:33, Walter Bright via Digitalmars-d digitalmars-d@puremagic.com mailto:digitalmars-d@puremagic.com wrote: On 8/9/2015 12:18 AM, Iain Buclaw via Digitalmars-d wrote: If the libraries were shared, this would reduce linking time, which in various benchmarks I've done is where most small projects spend the majority of their time doing. But no one has as of yet come up with a feasibly implementable idea to do that. We ship Phobos as a shared library on Linux, OSX and FreeBSD. ... By inventing your own storage section? This doesn't work where TLS is not natively supported. (Though, no one has really told me how it works after years repeatedly asking, but this is what I assume is being done). I don't understand your question. On Linux, TLS data is inserted into the same section that gcc puts it. On OSX, where gcc didn't support TLS, dmd did create it into a data segment. Every time a new thread was created, druntime would malloc a chunk of data, and copy that data segment into it to initialize it. Then it would save a pointer to the malloced data in the thread data structure. Accessing the OSX TLS involved finding the thread data structure for the current thread, and getting the pointer to the TLS malloced data, and adding the offset of the symbol to it. The only reason a new data section was required was so that all the TLS data from all the object modules would be adjacent. It's the only way to do it.
Re: D for Game Development
On 8/9/2015 1:05 AM, Iain Buclaw via Digitalmars-d wrote: This is on Windows? I'm not seeing this on Linux. http://goo.gl/58yhwU You're seeing that on Linux because doubles are passed/returned in XMM0 on Linux, and the only way to load XMM0 into the x87 is to pass it through a memory location. There's still no casting to/from real, even in that asm code.
Re: D for Game Development
On 8/9/2015 1:11 AM, Walter Bright wrote: You're seeing that on Linux because doubles are passed/returned in XMM0 on Linux, and the only way to load XMM0 into the x87 is to pass it through a memory location. There's still no casting to/from real, even in that asm code. BTW, if you want to suggest faster emitted code for cos(float) and cos(double), I'm game! Fire away!
Re: D for Game Development
Am Sun, 9 Aug 2015 01:05:35 -0700 schrieb Walter Bright newshou...@digitalmars.com: I don't understand your question. On Linux, TLS data is inserted into the same section that gcc puts it. On OSX, where gcc didn't support TLS, dmd did create it into a data segment. Every time a new thread was created, druntime would malloc a chunk of data, and copy that data segment into it to initialize it. Then it would save a pointer to the malloced data in the thread data structure. Accessing the OSX TLS involved finding the thread data structure for the current thread, and getting the pointer to the TLS malloced data, and adding the offset of the symbol to it. Do you support shared libraries on OSX with that emulated TLS system for all use cases? What if library A want to access a exported TLS variable in library B? How do you: 1) Find the library the imported symbol is exported from (libraryB) 2) Find the TLS block for that library 3) Find the offset in that TLS block The only reason a new data section was required was so that all the TLS data from all the object modules would be adjacent. It's the only way to do it. That statement is too broad to be true ;-) GCC's emulated TLS doesn't have adjacent memory for TLS variables and it works fine with D (and the GC). It is a little bit slower than if we had adjacent memory. OTOH this approach works with all kinds of shared libraries and requires very little system specific code (only need some pthread tls mechanism). And it is compatible with GCCs emulated TLS, so you can even have extern TLS variables shared between C and D with emutls.
Re: D for Game Development
Am Sun, 9 Aug 2015 00:32:00 -0700 schrieb Walter Bright newshou...@digitalmars.com: On 8/8/2015 11:36 PM, Tofu Ninja wrote: On Sunday, 9 August 2015 at 05:18:33 UTC, rsw0x wrote: dmd not being deprecated continues the cycle of gdc/ldc lagging versions behind and being understaffed in manpower. I think another point to look at is how far gdc and ldc have come while still having so few people working on them. Clearly they are able to get more done faster because they can leverage the work of the llvm and gcc devs. Seems silly that the majority of our talent is focused on dmd when it is the slowest of the bunch. D's not made here syndrome strikes again! There's pretty much no talent focused on the dmd back end. I do most of the (very) occasional bug fixes, and sometimes Martin or Daniel correct something, and that's about it. The idea that it is sucking up resources is incorrect. The DMD devs aren't working on the backend, but the GDC and LDC are neither ;-) He's talking about the glue layer. DMD has the advantage that whenever a frontend pull request requires glue layer changes you get at and once by the contributor. But for LDC and GDC the glue layer changes have to be implemented by GDC/LDC devs.
Re: D for Game Development
On 8/9/2015 2:07 AM, Johannes Pfau wrote: DMD has the advantage that whenever a frontend pull request requires glue layer changes you get at and once by the contributor. But for LDC and GDC the glue layer changes have to be implemented by GDC/LDC devs. If LDC were the default, then the GDC devs would still have to do the same work.
Re: D for Game Development
On 8/9/2015 2:04 AM, Johannes Pfau wrote: That statement is too broad to be true ;-) GCC's emulated TLS doesn't have adjacent memory for TLS variables and it works fine with D (and the GC). It is a little bit slower than if we had adjacent memory. OTOH this approach works with all kinds of shared libraries and requires very little system specific code (only need some pthread tls mechanism). And it is compatible with GCCs emulated TLS, so you can even have extern TLS variables shared between C and D with emutls. The reason I did the special support for TLS on OSX is because gcc at the time did not support TLS in any way shape or form. Now that it does, dmd should change to do it the same way.
Re: D for Game Development
On 9 August 2015 at 11:07, Johannes Pfau via Digitalmars-d digitalmars-d@puremagic.com wrote: Am Sun, 9 Aug 2015 00:32:00 -0700 schrieb Walter Bright newshou...@digitalmars.com: On 8/8/2015 11:36 PM, Tofu Ninja wrote: On Sunday, 9 August 2015 at 05:18:33 UTC, rsw0x wrote: dmd not being deprecated continues the cycle of gdc/ldc lagging versions behind and being understaffed in manpower. I think another point to look at is how far gdc and ldc have come while still having so few people working on them. Clearly they are able to get more done faster because they can leverage the work of the llvm and gcc devs. Seems silly that the majority of our talent is focused on dmd when it is the slowest of the bunch. D's not made here syndrome strikes again! There's pretty much no talent focused on the dmd back end. I do most of the (very) occasional bug fixes, and sometimes Martin or Daniel correct something, and that's about it. The idea that it is sucking up resources is incorrect. The DMD devs aren't working on the backend, but the GDC and LDC are neither ;-) He's talking about the glue layer. DMD has the advantage that whenever a frontend pull request requires glue layer changes you get at and once by the contributor. But for LDC and GDC the glue layer changes have to be implemented by GDC/LDC devs. I think that is more of a problem with length of development + number of contributors/changes. For instance, when it was just Walter committing changes, the number of fixed bugs was of a reasonable number such that I could have gone through them all and tested them within a day (this is back when the D2 testsuite was private and I had no way other way to track whether or not codegen changes were required). Now we have the testsuite, which seems to be a good enough gauge for finding problems. However if there's been a change (eg: refactor) between what codegen is lowered in the frontend vs. glue, then it becomes a commit hunt trawling through thousands of changes to work out which one is relevant to the new wrong-code-on-previously-working test. One day turns into a week, turns into a month, turns into half a year. Iain.
Re: D for Game Development
On 09-Aug-2015 15:27, Manu via Digitalmars-d wrote: On 9 August 2015 at 20:04, Dmitry Olshansky via Digitalmars-d digitalmars-d@puremagic.com wrote: On 09-Aug-2015 12:33, Manu via Digitalmars-d wrote: On 9 August 2015 at 13:34, Rikki Cattermole via Digitalmars-d digitalmars-d@puremagic.com wrote: On 9/08/2015 2:40 p.m., Manu via Digitalmars-d wrote: [snip] Even though it is hard for you to still be here, I hope you do continue to help D grow. This is a good community, we just need time before real adoption. E.g. we are only just now starting to unify projects. Cheers, but don't get me wrong; I've barely contributed anything of value other than advocacy and little bits and pieces here and there. I don't deserve any credit, I just complain about things that make it impossible for me to get on with my work. std.simd though would be awesome to have ;) Yeah, I keep coming back to it, and getting myself stuck with various troubles making it work good. I'm perpetually unhappy with my code, and I just need a really good block of time to get through it. If people want to review std.color and help get that off my short-list, I promise I'll make std.simd my top priority :P Well, let us march towards std.experimental.color then :) I'll see what I need about it or maybe it's plenty good enough for me already. One thing I've hit with color in the past is painfully slow bulk array at once color conversions. In 2013 my CV app for an embbeded linux device had spent ~50% of time gray-scaling input image(!) that is until I coded a bit of NEON to fix that to ~11%. And note I'm no SIMD guru so I had spent an evening worth of time to test a few versions but the result was well worth it. I also haven't had need for it in my recent work, so it's not being motivated by necessity since I haven't been game-dev-ing much. -- Dmitry Olshansky
Re: D for Game Development
On 8/9/15 5:15 AM, Walter Bright wrote: On 8/9/2015 2:04 AM, Johannes Pfau wrote: That statement is too broad to be true ;-) GCC's emulated TLS doesn't have adjacent memory for TLS variables and it works fine with D (and the GC). It is a little bit slower than if we had adjacent memory. OTOH this approach works with all kinds of shared libraries and requires very little system specific code (only need some pthread tls mechanism). And it is compatible with GCCs emulated TLS, so you can even have extern TLS variables shared between C and D with emutls. The reason I did the special support for TLS on OSX is because gcc at the time did not support TLS in any way shape or form. Now that it does, dmd should change to do it the same way. Where is the bugzilla issue etc :o). -- Andrei
Re: D for Game Development
On 9 August 2015 at 23:52, Dmitry Olshansky via Digitalmars-d digitalmars-d@puremagic.com wrote: On 09-Aug-2015 15:27, Manu via Digitalmars-d wrote: On 9 August 2015 at 20:04, Dmitry Olshansky via Digitalmars-d digitalmars-d@puremagic.com wrote: On 09-Aug-2015 12:33, Manu via Digitalmars-d wrote: On 9 August 2015 at 13:34, Rikki Cattermole via Digitalmars-d digitalmars-d@puremagic.com wrote: On 9/08/2015 2:40 p.m., Manu via Digitalmars-d wrote: [snip] Even though it is hard for you to still be here, I hope you do continue to help D grow. This is a good community, we just need time before real adoption. E.g. we are only just now starting to unify projects. Cheers, but don't get me wrong; I've barely contributed anything of value other than advocacy and little bits and pieces here and there. I don't deserve any credit, I just complain about things that make it impossible for me to get on with my work. std.simd though would be awesome to have ;) Yeah, I keep coming back to it, and getting myself stuck with various troubles making it work good. I'm perpetually unhappy with my code, and I just need a really good block of time to get through it. If people want to review std.color and help get that off my short-list, I promise I'll make std.simd my top priority :P Well, let us march towards std.experimental.color then :) I'll see what I need about it or maybe it's plenty good enough for me already. One thing I've hit with color in the past is painfully slow bulk array at once color conversions. In 2013 my CV app for an embbeded linux device had spent ~50% of time gray-scaling input image(!) that is until I coded a bit of NEON to fix that to ~11%. And note I'm no SIMD guru so I had spent an evening worth of time to test a few versions but the result was well worth it. I'm happy to do optimisation passes, and have plenty of experience to do so, but the API and general feature set needs to be agreed before I do that sort of thing. Optimisation can come via future PR's. Incidentally, std.color would be a great customer for std.simd ;)
Re: D for Game Development
On 09/08/15 15:53, Andrei Alexandrescu wrote: Where is the bugzilla issue etc :o). -- Andrei It's been there for a while [1] ;) [1] https://issues.dlang.org/show_bug.cgi?id=9476 -- /Jacob Carlborg
Re: D for Game Development
On 09/08/15 13:38, Manu via Digitalmars-d wrote: In fact, we've been discussing for a few months that we'd have have another very promising opportunity to use D at work in a really appropriate context if I could rely on Android and iOS appearing within 6-12 months or so. There's been quite a lot of activities lately in improving the Andriod and iOS support by Joakim and Dan. -- /Jacob Carlborg
Re: D for Game Development
On 8/9/2015 4:38 AM, Manu via Digitalmars-d wrote: On 9 August 2015 at 15:31, Walter Bright via Digitalmars-d But waiting for someone else to discover the same thing on some other piece of code means you'll be waiting a long time. I understand, but that's not sustainable. We can't be in a situation where I'm at work with a deadline, and I need to invoke the community to address a codegen issue that's blocking a release. Unexpected surprises like that with unknown/long turn-around times aren't a practical commitment. It will NEVER get fixed if you don't file bug reports, and you'll continue to be frustrated (and me too, because there's NOTHING I can do to improve things based on what you post here). Last time I was concerned with this, x87 was destroying DMD performance. Floats were x87, moved to XMM (according to x64 ABI) when passed to functions, then moved back into x87 on the other side when they're operated on. Float code was overwhelmed with shuffling values between registers. Basically all hot code is float code in my line of work. All I really need is a bugzilla issue with just ONE example of needlessly using the x87 where a SIMD instruction would be better. I think Ethan was in discussions with you about this some time back? It was a problem at the time I left Remedy. As I recall, I heard from Ethan just once since you left. In contrast, I hear regularly from Sociomantic when they've got an issue, and I'm able to consequently help them be successful with D. Also, I think one of the big issues is the optimiser in general. The inliner's just not fantastic, and D depends on it perhaps even more than C++, especially when using the modern lazy code style. I'm sure I can hand-assist DMD to produce the assembly I expect for some hot function with some work, but traditional hand-assisted code generation all falls apart when you start stacking lazy-ranges and generally using the modern D style. DMD's backend has almost no development, it's advancing at near-zero velocity compared to LLVM. We need to get out of the situation where LDC and GDC are perpetually 1-2 versions behind. Incidentally, In my recent (dead-end) experience with LDC, I get endless ICE's whenever I try to do anything mildly complex. When you have your Debug and Release build straddling language versions and compilers with different ICE characteristics, it's just not a practical workflow. Only green-fields projects or the simplest of simple apps can hope not to trigger bugs constantly in that environment. I can't help you with LDC ICE's, but are you filing bug reports for them? Again, if you don't file bug reports, NOTHING WILL GET FIXED. You will be frustrated and everyone else will be, too. 2. DMD generates x87 code, and uses real everywhere. Less so now than it used to. For float and double, it uses SIMD. Okay, is this fairly recent? My last set of comprehensive tests are probably out of date. No, it's been that way for a while. Massive register swapping was the issue. I'd like to think register swapping should never be implicitly generated unless I *explicitly* type the real keyword, I don't want to see x87 opcodes. It'll still use the x87 for things like FCOS and FSIN. But if it's doing an x87, say, multiply when it should be using SIMD, you need to file a bug report. Vague statements are not actionable. 2. LDC has a lot more bugs than DMD (which still has quite a few bugs), and the Windows build is new and even more immature still. 3. LDC has no debuginfo. **biggest practical issue by far!** 4. LDC/GDC are always a few versions behind DMD. This creates an awkward/almost-impossible situation when you rely on DMD to build debug code, and LDC to build releasable code. Depending on 2 flaky compilers is even less fun than one. 5. DLL's were really flakey at the time, I'm not sure how they are now, but I'm concerned they may not be much better. 6. Shared druntime; we were loading D code from DLL's, lots of them. It's not really reasonable for each DLL to have it's own druntime instance, they need to share one provided by the host app. I agree, and now we ship a Phobos DLL, resolving that issue. Really? Where is it? (I can't see it in the distribution). Should be in the bin directory. At the time I was actually heckled by people here telling me I was stupid to try and use vibe.d commercially. I was fairly surprised, it seems like one of the D community's biggest success stories, and people were (almost violently) telling me I'm stupid to attempt to use it in production. I didn't see such comments, but there'll always be naysayers. Might I suggest - and I'm sure you won't like this, but I think it would do worlds of good; your experience implementing MS debuginfo in DMD is invaluable and fairly unique. If you could contribute that debuginfo support to LLVM, it would make a world of difference. All I know is actually in the DMD source code. Bindings aren't too hard to
Re: D for Game Development
On 8/9/2015 12:59 PM, ponce wrote: Well, for Win64 the codegen is simply wrong. I don't even care if the codegen is fast or not, but correct should be a given. Biggest problem for me so far. There's nothing I nor anyone else can do with comments like this. It passes the executable part of the test suite on Win64. If there are bugs in the Win64 code generation, I don't see any on Bugzilla. Please post incorrect codegen bugs to bugzilla. If they are already on bugzilla, please post the bug numbers.
Re: D for Game Development
On Sunday, 9 August 2015 at 05:18:33 UTC, rsw0x wrote: On Sunday, 9 August 2015 at 02:41:00 UTC, Manu wrote: ... This pretty much hit the nail on the head on why dmd needs deprecated. I'm tired of seeing 'BUT IT WORKS ON WINDOWS' as an excuse. I don't care if it works on windows, it produces code slower than interpreted lua. Exactly what use is that? It may as well not work on windows at all as far as release builds are concerned. Well, for Win64 the codegen is simply wrong. I don't even care if the codegen is fast or not, but correct should be a given. Biggest problem for me so far. Aggravated by the time it takes to isolate such bugs.
Re: D for Game Development
On Sunday, 9 August 2015 at 20:24:47 UTC, Walter Bright wrote: On 8/9/2015 12:59 PM, ponce wrote: Well, for Win64 the codegen is simply wrong. I don't even care if the codegen is fast or not, but correct should be a given. Biggest problem for me so far. There's nothing I nor anyone else can do with comments like this. It passes the executable part of the test suite on Win64. If there are bugs in the Win64 code generation, I don't see any on Bugzilla. Please post incorrect codegen bugs to bugzilla. If they are already on bugzilla, please post the bug numbers. Once I get back to Windows I will post the report. The problem is that from a selfish point of view I can better optimize for my time and just disable optimizations in the faulty code, moving on to the next task. A Tragedy of the commons situation.
Re: D for Game Development
On 8/9/2015 9:26 PM, Tofu Ninja wrote: On Sunday, 9 August 2015 at 20:51:32 UTC, Walter Bright wrote: On 8/9/2015 4:38 AM, Manu via Digitalmars-d wrote: On 9 August 2015 at 15:31, Walter Bright via Digitalmars-d I agree, and now we ship a Phobos DLL, resolving that issue. Really? Where is it? (I can't see it in the distribution). Should be in the bin directory. There is no Phobos dll, only Phobos lib. There's linux/lib32/libphobos2.so, for example.
Re: D for Game Development
On 8/9/2015 11:50 AM, Jacob Carlborg wrote: [1] https://issues.dlang.org/show_bug.cgi?id=9476 Thanks for helping out with this.
Re: D for Game Development
On 8/9/2015 2:03 PM, ponce wrote: Once I get back to Windows I will post the report. Thank you. The problem is that from a selfish point of view I can better optimize for my time and just disable optimizations in the faulty code, moving on to the next task. A Tragedy of the commons situation. I think that's very short term thinking. You will benefit from the fixes since you won't have to debug or work around them any more.
Re: D for Game Development
On Sunday, 9 August 2015 at 20:51:32 UTC, Walter Bright wrote: On 8/9/2015 4:38 AM, Manu via Digitalmars-d wrote: On 9 August 2015 at 15:31, Walter Bright via Digitalmars-d I agree, and now we ship a Phobos DLL, resolving that issue. Really? Where is it? (I can't see it in the distribution). Should be in the bin directory. There is no Phobos dll, only Phobos lib.
Re: D for Game Development
On Sunday, 9 August 2015 at 12:27:26 UTC, Manu wrote: Yeah, I keep coming back to it, and getting myself stuck with various troubles making it work good. I'm perpetually unhappy with my code, and I just need a really good block of time to get through it. If people want to review std.color and help get that off my short-list, I promise I'll make std.simd my top priority :P I also haven't had need for it in my recent work, so it's not being motivated by necessity since I haven't been game-dev-ing much. Cool.
Re: D for Game Development
On 10 August 2015 at 06:26, Tofu Ninja via Digitalmars-d digitalmars-d@puremagic.com wrote: On Sunday, 9 August 2015 at 20:51:32 UTC, Walter Bright wrote: On 8/9/2015 4:38 AM, Manu via Digitalmars-d wrote: On 9 August 2015 at 15:31, Walter Bright via Digitalmars-d I agree, and now we ship a Phobos DLL, resolving that issue. Really? Where is it? (I can't see it in the distribution). Should be in the bin directory. There is no Phobos dll, only Phobos lib. No shared library support on Windows. This is part of the reason why shared library support has not made its way to GDC yet (at least for D2). I almost exorbitantly follow a one-size-fits-all stance on all codegen-related aspects. If it's not cross-platform, it's not going in. Iain.
Re: D for Game Development
On Friday, 7 August 2015 at 04:56:39 UTC, Rikki Cattermole wrote: *whispers* Hey hey you. You want tests? Well here is something you'll like[0]. Oh and check out[1]. [0] http://www.libpng.org/pub/png/pngsuite.html [1] http://forum.dlang.org/post/zxbexpwmirzdkewhq...@forum.dlang.org Well done you've written a library to pass some tests. Now fix the bugs that you haven't found yet and scalability issues you aren't aware of...the things that really only spring up when you get 1000+ users thrashing it each week. In the meantime I'll use D bindings to FreeImage or similar ilk that's gone through the wringer several times over. Sorry I don't mean to sound harsh but that's the reality I'm in right now pushing D on teams in my workplace. It would be much simpler if there were quality (idiomatic) D interfaces to existing quality C/C++ libraries. bye, lobo
Re: D for Game Development
On 8/08/2015 8:05 p.m., lobo wrote: On Friday, 7 August 2015 at 04:56:39 UTC, Rikki Cattermole wrote: *whispers* Hey hey you. You want tests? Well here is something you'll like[0]. Oh and check out[1]. [0] http://www.libpng.org/pub/png/pngsuite.html [1] http://forum.dlang.org/post/zxbexpwmirzdkewhq...@forum.dlang.org Well done you've written a library to pass some tests. Now fix the bugs that you haven't found yet and scalability issues you aren't aware of...the things that really only spring up when you get 1000+ users thrashing it each week. In the meantime I'll use D bindings to FreeImage or similar ilk that's gone through the wringer several times over. Sorry I don't mean to sound harsh but that's the reality I'm in right now pushing D on teams in my workplace. It would be much simpler if there were quality (idiomatic) D interfaces to existing quality C/C++ libraries. bye, lobo I've been saying from the beginning that we need both D implementation of some simpler formats such as PNG AND bindings + implementation for e.g. FreeImage. I have NEVER said that we should only use D code. Only an out of the box experience must not require external code. I wish people understood that I'm truly trying to meet people half way. That I'm not advocating NIH syndrome in any form and that other libraries can benefit us. If used the right way.
Re: D for Game Development
On Saturday, 8 August 2015 at 08:05:27 UTC, lobo wrote: Sorry I don't mean to sound harsh but that's the reality I'm in right now pushing D on teams in my workplace. It would be much simpler if there were quality (idiomatic) D interfaces to existing quality C/C++ libraries. Have you looked at http://code.dlang.org/packages/gfm%3Afreeimage ?
Re: D for Game Development
On Friday, 7 August 2015 at 20:24:54 UTC, jmh530 wrote: On Friday, 7 August 2015 at 17:40:16 UTC, deadalnix wrote: [...] I wouldn't think what you're saying is controversial...just a lot of work to do well. [...] +2000
Re: D for Game Development
On 6 August 2015 at 21:46, Rikki Cattermole via Digitalmars-d digitalmars-d@puremagic.com wrote: On 6/08/2015 11:30 p.m., Manu via Digitalmars-d wrote: On 6 August 2015 at 21:23, Rikki Cattermole via Digitalmars-d digitalmars-d@puremagic.com wrote: On 6/08/2015 11:18 p.m., Manu via Digitalmars-d wrote: On 5 August 2015 at 05:13, Rikki Cattermole via Digitalmars-d digitalmars-d@puremagic.com wrote: On 5/08/2015 6:59 a.m., develop32 wrote: On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote: D is really cool and makes a good candidate for developing a game. Are there any guys out there using D for indie games? Not an indie game, but Remedy is making Quantum Break using D. Got a source for that? As I can't find it. Hi. I dunnit, and I did a talk about it at dconf2013. I knew you were involved with them back then. I was more interested in anything that happened after that. It took a lot longer for us to get the compiler to a sufficiently stable state that we were able to build reliably than we'd liked. In the mean time, code pegged for D was forced to be written in C, so a lot of D code ended out being C code on account of 'couldn't wait'. When I left, there were a couple of critical systems running in D, and a few toolchain issues left to work out (Windows DLL's + GC). It was left with Ethan who occasionally appears here. I'm not sure where it went after that. There was much enthusiasm among the team, but the toolchain progressed slower than we could afford, and we just had to get on with it in some cases. Hopefully there's still some D code in there, and (if the problems were fixed!) there's no good reason why it wouldn't have scaled out from where I left it. Yeah I hope it had. Although would be nice to hear from Remedy what they currently use / think of D. I kinda hoped that they had released e.g. a blog post about it, which they haven't. Our experience wasn't really positive. Can't/don't-want-to write a blog post about that. Trust me, we were very enthusiastic to stand at GDC and give a lecture about our experience, but it didn't really go according to plan, mostly blocked by trivial shit that's been known problems for at least as long as I've been around here. It's not so much language problems, it's tooling problems. It's the most important and perhaps most neglected aspect of the D ecosystem. 1. DMD has unsatisfactory codegen for anything other than debug builds. 2. DMD generates x87 code, and uses real everywhere. We can't be generating new x87+real instructions in 2015. It's deprecated hardware! 2. LDC has a lot more bugs than DMD (which still has quite a few bugs), and the Windows build is new and even more immature still. 3. LDC has no debuginfo. **biggest practical issue by far!** 4. LDC/GDC are always a few versions behind DMD. This creates an awkward/almost-impossible situation when you rely on DMD to build debug code, and LDC to build releasable code. Depending on 2 flaky compilers is even less fun than one. 5. DLL's were really flakey at the time, I'm not sure how they are now, but I'm concerned they may not be much better. 6. Shared druntime; we were loading D code from DLL's, lots of them. It's not really reasonable for each DLL to have it's own druntime instance, they need to share one provided by the host app. 7. D binaries are *gigantic*, I don't know why. D seems to link the world, and I'm certain that most of the crap that's linked is never referenced or executed... it just makes gigantic binaries for some reason, even with line-for-line translations of C/C++ code. That's not real good on games consoles where icache is king. I tried to use D in my current workplace on 3 occasions now, and ran into a different set of problems. In the first attempt I tried to write a simple vibe.d webserver app, but it kept crashing randomly when I was using the API's exactly as intended (apparently a client was posting `/n` instead of `/r/n`, or maybe the inverse of that, and it didn't like it). The IDE/debugging situation is basically impossible; vibe.d throws exceptions all over the place, with no really good tools for debugging this sort of thing. My colleagues freaked out and thought I was crazy, and my credibility was diminished. In my second attempt, progress was interrupted by some ICE's, linking with some C++ code caused various problems. I investigated making another attempt to use D where we have some web front-end code that's built using Emscripten. D would have been perfect for this job, but LDC can't target Emscripten and/or NaCl. I don't see that coming along any time soon. I briefly looked at trying to make an Emscripten build of LDC, but it requires probably weeks worth of research and expert knowledge to approach it. A final recent attempt was basically a non-starter on account of no Qt bindings that work /|| are up to date. I'm using C++11 now, it's horrible. Let me repeat, it's HORRIBLE, but it's *possible* to
Re: D for Game Development
On 9/08/2015 2:40 p.m., Manu via Digitalmars-d wrote: On 6 August 2015 at 21:46, Rikki Cattermole via Digitalmars-d digitalmars-d@puremagic.com wrote: On 6/08/2015 11:30 p.m., Manu via Digitalmars-d wrote: On 6 August 2015 at 21:23, Rikki Cattermole via Digitalmars-d digitalmars-d@puremagic.com wrote: On 6/08/2015 11:18 p.m., Manu via Digitalmars-d wrote: On 5 August 2015 at 05:13, Rikki Cattermole via Digitalmars-d digitalmars-d@puremagic.com wrote: On 5/08/2015 6:59 a.m., develop32 wrote: On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote: D is really cool and makes a good candidate for developing a game. Are there any guys out there using D for indie games? Not an indie game, but Remedy is making Quantum Break using D. Got a source for that? As I can't find it. Hi. I dunnit, and I did a talk about it at dconf2013. I knew you were involved with them back then. I was more interested in anything that happened after that. It took a lot longer for us to get the compiler to a sufficiently stable state that we were able to build reliably than we'd liked. In the mean time, code pegged for D was forced to be written in C, so a lot of D code ended out being C code on account of 'couldn't wait'. When I left, there were a couple of critical systems running in D, and a few toolchain issues left to work out (Windows DLL's + GC). It was left with Ethan who occasionally appears here. I'm not sure where it went after that. There was much enthusiasm among the team, but the toolchain progressed slower than we could afford, and we just had to get on with it in some cases. Hopefully there's still some D code in there, and (if the problems were fixed!) there's no good reason why it wouldn't have scaled out from where I left it. Yeah I hope it had. Although would be nice to hear from Remedy what they currently use / think of D. I kinda hoped that they had released e.g. a blog post about it, which they haven't. Our experience wasn't really positive. Can't/don't-want-to write a blog post about that. Trust me, we were very enthusiastic to stand at GDC and give a lecture about our experience, but it didn't really go according to plan, mostly blocked by trivial shit that's been known problems for at least as long as I've been around here. It's not so much language problems, it's tooling problems. It's the most important and perhaps most neglected aspect of the D ecosystem. 1. DMD has unsatisfactory codegen for anything other than debug builds. 2. DMD generates x87 code, and uses real everywhere. We can't be generating new x87+real instructions in 2015. It's deprecated hardware! 2. LDC has a lot more bugs than DMD (which still has quite a few bugs), and the Windows build is new and even more immature still. 3. LDC has no debuginfo. **biggest practical issue by far!** 4. LDC/GDC are always a few versions behind DMD. This creates an awkward/almost-impossible situation when you rely on DMD to build debug code, and LDC to build releasable code. Depending on 2 flaky compilers is even less fun than one. 5. DLL's were really flakey at the time, I'm not sure how they are now, but I'm concerned they may not be much better. 6. Shared druntime; we were loading D code from DLL's, lots of them. It's not really reasonable for each DLL to have it's own druntime instance, they need to share one provided by the host app. 7. D binaries are *gigantic*, I don't know why. D seems to link the world, and I'm certain that most of the crap that's linked is never referenced or executed... it just makes gigantic binaries for some reason, even with line-for-line translations of C/C++ code. That's not real good on games consoles where icache is king. I tried to use D in my current workplace on 3 occasions now, and ran into a different set of problems. In the first attempt I tried to write a simple vibe.d webserver app, but it kept crashing randomly when I was using the API's exactly as intended (apparently a client was posting `/n` instead of `/r/n`, or maybe the inverse of that, and it didn't like it). The IDE/debugging situation is basically impossible; vibe.d throws exceptions all over the place, with no really good tools for debugging this sort of thing. My colleagues freaked out and thought I was crazy, and my credibility was diminished. In my second attempt, progress was interrupted by some ICE's, linking with some C++ code caused various problems. I investigated making another attempt to use D where we have some web front-end code that's built using Emscripten. D would have been perfect for this job, but LDC can't target Emscripten and/or NaCl. I don't see that coming along any time soon. I briefly looked at trying to make an Emscripten build of LDC, but it requires probably weeks worth of research and expert knowledge to approach it. A final recent attempt was basically a non-starter on account of no Qt bindings that work /|| are up to date. I'm using C++11 now, it's horrible. Let me repeat,
Re: D for Game Development
On Sunday, 9 August 2015 at 02:41:00 UTC, Manu wrote: ... This pretty much hit the nail on the head on why dmd needs deprecated. I'm tired of seeing 'BUT IT WORKS ON WINDOWS' as an excuse. I don't care if it works on windows, it produces code slower than interpreted lua. Exactly what use is that? It may as well not work on windows at all as far as release builds are concerned. dmd not being deprecated continues the cycle of gdc/ldc lagging versions behind and being understaffed in manpower.
Re: D for Game Development
On 8/8/2015 7:40 PM, Manu via Digitalmars-d wrote: 1. DMD has unsatisfactory codegen for anything other than debug builds. Do you mean the codegen is slower? But consider that the bottleneck in most programs is a small section of code. Taking a good look at the generated code for that and comparing with another compiler can often hint at an easy improvement to dmd that can address that bottleneck. But waiting for someone else to discover the same thing on some other piece of code means you'll be waiting a long time. 2. DMD generates x87 code, and uses real everywhere. Less so now than it used to. For float and double, it uses SIMD. We can't be generating new x87+real instructions in 2015. It's deprecated hardware! x87 works on every x86 CPU, and I doubt it will ever go away, deprecated or not. Why was it a problem for you? 2. LDC has a lot more bugs than DMD (which still has quite a few bugs), and the Windows build is new and even more immature still. 3. LDC has no debuginfo. **biggest practical issue by far!** 4. LDC/GDC are always a few versions behind DMD. This creates an awkward/almost-impossible situation when you rely on DMD to build debug code, and LDC to build releasable code. Depending on 2 flaky compilers is even less fun than one. 5. DLL's were really flakey at the time, I'm not sure how they are now, but I'm concerned they may not be much better. 6. Shared druntime; we were loading D code from DLL's, lots of them. It's not really reasonable for each DLL to have it's own druntime instance, they need to share one provided by the host app. I agree, and now we ship a Phobos DLL, resolving that issue. 7. D binaries are *gigantic*, I don't know why. D seems to link the world, and I'm certain that most of the crap that's linked is never referenced or executed... it just makes gigantic binaries for some reason, even with line-for-line translations of C/C++ code. That's not real good on games consoles where icache is king. Yes, that's an ongoing problem. I need to spend some time on that one. I tried to use D in my current workplace on 3 occasions now, and ran into a different set of problems. In the first attempt I tried to write a simple vibe.d webserver app, but it kept crashing randomly when I was using the API's exactly as intended (apparently a client was posting `/n` instead of `/r/n`, or maybe the inverse of that, and it didn't like it). Were these bugs reported? In my second attempt, progress was interrupted by some ICE's, linking with some C++ code caused various problems. ICE's in what? What problems? A final recent attempt was basically a non-starter on account of no Qt bindings that work /|| are up to date. Bindings aren't too hard to update. I'm getting pretty close to calling it a day. Is 6 years enough time to repeatedly prove to myself that I'm chasing a fantasy? People keep talking about Rust, I'm thinking of giving it a shot. I think D needs a budget, and paid programmers employed to do boring shit that makes the whole thing more stable and robust. Mozilla seems to have this(?) D seems to consistently offer 95% solutions to problems. 95% is not a solution, it's just another problem. Oops, I ranted. Sorry! :) I think what stalled Remedy's use of D is you left Remedy. Note that while you were there I went to Finland largely at my own expense to help make it work for Remedy. After you left, there wasn't much interest from Remedy. I note that I rarely know just what is blocking you. For example, you say above you got some ICEs. What ICEs? We cannot fix bugs we don't know about. I would also very much appreciate if you would pitch in to help with things that are blocking you, like updated Qt bindings. Generally, people around here tend to contribute fixes for things that personally interest or block them. Priorities for you aren't priorities for others. D doesn't have a community so large that you can sit back and assume many others will run into the same issues you have and will fix them. You have to be more proactive. Looking at open bugzilla issues you've commented on: https://issues.dlang.org/show_bug.cgi?id=5227 https://issues.dlang.org/show_bug.cgi?id=6343 https://issues.dlang.org/show_bug.cgi?id=8845 https://issues.dlang.org/show_bug.cgi?id=9065 https://issues.dlang.org/show_bug.cgi?id=9137 https://issues.dlang.org/show_bug.cgi?id=10203 https://issues.dlang.org/show_bug.cgi?id=10959 https://issues.dlang.org/show_bug.cgi?id=11541 https://issues.dlang.org/show_bug.cgi?id=12440 https://issues.dlang.org/show_bug.cgi?id=13265 https://issues.dlang.org/show_bug.cgi?id=14260 That's it. None of them seem to be ones you brought up in your post. To get attention for issues that are blocking you you absolutely have to file bugzilla reports. That doesn't guarantee they will be fixed, but if you do not file them, it DOES guarantee that they will NOT be addressed, and you'll get frustrated.
Re: D for Game Development
On Friday, 7 August 2015 at 07:24:29 UTC, Dmitry Olshansky wrote: Truth be told if we were willing to walk extra mile we'd have proper curl/zlib experience. But linking problems plague std.net.curl usage and both libs are permanently somewhat out of date. boost http is currently in review.
Re: D for Game Development
On Friday, 7 August 2015 at 08:25:04 UTC, Ola Fosheim Grøstad wrote: On Friday, 7 August 2015 at 07:24:29 UTC, Dmitry Olshansky wrote: Truth be told if we were willing to walk extra mile we'd have proper curl/zlib experience. But linking problems plague std.net.curl usage and both libs are permanently somewhat out of date. boost http is currently in review. Does it's mean that std.net.curl would be replaced by it? Could you give link to discussion?
Re: D for Game Development
On 07-Aug-2015 08:08, Rikki Cattermole wrote: On 7/08/2015 10:48 a.m., Tofu Ninja wrote: On Thursday, 6 August 2015 at 06:30:06 UTC, Rikki Cattermole wrote: Here is what we need to do going forward (beyond what me and Manu are doing): 1. Derelict-Util needs to be put into Phobos. This is not optional 2. Derelict-GL3 needs to be put into Phobos. Optional, but might be a damn good idea! 3. Windows API needs to be moved into either Phobos or druntime. Not optional. 4. X11 bindings added to Phobos. Not optional. 5. Cocoa bindings added to Phobos. Not optional. This all needs to happen _before_ we start working on a window library for Phobos. Let alone a GUI. We're mostly got problems with Cocoa. X11 bindings just need to be changed to dynamically bound. Windows API bindings if gone into druntime wouldn't need to go through the review cycle luckily. But would need some decent review on e.g. Github. I really feel like D needs to get over it's not invented here syndrome, a much easier path would to just use a pre existing cross platform windowing library. Its laughable that the people in D want to reinvent this stuff. It's been done, just use the already working version! Why have all this great c and c++ interop if we never use it. Both are good ways. From what I see e.g. this attempts to add STL bindings to druntime: https://github.com/D-Programming-Language/druntime/pull/1316 D brings enough to the table to warrant re-writing most of libraries. The result typically is smaller, faster and more general, of course, it still depends on author's skill. It's important to pick battles though, there are thousands of good libraries already out there. I have the same gripe with how the experimental.image is doing image loading/saving, there are plenty of already existing image libraries that already support every image format you could ever dream of. Just use them, they will work 1000x better than any reinvention that we do here. Ok, here is what I'm willing to do. If you are willing to get Derelict-Util into Phobos and create the bindings for what ever (appropriate) c-library. I'm willing to create the wrappers around it to make it work with the interfaces. Not likely to happen (soon). Nice loaders for shared libraries are something that Druntime would very much need, not sure if there is something else in Derelic-Util. My intention was these to become third party libraries via dub. Please understand that I want a reasonable experience out of the box and not have the same situation we currently have with zlib/curl. Truth be told if we were willing to walk extra mile we'd have proper curl/zlib experience. But linking problems plague std.net.curl usage and both libs are permanently somewhat out of date. Which means we do need 1 or 2 image file format implementations and per platform a single window/context implementation. It doesn't have to be flash or highly customizable. But it does need to work for most people. -- Dmitry Olshansky
Re: D for Game Development
On Friday, 7 August 2015 at 05:08:27 UTC, Rikki Cattermole wrote: Ok, here is what I'm willing to do. If you are willing to get Derelict-Util into Phobos and create the bindings for what ever (appropriate) c-library. I'm willing to create the wrappers around it to make it work with the interfaces. Well we already have DerelictFI (FreeImage), but I completely disagree with the premise than having image loaders/savers is unworthy NIH. Dropping the number of dependencies is almost always worth it in my opinion.
Re: D for Game Development
On 07-Aug-2015 11:39, Suliman wrote: On Friday, 7 August 2015 at 08:25:04 UTC, Ola Fosheim Grøstad wrote: On Friday, 7 August 2015 at 07:24:29 UTC, Dmitry Olshansky wrote: Truth be told if we were willing to walk extra mile we'd have proper curl/zlib experience. But linking problems plague std.net.curl usage and both libs are permanently somewhat out of date. boost http is currently in review. Does it's mean that std.net.curl would be replaced by it? Could you give link to discussion? I guess it's Boost C++ http. Certainly has nothing to do with D and anyhow porting the whole C++ Boost (even just the relevant parts) to D is quite an effort. -- Dmitry Olshansky
Re: D for Game Development
On Friday, 7 August 2015 at 08:41:11 UTC, Dmitry Olshansky wrote: I guess it's Boost C++ http. Certainly has nothing to do with D and anyhow porting the whole C++ Boost (even just the relevant parts) to D is quite an effort. It is relevant since Boost libraries often are precursors to C++ standards and Walter has been clear on C++ compatibility as a goal. So it would be a mistake to not look at Boost http before designing a pure D http interface.
Re: D for Game Development
On 07-Aug-2015 12:16, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: On Friday, 7 August 2015 at 08:41:11 UTC, Dmitry Olshansky wrote: I guess it's Boost C++ http. Certainly has nothing to do with D and anyhow porting the whole C++ Boost (even just the relevant parts) to D is quite an effort. It is relevant since Boost libraries often are precursors to C++ standards and Walter has been clear on C++ compatibility as a goal. So it would be a mistake to not look at Boost http before designing a pure D http interface. Already have that it's called vibe.d. There must be other stuff floating around as well (e.g.Adam's tiny http server). -- Dmitry Olshansky
Re: D for Game Development
On Friday, 7 August 2015 at 09:43:13 UTC, Dmitry Olshansky wrote: Already have that it's called vibe.d. There must be other stuff floating around as well (e.g.Adam's tiny http server). That's not what I mean. I mean being able to interface with C++ counterparts in general. E.g. use the same structures, enums, etc on both sides.
Re: D for Game Development
On 8/08/2015 1:07 a.m., rsw0x wrote: On Friday, 7 August 2015 at 12:55:23 UTC, Andrei Alexandrescu wrote: On 8/6/15 6:48 PM, Tofu Ninja wrote: I really feel like D needs to get over it's not invented here syndrome, a much easier path would to just use a pre existing cross platform windowing library. I agree (though I don't know much about which library would be the best choice), at least on the basis of scarce resources. Large ambitious projects are a lot more fun to start than complete. -- Andrei Bare windowing libraries that are well tested already exist, like GLFW. To be fare, the most difficult part about a windowing library, is to make it behave identically on all platforms. For a Phobos out of the box implementation, we only need to get it close enough that programs can use it for prototyping. For anything serious, something like GLFW is definitely a better option. As long as we keep it well known about this and a migration path that isn't at all hard, I see no problem with doing this.
Re: D for Game Development
On Friday, 7 August 2015 at 13:07:59 UTC, rsw0x wrote: On Friday, 7 August 2015 at 12:55:23 UTC, Andrei Alexandrescu wrote: On 8/6/15 6:48 PM, Tofu Ninja wrote: I really feel like D needs to get over it's not invented here syndrome, a much easier path would to just use a pre existing cross platform windowing library. I agree (though I don't know much about which library would be the best choice), at least on the basis of scarce resources. Large ambitious projects are a lot more fun to start than complete. -- Andrei Bare windowing libraries that are well tested already exist, like GLFW. +1
Re: D for Game Development
On Friday, 7 August 2015 at 12:55:23 UTC, Andrei Alexandrescu wrote: On 8/6/15 6:48 PM, Tofu Ninja wrote: I really feel like D needs to get over it's not invented here syndrome, a much easier path would to just use a pre existing cross platform windowing library. I agree (though I don't know much about which library would be the best choice), at least on the basis of scarce resources. Large ambitious projects are a lot more fun to start than complete. -- Andrei The problem is that we get caught up with the API. The way forward that makes the most sense IMO, is to design some nice API and use whatever already exists behind. Less work, without the lock in.
Re: D for Game Development
On 8/6/15 6:48 PM, Tofu Ninja wrote: I really feel like D needs to get over it's not invented here syndrome, a much easier path would to just use a pre existing cross platform windowing library. I agree (though I don't know much about which library would be the best choice), at least on the basis of scarce resources. Large ambitious projects are a lot more fun to start than complete. -- Andrei
Re: D for Game Development
On Friday, 7 August 2015 at 12:55:23 UTC, Andrei Alexandrescu wrote: On 8/6/15 6:48 PM, Tofu Ninja wrote: I really feel like D needs to get over it's not invented here syndrome, a much easier path would to just use a pre existing cross platform windowing library. I agree (though I don't know much about which library would be the best choice), at least on the basis of scarce resources. Large ambitious projects are a lot more fun to start than complete. -- Andrei Bare windowing libraries that are well tested already exist, like GLFW.
Re: D for Game Development
On 07/08/15 00:48, Tofu Ninja wrote: I really feel like D needs to get over it's not invented here syndrome, a much easier path would to just use a pre existing cross platform windowing library. A bit more than a windowing library [1] [1] https://github.com/d-widget-toolkit/dwt -- /Jacob Carlborg
Re: D for Game Development
On Friday, 7 August 2015 at 17:40:16 UTC, deadalnix wrote: The problem is that we get caught up with the API. The way forward that makes the most sense IMO, is to design some nice API and use whatever already exists behind. Less work, without the lock in. I wouldn't think what you're saying is controversial...just a lot of work to do well. I imagine what you're saying as a two-step process: 1) Get a library working with D, 2) Write a nice API. I would likely get stuck on the first one before even getting to the second, but I wouldn't want to bore you with how confusing I find the documentation on interfacing to C. Anyway, I was thinking that magicport seems to be very important the process of creating ddmd. I would think we should be able to leverage this work for interfacing with C. In particular, interfacing with C requires the transformation of .h files to .di files. My assumption is that magicport is capable of converting lots of C++ files to D files, although my recollection of Daniel Murphy's talk is that there are some cases where it does not work perfectly and he has to adjust things manually. Regardless, if it works for C++, it should work for C, maybe even better since C is less complicated. So maybe magicport can be used to make it easier to get C libraries working with D. Then, you would just need to focus on writing the APIs.
Re: D for Game Development
On Friday, 7 August 2015 at 20:24:54 UTC, jmh530 wrote: Anyway, I was thinking that magicport seems to be very important the process of creating ddmd. I would think we should be able to leverage this work for interfacing with C. In particular, interfacing with C requires the transformation of .h files to .di files. My assumption is that magicport is capable of converting lots of C++ files to D files, although my recollection of Daniel Murphy's talk is that there are some cases where it does not work perfectly and he has to adjust things manually. Regardless, if it works for C++, it should work for C, maybe even better since C is less complicated. So maybe magicport can be used to make it easier to get C libraries working with D. Then, you would just need to focus on writing the APIs. We already have htod and DStep.
Re: D for Game Development
On Thursday, 6 August 2015 at 06:30:06 UTC, Rikki Cattermole wrote: On 6/08/2015 12:05 p.m., Tofu Ninja wrote: [...] [...] Here is what we need to do going forward (beyond what me and Manu are doing): [...] Don't you think that's a lot to ask from phobos?
