I made a game and engine in D that's a cross between Superliminal and Viewfinder, and you can play the demo now

Lewis musicaljelly at gmail.com
Thu Feb 27 09:24:59 UTC 2025


On Wednesday, 26 February 2025 at 16:21:20 UTC, Michael Lee wrote:
> On Monday, 24 February 2025 at 10:51:09 UTC, Lewis wrote:
>> I don't strictly use betterC, but I do avoid GC usage in all 
>> frame-to-frame gameplay code. I allow myself GC usage for 
>> debug code, editor tools, and major state changes where a 
>> hitch is okay (eg. startup, loading a save game).
>>
>> The bulk of my frame-to-frame allocations are handled by an 
>> object pooling system that reuses elements and grows if 
>> needed. I also have a per-thread linear allocator that resets 
>> after each frame, useful for scratch allocations that don't 
>> need to outlive a frame. I made some minor changes to druntime 
>> so that in any given scope I can switch into "scrapheap mode" 
>> as I call it, at which point all GC allocations get redirected 
>> to my linear allocator until the scope exits. This lets me use 
>> phobos, druntime, and other libraries even if they would 
>> allocate to the GC in a problematic way. As long as the 
>> allocation doesn't need to outlive the frame, I can use the 
>> library unmodified by just switching into scrapheap mode.
>
> This sounds ideal to me. How much of phobos did you mod? What 
> kind of lift was it? Does it take much maintenance? Does using 
> phobos feel seamless or is there some reluctance/superstition 
> about using it in complex scenarios e.g. threads.
>
> I'm an indie game dev, and am moving to D from C++. Congrats on 
> the release! The game looks fantastic. A crowning achievement 
> for a solo dev.

I didn't make all that many changes, and I don't think any of 
them were strictly mandatory to ship a game. They broadly fall 
into a few catagories:
- Support for "scrapheap mode" (temporarily rerouting GC 
allocations to a linear frame allocator)
- Support for DLL-based hotswapping. This required piping a few 
calls in the DLL's druntime/phobos over to the EXE's druntime 
(eg. using a GC proxy, thread management). Also, a couple small 
changes to stuff like the GC initialization in the DLL so the 
proxy gets set up correctly. This was completely worth it, DLL 
hotswapping is a gamechanger, just a massive improvement to 
iteration time. My changes are a tad hacky, but the release build 
of the game skips the DLL and links everything statically, so any 
bugs from this hackiness are debug-only.
- Reducing build times. I use string formatting absolutely 
everywhere, so in debug I use the old C-style string formatting 
implementation, since it's non-templated and compiles very 
slightly faster (which for 10 calls is pointless, but 1000 calls 
it adds up).
- Added a couple minor features to the phobos thread pool 
implementation
- Added some missing bits of the windows API
- Modified std.experimental.logger to better suit my exact needs 
(and use no templates, again I log everywhere and want to keep 
build times fast)

I use phobos all over the place without any issues.


More information about the Digitalmars-d-announce mailing list