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/

On Friday, 24 May 2024 at 17:45:31 UTC, Lewis 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.

On Friday, 24 May 2024 at 19:22:32 UTC, Jonathan Gerlach wrote:

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.

On Friday, 24 May 2024 at 17:45:31 UTC, Lewis wrote:

Seems worthy of a DConf presentation!

-- Bastiaan.

On Friday, 24 May 2024 at 17:45:31 UTC, Lewis wrote:

Nice, experience is quite smooth.
But it does feel a bit like a tech demo. I want to know why I am trying to get out of this wizard home. Maybe he is also walking around here and I need to hide my movement from him as well later in the game :)

On Friday, 24 May 2024 at 17:45:31 UTC, Lewis wrote:

I've just played through the demo, it's impressive! It's a pleasantly confusing experience and my brain hurts now. Also, it works perfectly fine on Linux via Proton.

On Tuesday, 18 June 2024 at 08:49:57 UTC, cookiewitch wrote:

Added to my wishlist, as I always like to share with others projects built in D :)