On Friday, 28 March 2025 at 22:44:56 UTC, Hipreme wrote:

It turned out to be debug code in a shader that was accidentally getting compiled in. The debug code checked a constant buffer value indicating whether the level editor was active, and if so it disabled the paint-in effect (and just made everything fully painted in).

In release, we don't bother ever setting this isLevelEditorActive parameter, since the editor is compiled out of the release build and thus unusable. But this bad debug code was still using the parameter. And since nobody was setting the value, the value was unspecified. On most GPUs/drivers, it seemed to be defaulting to 0, aka no editor, so it worked out by accident. But when using Proton, for whatever reason, it didn't default to 0 and instead had random unspecified values, so it flickered between on and off.

A classic case of a bug that was occurring on all machines, but only actually showing observable symptoms on a select few. The good news is that I installed a Ubuntu dual boot in order to track this down, so I can now just test on Proton as a matter of course when pushing out updates.

On Wednesday, 2 April 2025 at 09:37:44 UTC, Lewis wrote:

Oh that makes a lot of sense! There exists a lot of issues in regard of unused shader variables, so, it is a must check every time. On OpenGL, for example, if a variable is unused, it might get removed from the shader and trying to set it somewhere will cause issues. Uninitialized is almost on the same ground of undefined behavior

On Monday, 24 February 2025 at 03:08:11 UTC, Lewis wrote:

Congrats on getting the demo out! I guess that means there's at least 2 pieces of DLang software on steam now, heh. It is a little disheartening to see the strict dependency on DX11 though. I do happen to have porting experience w/ Metal and Vulkan, so if you wish to natively port your code to macOS and Linux do feel free to poke me! (+ I offer contract porting services through my business if that has any interest)

On Monday, 24 February 2025 at 03:08:11 UTC, Lewis wrote:

I'm so glad you posted this! I've done many game projects (usually D and DAllegro) for many many years but nothing worth completing. I've written similar things with static pools for everything, and for strings I massively sped things up by writing a simple static string class that just allocates larger if it needs to be. Before when I started storing debug data inside my game objects, I was hitting like 1500 allocations a second, it was absurd. I've long wondered about using DLLs, as well as template compilation time. I remember when simply including std.regex quadrupled my compile time.

Have you considered doing a blog writeup on your experiences, hacks, and changes? I'd love to read it.