Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unity's Mono problem: C# code runs slower than it should

marekfiser.com

Post reply on HN
Print view View original

91–100 of 190 posts

Re: Unity's Mono problem: C# code runs slower than it should

#91

Post by fulafel »

DiabloD3 wrote: post #40
reactordev wrote: post #31

Unity has a unity problem. While it’s easy to get in and make something (it’s got all the bells and whistles) it also suffers from the monolith problem (too many features, old code, tech debt). The asset store is gold but their tech feels less refined. It’s leaps and bounds where it was when it started but it still has this empty feel to it without heavy script modifications. There is the problem. The scripting endin…

That last step is nonsensical: WebGPU is a shim layer that Vulkan-like layer (in the sense that WebGL is GLES-like) that allows you to use the native GPGPU-era APIs of your OS. On a "proper OS", your WebGPU is 1:1 translating all calls to Vulkan, and doing so pretty cheaply. On Windows, your browser will be doing this depending on GPU vendor: Nvidia continues to have not amazing Vulkan performance, even in cases wher…

WebGL and WebGPU must robustly defend against malicious web content making the API calls, just like other browser JavaScript APIs, which makes for some overhead and resulted in leaving out some features of the underlying APIs.

Vulkan has also evolved a lot and WebGPU doesn't want to require new Vulkan features, lacking for example bindless textures, ray tracing etc.

Re: Unity's Mono problem: C# code runs slower than it should

#92

Post by torginus »

reactordev wrote: post #31

Unity has a unity problem. While it’s easy to get in and make something (it’s got all the bells and whistles) it also suffers from the monolith problem (too many features, old code, tech debt). The asset store is gold but their tech feels less refined. It’s leaps and bounds where it was when it started but it still has this empty feel to it without heavy script modifications. There is the problem. The scripting endin…

Unity somehow manages to break the API of their own features so bad every year or so that their own tutorials don't work. You have a solid baseline API that has existed since forever (with known limitations), with stuff like the legacy render pipeline. Every attempt to reform it has only introduced confusion, complexity, and is at some point between experimental and no longer supported.

I don't agree with you on the Asset Store, for the same reasons - the rate of breakage means that things that are not constantly updated no longer work - and multple versions need to be maintained for parallel engine versions. That combined with the dubious economics of Asset Store (I don't think it makes financial sense to even make these things, let alone maintain them), they mostly end up as abandonware.

