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