Re: Options for Cross-Platform 3D Game Development
On Wednesday, 5 July 2023 at 22:27:46 UTC, Andrew wrote: So, I've gotten the itch to have a go at game development in D, after doing a bit of it in Java last year. I've previously used LWJGL, which is a java wrapper for OpenGL, OpenAL, GLFW, and some other useful libs. The problem is, apparently OpenGL is deprecated for apple devices, so I don't really want to use that unless there are no decent alternatives. So far, the most promising I've seen is [bindbc-bgfx](https://code.dlang.org/packages/bindbc-bgfx), but it's been a pain to set up due to having to build the bgfx codebase, which requires a specific version of glibc that my distro (Linux Mint) doesn't offer yet. Are there any other recommendations for cross-platform rendering libraries? Of course I could use a pre-made game engine like Unity or Godot, but for me, most of the fun is in making the engine. To be honest, I'm accepting anyone on Hipreme Engine that is willing to help adding a shader transpiler or cross compiler. Right now I got an abstraction over opengl, direct3d and metal, for almost every basic stuff out there, which is really simple. Having the shaders being written once is pretty much the next step but I can't focus on that. You'll have a better experience with Hipreme Engine than mostly of the options you get here since you'll have a complete cross compilation env for you requiring no configuration at all.
Re: Options for Cross-Platform 3D Game Development
On Wednesday, 5 July 2023 at 22:27:46 UTC, Andrew wrote: So, I've gotten the itch to have a go at game development in D, after doing a bit of it in Java last year. I've previously used LWJGL, which is a java wrapper for OpenGL, OpenAL, GLFW, and some other useful libs. Are there any other recommendations for cross-platform rendering libraries? Of course I could use a pre-made game engine like Unity or Godot, but for me, most of the fun is in making the engine. There is a Hipreme Engine (written in D): Check it out on the GitHub: https://github.com/MrcSnm/HipremeEngine
Re: Options for Cross-Platform 3D Game Development
On Wednesday, 5 July 2023 at 22:27:46 UTC, Andrew wrote: So, I've gotten the itch to have a go at game development in D, after doing a bit of it in Java last year. I've previously used LWJGL, which is a java wrapper for OpenGL, OpenAL, GLFW, and some other useful libs. The problem is, apparently OpenGL is deprecated for apple devices, so I don't really want to use that unless there are no decent alternatives. So far, the most promising I've seen is [bindbc-bgfx](https://code.dlang.org/packages/bindbc-bgfx), but it's been a pain to set up due to having to build the bgfx codebase, which requires a specific version of glibc that my distro (Linux Mint) doesn't offer yet. Are there any other recommendations for cross-platform rendering libraries? Of course I could use a pre-made game engine like Unity or Godot, but for me, most of the fun is in making the engine. Are you trying to make a PC game, or a mobile game? Because in 99% of cases I would pick a different toolchain for mobile than PC. OpenGL being depreciated on a single, walled-garden platform, does not rule it out for the entire rest of installed systems. Only if I absolutely needed, cross-platform out-of-the-box with mobiles and PC, would I pick a package like, Xamarin. Which now forces me to use C#, and the size bloat of including a mono framework with all my apps. I would not pick Xamarin just because I wanted to keep my options open, I would d pick it because I have a planned application that needed to be 1:1 synced across iPhone, Android (and possibly PC). There's also other options. Such as using a OpenGL -> Metal conversion layer, like MetalAngle: https://github.com/kakashidinho/metalangle https://chromium.googlesource.com/angle/angle So be sure exactly what you want as the best tools for the job will depend greatly on the requirements of the project.
Re: Options for Cross-Platform 3D Game Development
On Wednesday, 5 July 2023 at 22:27:46 UTC, Andrew wrote: So, I've gotten the itch to have a go at game development in D, after doing a bit of it in Java last year. I've previously used LWJGL, which is a java wrapper for OpenGL, OpenAL, GLFW, and some other useful libs. The problem is, apparently OpenGL is deprecated for apple devices, so I don't really want to use that unless there are no decent alternatives. So far, the most promising I've seen is [bindbc-bgfx](https://code.dlang.org/packages/bindbc-bgfx), but it's been a pain to set up due to having to build the bgfx codebase, which requires a specific version of glibc that my distro (Linux Mint) doesn't offer yet. Are there any other recommendations for cross-platform rendering libraries? Of course I could use a pre-made game engine like Unity or Godot, but for me, most of the fun is in making the engine. Lately I've been diligently updating BindBC-bgfx because bgfx is seriously really good. About your glibc problem, you can use an older version of bgfx (which might mean 1. you have to use the old BindBC-bgfx API, or 2. run the *newest* [binding generator script](https://github.com/BindBC/bindbc-bgfx/#generating-bindings) on an older version of bgfx; rather than running the old generator script that comes with that older version), or you can build and install a newer version of GDC yourself, which is what I did. It's VERY slow to build, but relatively painless otherwise. bgfx is a little bit confusing for a first-time user, but if you have any trouble setting it up try searching through the bgfx Discord server, and if you can't find the answer that way then just ask for help there. Its documentation is alright but some of the English in it isn't the best. Once you're familiar with it, it's a really simple and powerful API that can do basically anything, but it's all rendering backend-agnostic. On Wednesday, 5 July 2023 at 23:53:41 UTC, ryuukk_ wrote: If you need something that provides you an API to render things directly without doing raw GPU commands, then RayLib is excellent, you can still build your engine around it, it act like a framework a la libGDX/XNA/MonoGame - https://github.com/schveiguy/raylib-d If you want to create your own engine from scratch, then Vulkan (works on mobile/linux/windows and macOS via moltenvk) I wouldn't really recommend Raylib unless you only plan to use fairly rudimentary 3D, as I've found its 3D rendering to be very limited. Unlike bgfx it can't do compute shaders, read-back from the GPU, instancing, 32-bit index buffers, etc. [Raylib's cheatsheet](https://www.raylib.com/cheatsheet/cheatsheet.html) should give you an idea of what you CAN do with its API. On Wednesday, 5 July 2023 at 23:53:41 UTC, ryuukk_ wrote: If you want to create your own engine from scratch, then Vulkan (works on mobile/linux/windows and macOS via moltenvk) Vulkan is also a really good option, and probably a bit faster than bgfx (or OpenGL obviously), but its API is very complicated. My head nearly exploded trying to use Vulkan, and I never got to the point of rendering 1 triangle. If you think you're enough of a genius then I'd say at least give it a shot. Worst case scenario is you give up after spending a day or two trying to learn it. P.S. I'm planning on adding a native-D bgfx backend to BindBC-ImGui 1.0 (my WIP bindings to the ImGui C++ API), if that's of interest to you. ;)
Re: Options for Cross-Platform 3D Game Development
Oh, and i forgot to mention Sokol, great C library, i couldn't find D bindings, so you'll have to create your own (it's trivial) https://github.com/floooh/sokol
Re: Options for Cross-Platform 3D Game Development
On Wednesday, 5 July 2023 at 22:27:46 UTC, Andrew wrote: So, I've gotten the itch to have a go at game development in D, after doing a bit of it in Java last year. I've previously used LWJGL, which is a java wrapper for OpenGL, OpenAL, GLFW, and some other useful libs. The problem is, apparently OpenGL is deprecated for apple devices, so I don't really want to use that unless there are no decent alternatives. So far, the most promising I've seen is [bindbc-bgfx](https://code.dlang.org/packages/bindbc-bgfx), but it's been a pain to set up due to having to build the bgfx codebase, which requires a specific version of glibc that my distro (Linux Mint) doesn't offer yet. Are there any other recommendations for cross-platform rendering libraries? Of course I could use a pre-made game engine like Unity or Godot, but for me, most of the fun is in making the engine. Depends what you really want to do If you need something that provides you an API to render things directly without doing raw GPU commands, then RayLib is excellent, you can still build your engine around it, it act like a framework a la libGDX/XNA/MonoGame - https://github.com/schveiguy/raylib-d If you want to create your own engine from scratch, then Vulkan (works on mobile/linux/windows and macOS via moltenvk) Or you can use WebGPU, despite its name it's crossplatform, targets Web via wasm (with LDC, requires some extra work tho), Windows, Linux, macOS, mobiles - https://github.com/gecko0307/bindbc-wgpu
Options for Cross-Platform 3D Game Development
So, I've gotten the itch to have a go at game development in D, after doing a bit of it in Java last year. I've previously used LWJGL, which is a java wrapper for OpenGL, OpenAL, GLFW, and some other useful libs. The problem is, apparently OpenGL is deprecated for apple devices, so I don't really want to use that unless there are no decent alternatives. So far, the most promising I've seen is [bindbc-bgfx](https://code.dlang.org/packages/bindbc-bgfx), but it's been a pain to set up due to having to build the bgfx codebase, which requires a specific version of glibc that my distro (Linux Mint) doesn't offer yet. Are there any other recommendations for cross-platform rendering libraries? Of course I could use a pre-made game engine like Unity or Godot, but for me, most of the fun is in making the engine.
Re: D, Game Development, GLSL, Math
On Saturday, 1 July 2017 at 19:23:57 UTC, Void-995 wrote: Looking good, but I'm thinking more about 1:1 GLSL syntax (main reason - rapid prototype of GLSL/HLSL/OpenCL in D and code portability back and forward basing on usage) and heavy depending on SIMD. Just math and nothing else. Also may be a nice excersise for myself. You can just depend on the subpackage gfm:math. Is 1:1 GLSL syntax that good? In GLSL: - per-item max is just called "max" which clashes with Phobos. Most GLSL function names clash with Phobos which creates errors when both are imported. - mat3x4 is a 3 column by 4 rows types, which is kind of a trap. - vec4 does not say it's 4 floats whereas vec4f does - "lerp" might be a better name than "mix" - etc...
Re: D, Game Development, GLSL, Math
On Saturday, 1 July 2017 at 19:07:48 UTC, Void-995 wrote: can i use simd as base to extend it's syntax for making something like GLM for C++? You can use simd to implement something like GLM, but extending the syntax of SIMD will prove more difficult. vector types are a bit different in LDC and DMD, also DMD 32-bit won't support D_SIMD. https://github.com/jkrempus/pfft is the only library I know that abstracts over the varied D SIMD capabilities, and possibly work with all compilers.
Re: D, Game Development, GLSL, Math
On Saturday, 1 July 2017 at 19:23:57 UTC, Void-995 wrote: On Saturday, 1 July 2017 at 19:16:12 UTC, drug wrote: 01.07.2017 22:07, Void-995 пишет: (Void-995) Hi, everyone. I'm pretty excited with what have D to offer for game development, especially meta programming, traits, object.factory, signals and bunch of other neat things that may save a lot of time. Also, i saw support for vector data types and simd, which sounds awesome. The question is, can i use simd as base to extend it's syntax for making something like GLM for C++? I mean extending existing types with new operators and such to have GLSL/HLSL like syntax for basis math operation in D? Maybe someone did that already? Look at gfm https://code.dlang.org/packages/gfm Looking good, but I'm thinking more about 1:1 GLSL syntax (main reason - rapid prototype of GLSL/HLSL/OpenCL in D and code portability back and forward basing on usage) and heavy depending on SIMD. Just math and nothing else. Also may be a nice excersise for myself. "Changing the syntax" can be done (e.g. https://github.com/p0nce/intel-intrinsics) You'll want to look at the operator overloading that can be done in D (spec https://dlang.org/spec/operatoroverloading.html) As a side note: I'll soon be starting work on DCompute[1] again (Honours thesis due tomorrow), integrating John Colvin's CLWrap among many other things. [1]https://github.com/libmir/dcompute
Re: D, Game Development, GLSL, Math
On Saturday, 1 July 2017 at 19:16:12 UTC, drug wrote: 01.07.2017 22:07, Void-995 пишет: (Void-995) Hi, everyone. I'm pretty excited with what have D to offer for game development, especially meta programming, traits, object.factory, signals and bunch of other neat things that may save a lot of time. Also, i saw support for vector data types and simd, which sounds awesome. The question is, can i use simd as base to extend it's syntax for making something like GLM for C++? I mean extending existing types with new operators and such to have GLSL/HLSL like syntax for basis math operation in D? Maybe someone did that already? Look at gfm https://code.dlang.org/packages/gfm Looking good, but I'm thinking more about 1:1 GLSL syntax (main reason - rapid prototype of GLSL/HLSL/OpenCL in D and code portability back and forward basing on usage) and heavy depending on SIMD. Just math and nothing else. Also may be a nice excersise for myself.
Re: D, Game Development, GLSL, Math
01.07.2017 22:07, Void-995 пишет: (Void-995) Hi, everyone. I'm pretty excited with what have D to offer for game development, especially meta programming, traits, object.factory, signals and bunch of other neat things that may save a lot of time. Also, i saw support for vector data types and simd, which sounds awesome. The question is, can i use simd as base to extend it's syntax for making something like GLM for C++? I mean extending existing types with new operators and such to have GLSL/HLSL like syntax for basis math operation in D? Maybe someone did that already? Look at gfm https://code.dlang.org/packages/gfm
D, Game Development, GLSL, Math
(Void-995) Hi, everyone. I'm pretty excited with what have D to offer for game development, especially meta programming, traits, object.factory, signals and bunch of other neat things that may save a lot of time. Also, i saw support for vector data types and simd, which sounds awesome. The question is, can i use simd as base to extend it's syntax for making something like GLM for C++? I mean extending existing types with new operators and such to have GLSL/HLSL like syntax for basis math operation in D? Maybe someone did that already?
Re: Game Development Using D
On Saturday, 21 May 2016 at 15:53:18 UTC, David wrote: Hi, I want to try to create a game using D. I'm a complete newbie though (other than having C/C++ experience). Where would I start? Does D have an openGL binding? I am assuming I'll need to leverage a good amount C APIs? Any list of these that would be useful it a game setting? Obviously this all depends on *how* much work I want to do. Ideally, I'd like a collection of tools that will get me roughly the equivalent of what XNA provides. If you don't know much OpenGL, go for DSFML https://github.com/Jebbs/DSFML
Re: Game Development Using D
On Saturday, 21 May 2016 at 15:53:18 UTC, David wrote: Hi, I want to try to create a game using D. I'm a complete newbie though (other than having C/C++ experience). Where would I start? Does D have an openGL binding? I am assuming I'll need to leverage a good amount C APIs? Any list of these that would be useful it a game setting? Obviously this all depends on *how* much work I want to do. Ideally, I'd like a collection of tools that will get me roughly the equivalent of what XNA provides. In DlangUI there is Tetris game example Repository: https://github.com/buggins/dlangui Tetris: https://github.com/buggins/dlangui/tree/master/examples/tetris Clone repository, cd dlangui/examples/tetris, dub run As well, there are OpenGL example https://github.com/buggins/dlangui/tree/master/examples/opengl and DMiner example (minecraft-like rendering engine) https://github.com/buggins/dlangui/tree/master/examples/dminer
Re: Game Development Using D
On Saturday, 21 May 2016 at 15:53:18 UTC, David wrote: Hi, I want to try to create a game using D. I'm a complete newbie though (other than having C/C++ experience). Where would I start? Does D have an openGL binding? I am assuming I'll need to leverage a good amount C APIs? Any list of these that would be useful it a game setting? Obviously this all depends on *how* much work I want to do. Ideally, I'd like a collection of tools that will get me roughly the equivalent of what XNA provides. Also forgot to add this : http://defenestrate.eu/_static/ossvikend/intro-gamedev-d/slides/index.html It's an intro to D game dev
Re: Game Development Using D
On Saturday, 21 May 2016 at 15:53:18 UTC, David wrote: Hi, I want to try to create a game using D. I'm a complete newbie though (other than having C/C++ experience). Where would I start? Does D have an openGL binding? I am assuming I'll need to leverage a good amount C APIs? Any list of these that would be useful it a game setting? Obviously this all depends on *how* much work I want to do. Ideally, I'd like a collection of tools that will get me roughly the equivalent of what XNA provides. I use GFM, https://github.com/d-gamedev-team/gfm It's pretty easy to use and saves alot of headache. Downside is that the documentation is somewhat outdated (namely close() functions are deprecated, you have to use the destroy attribute, or typecons). SDL + OpenGL is easy with GFM. here is a good opengl tutorial : http://www.learnopengl.com/
Re: Game Development Using D
On Saturday, 21 May 2016 at 16:01:26 UTC, Stefan Koch wrote: On Saturday, 21 May 2016 at 15:53:18 UTC, David wrote: Hi, I want to try to create a game using D. I'm a complete newbie though (other than having C/C++ experience). Where would I start? Does D have an openGL binding? I am assuming I'll need to leverage a good amount C APIs? Any list of these that would be useful it a game setting? Obviously this all depends on *how* much work I want to do. Ideally, I'd like a collection of tools that will get me roughly the equivalent of what XNA provides. The is derilict-gl and then there is the dgame library Check out the DerelictOrg bindings in general: https://github.com/DerelictOrg In particular DerelictAssimp3 might help with animation and scene loading. Other related game libraries are in the dub registry: https://code.dlang.org/search?q=game
Re: Game Development Using D
On Saturday, 21 May 2016 at 15:53:18 UTC, David wrote: Hi, I want to try to create a game using D. I'm a complete newbie though (other than having C/C++ experience). Where would I start? Does D have an openGL binding? I am assuming I'll need to leverage a good amount C APIs? Any list of these that would be useful it a game setting? Obviously this all depends on *how* much work I want to do. Ideally, I'd like a collection of tools that will get me roughly the equivalent of what XNA provides. The is derilict-gl and then there is the dgame library
Game Development Using D
Hi, I want to try to create a game using D. I'm a complete newbie though (other than having C/C++ experience). Where would I start? Does D have an openGL binding? I am assuming I'll need to leverage a good amount C APIs? Any list of these that would be useful it a game setting? Obviously this all depends on *how* much work I want to do. Ideally, I'd like a collection of tools that will get me roughly the equivalent of what XNA provides.
What is the state of D for game development?
I am stealing HerrDrFaust's question from the following Reddit thread: https://www.reddit.com/r/programming/comments/3wqt3p/programming_in_d_ebook_is_at_major_retailers_and/ Please answer here or there. Thank you, Ali
Re: What is the state of D for game development?
On Thursday, 17 December 2015 at 17:38:31 UTC, Ali Çehreli wrote: I am stealing HerrDrFaust's question from the following Reddit thread: https://www.reddit.com/r/programming/comments/3wqt3p/programming_in_d_ebook_is_at_major_retailers_and/ Please answer here or there. Thank you, Ali Well, we have some bindings to game dev libraries, but the ecosystem isn't nearly as rich as what's available with C++. Derelict has bindings to almost all the "basic" libraries, though. I've been working on a binding to Bullet Physics, but it's stalled while I wait on a DMD pull request that I put in to allow the kind of introspection my method requires.
Re: What is the state of D for game development?
On Friday, 18 December 2015 at 00:03:06 UTC, extrawurst wrote: What PR is that ? Link ? --Stephan https://github.com/D-Programming-Language/dmd/pull/5290 It adds some __traits that would make it easier for me to introspect my binding modules and generate glue code. Right now, I'm using several stages of build tools which loop over the actual source files to generate the necessary code, which has gotten quite ugly. With the right __traits, it's possible to cut out some steps. Once I've refactored everything, it might actually be a viable method to bind all sorts of C++ libraries.
Re: What is the state of D for game development?
On Thursday, 17 December 2015 at 17:46:15 UTC, BLM768 wrote: On Thursday, 17 December 2015 at 17:38:31 UTC, Ali Çehreli wrote: I am stealing HerrDrFaust's question from the following Reddit thread: https://www.reddit.com/r/programming/comments/3wqt3p/programming_in_d_ebook_is_at_major_retailers_and/ Please answer here or there. Thank you, Ali Well, we have some bindings to game dev libraries, but the ecosystem isn't nearly as rich as what's available with C++. Derelict has bindings to almost all the "basic" libraries, though. I've been working on a binding to Bullet Physics, but it's stalled while I wait on a DMD pull request that I put in to allow the kind of introspection my method requires. What PR is that ? Link ? --Stephan
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