And on the Asset Store if you make something indispensable (which is more often than not something the engine should'have OOTB, like competent text rendering), one of the following things will happen:

- Unity will buy you out, and plop your asset in the engine, without doing any integration work, and will stick out like a sore thumb (TextMeshPro). Good for you, bad for consumers, and sucks if you were making a competitor

- They build an in-house solution, that you obviously can't compete with, and will have a huge leg up on you because they have engine access (sucks to be you)

- The engine will never have that feature, because 'you can just buy it', meaning you have to either spends hundreds of dollars/euros on dubious quality assets or hunt for open-source versions with generally even more varying usability. UE4/5 has a lot of these built in, and AAA quality.

Re: Unity's Mono problem: C# code runs slower than it should

#93

Post by Kwpolska »

chris_wot wrote: post #38
999900000999 wrote: post #34

Earlier quoted context omitted.

I don't like C++. It's very difficult to me, I generally stick to high level stuff , C#, JavaScript, Python, Dart, etc.

If you can code in C#, how is C++ difficult? Are pointers and the stl that difficult? Not denigrating, genuine question.

You're asking if going from a high level language to a low level language on steroids is difficult?

Pointers, manual memory management, and the design by committee standard library are not fun.

Re: Unity's Mono problem: C# code runs slower than it should

#95

Post by eole666 »

ramon156 wrote: post #29
999900000999 wrote: post #16

Earlier quoted context omitted.

We'll see when it actually ships. I've seen this issue before, they're making progress but theirs no firm release date. Plus you then have to extensive testing to see what works in Web builds and what doesn't. I REALLY enjoy vibe coding in Godot, but it's still behind Unity in a lot of ways.

Naive question but why not use GDscript? I haven't had any issues with it

I'll add that C# have better performances than gdscript. It doesn't make a difference for most of the things you code in a game, but it comes in handy when needed.

Re: Unity's Mono problem: C# code runs slower than it should

#96

Post by Rohansi »

reactordev wrote: post #31

Unity has a unity problem. While it’s easy to get in and make something (it’s got all the bells and whistles) it also suffers from the monolith problem (too many features, old code, tech debt). The asset store is gold but their tech feels less refined. It’s leaps and bounds where it was when it started but it still has this empty feel to it without heavy script modifications. There is the problem. The scripting endin…

> with a 1999 style property window on the side like Visual Studio was ever cool.

I don't think this is fair. I'd say Unity's inspector window is one of the good parts of Unity because it not just a property window. It's an immediate mode UI that things can hook into to do a lot more than just property editing.

Re: Unity's Mono problem: C# code runs slower than it should

#97

Post by BatteryMountain »

littlecranky67 wrote: post #87
BatteryMountain wrote: post #80

My dream would be that I can adb into my phone, install the .Net SDK or .Net Runtime (v 8 or 10) and have my applications run natively on Android. Simple console apps first, then the rest. Google should open their platform up a little bit more. Allow us to enable root access via adb. Let us unleash our pocket computer's full potentials. Would love to have portable low powered servers, running stacks of my choice. The…

> My dream would be that I can adb into my phone, install the .Net SDK or .Net Runtime (v 8 or 10) and have my applications run natively on Android My understanding is that you can (almost) do that using MAUI (formerly known as Xamarin). You will not get a .Net SDK or Runtime, but the mono runtime. Since it is bundled in your app, you won't actually notice.

No, we need one level lower & zero mono. I want the sdk or runtime to be installed in the same way (and executable) the same way on android as on other linux distro's. .Net has ARM builds so it will work fine. This is without any specific framework dependencies (like aspnet, maui, avalonia etc) - just plain .net 8/10. It would actually be nice if android just bundled the runtime to begin with so we don't have to. They can just pin it to latest LTS versions and let it auto update now & then, same way as WebView/Google play services etc.

Re: Unity's Mono problem: C# code runs slower than it should

#98

Post by skrebbel »

Does anyone on here know why it is that Unity doesn't just run on .NET? The cross-platform benefits of Mono have disappeared a decade ago or something like that.

Like, why would Unity invest in hacks like il2cpp rather than just port over to modern .NET? Is there some licensing thing going on?

Re: Unity's Mono problem: C# code runs slower than it should

#99

Post by littlecranky67 »

BatteryMountain wrote: post #97
littlecranky67 wrote: post #87

Earlier quoted context omitted.

> My dream would be that I can adb into my phone, install the .Net SDK or .Net Runtime (v 8 or 10) and have my applications run natively on Android My understanding is that you can (almost) do that using MAUI (formerly known as Xamarin). You will not get a .Net SDK or Runtime, but the mono runtime. Since it is bundled in your app, you won't actually notice.

No, we need one level lower & zero mono. I want the sdk or runtime to be installed in the same way (and executable) the same way on android as on other linux distro's. .Net has ARM builds so it will work fine. This is without any specific framework dependencies (like aspnet, maui, avalonia etc) - just plain .net 8/10. It would actually be nice if android just bundled the runtime to begin with so we don't have to. The…

So for whatever reason you want the .NET runtime over Mono - not sure why that is a hard requirement, but AFAIK that is also the goal for microsoft. As in, merging those runtimes and have a single codebase that works for all platforms (including android). There are technical obstacles and historic codebases, but I would expect this unified runtime soon.

Re: Unity's Mono problem: C# code runs slower than it should

#100

Post by pjmlp »

torginus wrote: post #88
luaKmua wrote: post #46

In general when game development comes up here I tend not to engage as professional gamedev is so different than what other people tend to deal with that it's hard to even get on the same page, but seeing as how this one is very directly dealing with my expertise I'll chime in. There are few things off with the this post that essentially sound as someone more green when it comes to Unity development (no problem, we a…

I think you've unfortunately got suckered in by Unity marketing wholesale, and things would stand to be cleared up a bit. Unity's whole shtick is that they make something horrible, then improve upon it marginally. The ground reality is that these performance enhancement schemes still fall very much short of just doing the basic sensible thing - using CoreCLR for most code, and writing C++ for the truly perf critical…

The biggest issue is that Unity is at the same time, the farol beacon for doing game develpment in C#, that Microsoft refuses to support, see how much effort Apple puts on game kits for Swift, versus DirectX team.

Efforts like Managed DirectX and XNA were driven by highly motivated individuals, and were quickly killed as soon as those individuals changed role.

One could blame them for leaving the project, or see that without them managemenent did not care enough to keep them going.

While at the same time, since Unity relies on such alternative approaches, it also creates a false perception on how good .NET and C# are in reality, for those devs that never learned C# outside Unity.

In a similar way it is like those devs that have learnt Java in Android, and get sold on the Kotlin vs Java marketing from Google, by taking Android Java as their perception of what it is all about.

Going back to game development and .NET, at least Capcom has the resources to have their own fork of modern .NET, e.g. Devil May Cry for the Playstation was done with it.

"RE:2023 C# 8.0 / .NET Support for Game Code, and the Future"

https://www.youtube.com/watch?v=tDUY90yIC7U

Post reply on HN