Re: Demo for The Art of Reflection released (a 3D game and engine fully written in D)
On Friday, 24 May 2024 at 19:22:32 UTC, Jonathan Gerlach wrote: I'm impressed. Are you using DirectX "11 on 12" or standard DirectX11? Did you need to avoid the GC at all? I imagine the GC could ruin your framerate if you're not careful. Thanks for sharing and congrats on finishing (close enough) your game. Plain old DX11. I've used DX12 in industry, and it basically amounts to opting in to writing 70% of the graphics driver along with your renderer :) I don't need to push AAA levels of performance or asset load for this game, so DX11 is fine. Regarding the GC, copy-pasting my reply from Discord: I don't have the GC fully disabled, but I make a point to avoid GC allocations in runtime code. I allow myself to use it for initialization, tooling, editor code, etc. For runtime code it really just acts as a fallback. If I messed something up, a memory leak just becomes a periodic hitch instead of an eventual crash. I've also hacked some changes into druntime to help with this: - I added a "scrapheap" GC implementation, which is a simple linear allocator that resets at the end of each frame. I have a mixin that makes a scope use the scrapheap instead of the regular GC, which is useful for allowing me to still use phobos or other libraries, as long as I'm okay with all allocated memory being discarded at the end of the frame. Each worker thread also gets one, which resets when a unit of work completes. - I added a quick and dirty mode I can enable that logs the callstack of every GC allocation, to help me track down stray allocations that occur during runtime. @nogc is too restrictive, and doesn't understand that my scrapheap usage bypasses the GC. Runtime allocations that need to stick around almost entirely use a structure I've internally called a GenerationalStorage. Pretty common idea in games, a fixed size object pool that hands out IDs, and IDs can be used to retrieve a pointer to the object. Each ID contains the object's index, along with a generation number that increments every allocation, letting you reliably catch and assert on any use-after-frees of IDs.
Demo for The Art of Reflection released (a 3D game and engine fully written in D)
Hello! Not sure if it's of interest, but I've been developing a 3D game and engine in D for a few years, and finally have a demo up on Steam for anyone interested in poking around (Windows only unfortunately). - All code (engine and game) written in D. Shaders in HLSL. External libraries used for some subsystems (eg. PhysX, FMOD) - Custom 3D DX11 renderer using PBR + IBL - Supports mirror rendering, with hundreds of simultaneous mirrors and recursive mirrors (passing seamlessly through mirrors is a core game mechanic) - Asset burning/cooking system for textures, geometry, materials, and shaders. All asset types support hotswapping. - Flexible code hotswapping, by putting 99% of the game and engine in a DLL - Scrappy in-game level editor that supports editing during gameplay Since I'm building the game as a commercial project I haven't released source code, but plan to open source it after the game releases. Happy though of course to answer any questions, share code snippets, techniques, general experiences, etc. https://store.steampowered.com/app/2290770/The_Art_of_Reflection/
Re: Visual D 0.44 released - VC project integration and Concord debugger extension
On Sunday, 12 March 2017 at 12:09:10 UTC, Rainer Schuetze wrote: Hi, I'm glad to finally announce the release of a new version of Visual D, the Visual Studio extension for the D programming language. [...] This looks awesome, thanks Rainer!
Re: Release D 2.071.0
On Thursday, 7 April 2016 at 07:44:48 UTC, Nordlöw wrote: On Tuesday, 5 April 2016 at 22:43:05 UTC, Martin Nowak wrote: Glad to announce D 2.071.0. I read somewhere recently about performance regressions in DMD. Were these related the import and module fixes? Were they fixed? Do they depend on any dmd switches? Thanks anyway! I just updated one of my projects from 2.069.0 to 2.071.0, and saw the build time jump from ~1.7s to ~2.5s. Take this single informal data point with a huge grain of salt obviously, but I am also curious about the details of this. DMD's speed is one of D's selling points to me, and I might roll back until performance improves if there isn't a straightforward fix. Agreed though, otherwise a great release. Thanks for everyone's hard work!
