Yes, but never got back to 100%
Lots of walks in the woods and figuring out what it is that motivates and making sure not to do things that are not that.
As a gamedev that tried shipping to linux, we really need some standardized minimized image to target with ancient glibc and such, and some guarantees that if it runs on the image that it runs on future linux versions.
Mensa has been great for me, even met my wife there.
OF course if we were simply successful and felt we fit in we wouldn't have sought out such an organization.
Because the hot paths in the code are not the majority of the code.
C# is (for me) much more productive to write than c++.
More powerful refactoring tooling due syntax that is much easier for tooling to process.
Powerful autocomplete, autorefactoring tooling.
Easy code navigation due to easy to process syntax.
The tooling also responds much faster, c++ refactoring tools seem to take a long time to process code.
Big reduction in footguns/UB etc.
Very quick iteration cycles, edit-and-continue in sub second, stop-edit-restart cycles in the low single second range.
Very good debugging, objects are inspectable and editable, stacktraces reliable.
Edit-and-continue makes for very quick probing of internal state.
The c++ code is around 1% of LOC and 20% of cpu cycles, seems like a good balance.
Bounds checking, lack of dangling pointers/use after free, removes a whole class of hard to debug bugs.
A few other commenters hit the points better, but mostly it comes down to avoiding allocating objects every frame/tick.
In part this is through avoiding LINQ, lambdas, yield return, async etc. (fine to use in code that is run once like startup, or on relatively rare triggers)
Using struct, arrays of struct/value, Span<>, ref, fixed etc. to keep memory access sequential or on stack.
Use mutable structs, avoiding properties, avoiding struct constructors, moving throws into utility methods, etc. to support (the rather weak) optimizer to do more inlining.
And move data processing of arrays of struct with tight loops, like compression, lighting, meshing, pathfinding into a native c++ dll/so or if applicable gpu. (c++ autovec/simd optimizations or much better than what the clr optimizer currently provides)
My last 8 yrs of game development have been in a good part about how to make c# go fast, and it is definitely possible, but you will have to write in a style that is different from the norm.
Thank you for backing his work, his posts and twitter feed are a gold mine for some pretty unique ideas in signed distance field and other rendering research.
That has been a consistent pattern in .net, where the liked current tech withers on the vine to make place for the new thing. Instead of the new thing proving itself organically.
We knew our windows version wasn't going to work with proton so we made a native linux version that works on steamos.
Sadly we remain listed as Unsupported on steamdeck as it seems to really want to use the broken windows version through proton instead of the working linux native version.
One reason folks can't move to more affordable cities is the companies seem stuck in each others gravity well and keep bunching up in just a few unaffordable spot.