How would you improve Classic Unity?

Compared to game code? Extremely. It's part of why it's actually a very good idea to keep them around for backend code for live service stuff.

 

I'm gonna press X on that one.

 

Think what makes corporate code more long-term maintainable is a mandatory unit-test coverage (not integration tests!) of 80, often 90%.
Due to the nature of games, that tends to be harder to achieve meaningfully in this field.

 

Agreed, but I decided to recreate the shape tests in the video in Unity on a list of 800,000 shapes, compiled to il2cpp. Because why not!
I have not tried jobs.
While the optimisations work, only dumping the class approach really makes the big difference. Loop unrolling had a varied but minor effect and table lookup also!
Typical timings (i7 CPU):


In a mono build the table lookup wasn't worth it BTW and nor were any of the optimisations really!!



Summary - don't be too desperate to optimise!

 

Very interesting! Thank you for trying those out.
I suspected results like that. C# just works way more with indirections, references, method-lookup tables (which are the "culprit" of virtual methods in cpp) and so on under the hood. That's inherent of most "managed languages" and as far as I know ill2cpp does not remove these either.
Still such tasks are its strong point I guess. In most actuall games you can be happy with a 10% fps increase when you switch to ill2cpp.

C# just gives you less performance improvement opportunity on this level - hence why Unity didn't try to build a better C# "compiler" (ill2cpp mainly exists due to Apples requirement to not use interpreted languages on iphones) but took a subset of the language and built Burst on it.

The upside of this is that you can use the features of the language without extreme worry about performance...

On actual optimizations, there's this neat video:

He mentions clean code too but doesn't blame it for everything.

@andyz Would you like to share the project?
I'd gladly add a burst variant.

 

It could also be that Mono is a really bad runtime. I think we need tests with .NET Core

 

We don't need tests to know that.

 

Would certainly be interesting.
Yes it is supposedly faster, but more than the jump to il2cpp?
The devs of Mono haven't been just dumb and MS got magicians to work on Net Core instead

 

To be fair code that IL2CPP generates is not optimal to say the least.
There are also some benchmarks on github: https://github.com/nxrighthere/BurstBenchmarks
Though not sure how trustworthy are they. But basically yes Mono definitely does lack in terms of JIT optimizations.
Edit: For instance .NET Core can actually understand that Vector3 and float3 are the same type and remove all calls to implicit convertors, while from what I gather mono doesn't even replace `% 2` with `& 1`

I'm mostly interested in particular switch vs virtual test case here

 

Great video explaining optimization strategies, I particularly like the Star Map example!

Watching this, it occurred to me that 90% or more of what he's talking about is DOD design without using DOTS/ECS at all. I can actually understand his example and adding Jobs/Burst way better than trying to wrap my head around the DOTS system.

Which makes me wonder, do we really need to learn DOTS to get better performance or is it simply a matter of coding better with memory access in mind? I think the latter is doable, but learning the DOTS way with subscenes and all that feels impossible to me.

 

While they have done a lot with some auto converting of gameobject to entity stuff so you can litterally make a subscene, fill it with things it will convert to entity, including some mobs maybe, and then, have your player as a game object and it still seems to interact I think there is a way to slowly grow into it rather than chunk yourself off the 100 story building hoping you got the hang of this on the way down

Jobs/burst also allow us to stretch off that need to leap deadline by letting us use more ways to eek out a bit more before again needing to leap off that building to dive right in

 

DOTS is a framework. Yes you can do separate systems that are data oriented on your own and it is definitely not always a bad idea to do so, but let's say after the third time you effectively create a replacement for Unity's Update method in the same project, you may want look into DOTS.
Latest when you work in a team, you'll want some common ground in the project.

 

Yes the other video would be interesting to do tests from.
I did the test with doubles because float inaccuracies appear on the switch test.
When I change to float it makes not much difference for il2cpp, but something really odd happens with mono - everything is much slower but the classes less so, something odd there... I think there are known issues with float speed vs doubles...??

 

Don't mix up your needs and preferences with other people's needs and preferences. Answer is, you do whatever is best for you and to the second is yes, we actually do.

 

