Well libraries such as firebase have java/native code on android as well, so intercepting Path.GetFullPath won’t be a safe bet anyways
That’s quite bizarre, and I absolutely believe you.
1 Like
Unity Tuanjie is based on Unity 2022 LTS, so it lags behind Unity 6 in many aspects, and the two are no longer likely to merge. Since the trade war began in 2018, all companies may be sanctioned at any time, thus interrupting the authorization of various hardware and software. Therefore, China has to maintain its own hardware, operating system, database, application software, and AI.
Frankly, unity 2022 is more stable than unity 6 in many aspect. Thee are many regression since 2023 and continued in to version 6. If they have succeed in changing dotnet version with unity 2022 I would not think they are lagged behind
By the time baseline Unity has the new scripting runtime Tuanjie will likely have surpassed Unity 6. Certainly in the ways that matter to most developers if not in every way.
Yes, sometimes I wonder why Unity has 7,000 employees, but everything is developing so slowly. The new animation system, CoreCLR, World Building, all the features that should have existed a long time ago, now only exist on PPT.
4 Likes
They don’t. After the big rounds of layoffs and closures they should be below 5,000 people.
3 Likes
They want to be on 25+ platforms => because of that, they need to have legacy C++ codebase they don’t want to get rid of and when you have such a messy and legacy codebase, development is very slow.
They need to do low level compiler stuff, instead of letting Microsoft to do that, and that is slowing them significantly.
They want to achieve more than they are actually able to !!!
Even Microsoft have done exactly what I am proposing with the .NET Framework itself.
They once realized, they need to do the complete restart and deep modernization, so they created .NET Core, which is absolutely not compatible with the legacy .NET Framework, and they were working hard for many years, to make it as powerful as the legacy .NET Framework.
But now? Microsoft is able to develop rapidly !!!
Sometimes, this is the only way to move forward, to kill the legacy bullshit altogether, and to not care about backward compatibility while modernizing…
Unity should become .NET only, and they should stop to mix .NET with their legacy C++ codebase!
But Unity is just not brave enough to do this, and it might kill them in few years !!!
Once we finally release our first game in Unity and make some money, I want to switch to Stride (modern, free and open-source game engine purely on top of .NET 8 already !!! ), because this Unity situation is making me very sad 
11 Likes
Do you understand what are you asking Unity to do? .Net is only a scripting backend. Rewriting Unity itself to use only .Net is not only insanely expencive, but will take unreal amounts of time and probably will degrade performance AND engine capabilities. If the only thing of your concern is new fancy syntax sugar added in new .Net, then maybe you should consider moving to other solution earlier.
Comparing .Net Framework to .Net Core transition to what you propose Unity to do is also very weird, considering .Net is just a solution managed by a company (while it’s sponsored by all the Microsoft products and is not the main revenue stream), and the other is the whole company purpose. If you would want to make a comparison like that, then it would be much more suitable to compare Unity rewriting their engine to .Net to rewriting Windows from the ground up and saying that they don’t care about old apps for the sake of “modernizing”.
5 Likes
Hi, @xoofx . [As mentioned here]( Blog post: Porting Unity to CoreCLR page-2#post-9718297), can you please tell us in what situations do you think CoreCLR will be faster then il2cpp? I guess projects that rely on reflection (Zenject for ex.)?
We’re talking about a multi-billion dollar company with ~5,000 employees. No, I don’t care that they chose to lay off the engineering and hire PR talking heads instead to be able to tell you how they can’t do what people are expecting of them. It was their decision.
4 Likes
I can share some anecdotal insight. I have procedural code that creates a galaxy with approximately a million star systems. This involves just the data—not 3D. This same code runs server-side (.NET 8) and client-side (Unity .NET Standard 2.1).
In .NET 8/Core CLR, it takes 700ms. In the Unity player, it’s around 6,000ms. It’s almost a 10x difference in performance.
The performance difference is due to across-the-board optimizations in .NET and base class libraries. In my scenario, the performance improvements for System.Random, GUID, and generic collections are significant.
I’m very excited to see CoreCLR come to Unity.
9 Likes
From the little I can perceive from outside, I don’t think the “healthy/active” teams at unity not working fast enough is the problem. Neither is their C++ code.
It was unfortunate that they decided to rely so heavily in domain reloads and a particular GC intrinsic behaviour but that doesn’t mean “C++ == bad”.
Consoles are handled by ILLCPP, and that could very well be done by a separate team without that much impact on the rest of the engine.
The problem seems to be mainly management setting stupid priorities and starving/hibernating teams to get their members focus on something else. Like, in this particular case, the decision to switch to modern .net was made 1 or 2 years too late.
Other examples:
- “new” gameobject+canvas based UI got released with 4.7 or so, improvement/maintenance almost stopped since, effort shifted to a “new new” html-ish based UI…
- TMP was acquired by unity, improvement/maintenance almost stopped since, effort shifted to a new “unity text” thingy
- after implementing URP/HDRP gameobject rendering performance improvement/maintenance almost stopped, effort shifted to a “ECS”, now 4/5 years later they finally realized ECS is great but not for everyone and some work on gameobjects has resumed
- all the physics engine changes…
- tons of systems that have seen very little improvements or don’t even exist: terrains, navigation, game AI, runtime saving/serialization, etc
Again, from super far away, it looks like unity has say, 20% of the independent teams of engineers an engine of its size and “value” should have. If every aspect of the engine were noticeably improving year after year, nobody would be so upset at having to wait for a particular feature. (Because we would be kept busy and happy by the other things that improve in the meantime.)
8 Likes
No, what Unity should do is make their current C++ codebase better. Rewriting your program is a very bad idea most of the time. Just look at how much time it has already taken to just port the scripting API from Mono to CoreCLR. How much longer would completely rewriting the rest of the C++ code take? Also, NET itself relies on C++ code to execute the C# IL. So this is not going to avoid the problem you believe they need to solve anyway.
Also, your belief that Unity will be gone in a few years if they don’t switch just makes me think of those Linux fanboys who keep predicting the imminent demise of Windows.
Also, you seem to be contradicting yourself. You said that Unity should “do low level compiler stuff, instead of letting Microsoft to do that”. How is throwing away their C++ code and switching to .NET completely not the exact opposite of this? And why are you praising the Stride engine when they are doing the exact opposite of that advice?
4 Likes
1 Like
For the scripting runtime it’s a combination of: (a) Unity emphasizes backwards compatibility, and (b) Unity wants to be able to move to newer versions in the future with minimal investment. Microsoft releases a new version every year so Unity has to be able to upgrade yearly or their entire investment will have been wasted, and they have to be able to do it without breaking everything. So as much as I hate how long it’s taking it’s completely necessary.
1 Like
I like it for hilariousness but he has valid point. Stride go on the right path that unity has gone wrong. The problem for me is just they don’t use LH coordinate and they don’t do the web. Aside from that is only because currently they just lack community and funding
Don’t forget the Input System. On the surface, sure, great UI and really cool how you can put everything into action maps. But then ask anyone who tried to do anything interesting with it through code and it’s an absolute messy string-based bloath with confusing error messages and terrible upkeep.
It seems not only are the teams going in all sorts of indescribable directions, it also doesn’t seem to deliver.
The only thing that I am really passionate about is Cinemachine, and that guy is mostly operating outside of Unity redtape, hell it’s one of the few packages that receives contributions. Somehow, poor management not only focusses efforts on the wrong things, but also those things are executed poorly. Has any actual engineer even tried, I’ll do you one better, asked for Muse?!
2 Likes
So I just read that in 2 days these forums will be closed and migrated to Unity Discussions… am I understanding that right?
Does anyone understand where and if we’ll be able to find this thread on Unity Discussions when it is available the 18th?
It’s a shame, I really enjoyed the calm and direct styling of the forums :<
2 Likes
The very first post of that thread states you’ll have a redirect for forum URLs, so just save this thread’s URL somewhere.
1 Like