3 ms·

Oh by all means, don't get me started on what they did to IEnumerator or awaits. Plus they _really_ fell into a hole by trying to compete with Unreal from a gr

Oh by all means, don't get me started on what they did to IEnumerator or awaits. Plus they _really_ fell into a hole by trying to compete with Unreal from a graphics perspective, forcing them down the route of having to write a compiler xD https://docs.unity3d.com/Packages/com.unity.burst@0.2/manual/index.html https://docs.unity3d.com/Packages/com.unity.burst@0.2/manual...

torginus 5y ago
Unity made tons of strange decisions over its lifetime. Like first, they picked .NET and it's Mono implementation, which wasn't as fast as the original one, but was decent - then they kicked up some stink with the Mono devs, leading to them shipping a Mono version that was at a point a decade out of date, and performed way worse than either Mono and .NET. Their first idea was, instead of updating Mono, what if they compiled .NET IL to C++, resulting in the monstrosity that was IL2CPP. If you are interested in what sort of C++ code it generated, here's a link: https://www.jacksondunstan.com/articles/4654 https://www.jacksondunstan.com/articles/4654 It's full of goto-s, helper method calls, and passing around these weird helper objects to every method. They triumphantly announced their perf gains - compared to their own old impl, which I remember being slower than Python at times. Then came Burst/ECS, like you mentioned, the former of which is working pretty well, but requires you to rewrite your C# code, with Unity-licenced dependencies, so even if you wrote a kickass dynamic tessellation library, it could be only used in Unity, because of said deps. The latter is still in forever Unity innovation limbo. Meanwhile in Unreal-land, they used pretty much standard C++, for a decade, no arcane space-magic ECS found here - and the code has been pretty much stable for that time.
- oblio 5y ago
  > Unity made tons of strange decisions over its lifetime. Heh. None of those of those decisions seem strange once you view them through the lens of some game devs full of hubris :-)

torginus 5y ago

Unity made tons of strange decisions over its lifetime. Like first, they picked .NET and it's Mono implementation, which wasn't as fast as the original one, but was decent - then they kicked up some stink with the Mono devs, leading to them shipping a Mono version that was at a point a decade out of date, and performed way worse than either Mono and .NET. Their first idea was, instead of updating Mono, what if they compiled .NET IL to C++, resulting in the monstrosity that was IL2CPP. If you are interested in what sort of C++ code it generated, here's a link: https://www.jacksondunstan.com/articles/4654 https://www.jacksondunstan.com/articles/4654 It's full of goto-s, helper method calls, and passing around these weird helper objects to every method. They triumphantly announced their perf gains - compared to their own old impl, which I remember being slower than Python at times. Then came Burst/ECS, like you mentioned, the former of which is working pretty well, but requires you to rewrite your C# code, with Unity-licenced dependencies, so even if you wrote a kickass dynamic tessellation library, it could be only used in Unity, because of said deps. The latter is still in forever Unity innovation limbo. Meanwhile in Unreal-land, they used pretty much standard C++, for a decade, no arcane space-magic ECS found here - and the code has been pretty much stable for that time.

oblio 5y ago
> Unity made tons of strange decisions over its lifetime. Heh. None of those of those decisions seem strange once you view them through the lens of some game devs full of hubris :-)