You can't quite do full Data Oriented Design with C#, you would eventually hit performance walls on top of adopting a bunch of unintuitive patterns and losing a lot of C# ease of use.

Whether DOTS is a good solution to that problem is another matter, but it is a solution.

 

You mean like this? https://github.com/LurkingNinja/com.lurking-ninja.player-loop
It is officially supported by Unity (I just made a nice wrap around it).

 

Yeah I feel like most of us by now have our own 'global' callback loops using the PlayerLoop API.

 

You can apply data-oriented principles to MonoBehaviours but they're still managed which comes with significant overhead, and the systems built to support them exist in C++ so you have all of the overhead of marshalling data on top of that.

 

Being able to have the editor automatically switch themes depending on my system theme would be nice. There are ways to do it with scripts but that's project dependent when I'd really just like a checkbox in the settings or have it as part of the dropdown.

 

balebergalabida... i'm definitely not going to learn DOTS for my next project xD... i have enough with c#

 

I mean you do you, we won't tell you how to limit your options and how don't. Your loss.

 

To be honest, learning new subscene workflow, is only small part of learning DOTS. While you may need to learn and follow it's work flow, the biggest time you spent, is learning and implementing jobs, burst and ECS. Obviously you can can skip ECS part, if you want to.

 

i'm not a coder, i guess i will have to work very hard on performance xD... my loss? yeah i guess so, but i'm not learning DOTS
Edit: my other option is Unreal, which is again, wasting time learning another workflow -.- but at least not that much as learning DOTS

 

Hmm, that is only a small nudge towards data oriented design if you ask me.
The data of the objects you are executing the custom Update methods on is still scattered all around. DoD is once you have control over the objects too, not only the methods. E.g. by managing the array/list of instances yourself.
And ideally as structs and not as classes as that reduces cache misses further and finally makes it easier in a next step to jobify the whole task when absolute maximum performance is required.

Such a struct management system is what I meant what you may end up having multiple times in the game and then should consider DOTS.

Uhm, if you already have a couple years experience with Unity, it will certainly be harder to switch since obviously there's way more than the ECS framework to an engine.
P.s. are you just looking for performance? In that case in Unreal you also need to learn it's ECS which is named "Mass".
Finally Blueprints are also "coding" aka programming, just in a different envelope.

As a "non coder" don't worry much about ECS and similar. There are plenty of games that can work without them. Hence why it's not a replacement for anything.

 

That's not its intended purpose either. It's to work around the frequent boundary-crossing between managed and unmanaged parts of the engine. Like the ordinary Update does every single time.

But you can also set it up centralized (it's not in my simple example) too, that can be a nudge in the DOD direction. You can eat this cake and keep it too. Obviously you will pay in performance, but you can push that threshold considerably out without full refactor to ECS.

Great. And? You had an opinion on a coder-thing. Don't worry I also have opinion on things I have zero idea about too. We're only humans.

 

thanks for your info.
About performance, nanite is very attractive xD... i always pay attention to that (performance), for me, it is the most important thing on a videogame IMO...

 

It would be great if Pasting into the scene had contextual parent levels based on the object you currently have selected.

Imagine the following scenarios:
You press control + Shift + N to create an empty game object. BOOM instantly created, zero'd out, and childed to the current object you have selected.

Have a few assets you want to be childed under another object? Just shift select them all together, hit control x and cut. Select the object you want them childed under, control + V. Boom there they are.

This is probably a very old and common suggestion, but it's one of those little things that hit me today and I couldn't help but think, why the heck isn't this very basic functionality in the engine?

 

The default shortcut for "Paste As Child" is Ctrl+Shift+V. The workflow you described should work with Ctrl+Shift+V instead of Ctrl+V. If it doesn't, it might be a bug or an edge case that you encountered. In that case, please submit a bug report.

 

I'll be darned, well maybe they could invert the hotkeys so this is the default action and plopping it unchilded way at the bottom of the scene hierarchy required the shift?

It's one of those things that people somewhat new to the engine might enjoy a little more in the current setup, but once you're a little more well versed with the engine 99% of the time you're wanting to put things in specific places in the hierarchy.