I’m far from being knowledgeable in the graphics area of games - but as far as I’m informed you can not just switch from BIRP to any of the others with just a switch so bringing existing huge projects over is a time consuming task?
Still switching to CoreCLR is the one thing I’m waiting on for years now as I’m pretty sure that it would heavily benefit our game as it’s heavily CPU bound - due to it’s nature, not (only 
) our code.
1 Like
To be fair, maybe they liked their editor loading in 1 minute instead of 10 :')
2 Likes
No. It’s only within the past year that SRP usage has hit 90%, and even then that’s only for PC and consoles. For mobile and XR devices it’s around 50%.
Here’s a screenshot from the roadmap presented at GDC 2024. If you wish to look it up yourself it starts approximately six minutes into that video.
They’re talking about games already created for BiRP not games that have yet to be released.
1 Like
No, 90% of PC/Console games published in 2023 used SRP. Mobile SRP is still much less utilized (50%), because it’s a more complex ecosystem and the benefits aren’t as clear-cut.
Mobile is the majority of published games made in Unity, and the majority of gaming revenue across-the-board, so while they may deprecate BiRP, seems unlikely they’ll drop it altogether anytime soon (if ever).
Yeah sorry you guys are right. Guess I had it a little bit wrong in memory…
What actually now interests me regarding the mobile percentage is: How many of the games released on mobile using BiRP are also built for iOS…
I have a feeling that because the Google Play Store allows any game to be published, as long as it passes through their security check, that the number is being skewed by hobbyist devs, who made one very simple game using the next possible engine they can use and published it in a simple state. There are many embarrassingly non-polished games on the Google Play Store and I think part of Unity’s bad reputation comes from this.
Also you don’t have to pay on the Google Play Store to launch a game, unlike the Apple Store, further accentuating the hobbyist aspect that I’m referring to.
Or maybe I’m wrong xd
Edit: Not saying that the Apple Store is better (god I hate that 100$ yearly fee…)
Hey all, can we continue the Unified Renderer discussion in the dedicated thread:
Soon there’ll be an official overview thread (hopefully with way more information then we know now) and we can direct discussion there.
4 Likes
Maybe 2 years ago no, but today I would definitely agree. The only reason to stay on Built-in would be compatibility with some Asset Store assets. But for a new project, I’d say URP all the time.
4 Likes
17 posts were split to a new topic: Resourcing concerns for .NET Modernisation
Mom said it’s my turn now to shit on Thaina.
Jokes aside, how about you guys just stfu? We have heard both arguments like 3 times already, you have polluted this thread more than necessary…
We get it.
14 Likes
Man, parrot people are the worst. /srs Coming in, repeating the same things that were said before without adding anything; stoking the now finally smoldering coal once again and for what? Just to throw in a ‘me too’. /hj
Both sides have been plenty talked about by now. If you’ve not got any fundamental new point to make, just don’t. /srs And don’t go around harassing people in dm’s just cuz you felt personally targeted by a post made days ago that was clearly not meant to target anyone in particular. /lu
Our frustrations have been read, we’ve moved on to our waiting state again; let’s finally resume using this thread as an actual discussion thread about the features and the general .net modernization effort once again. /srs
6 Likes
Ok, no, fuck this, this has gone way too far.
Moderator please move these guys to their own tread or something, I’ve flagged the messages for you.
12 Likes
Can everyone please cease the bickering.
If anyone wants to continue this back and forth about the internal resourcing of the .NET modernisation team, your posts will be removed.
I have split off a new topic for that discussion, which will hopefully prevent ongoing defiance of moderator direction.
This thread should ideally be reserved for technical questions or concerns about the transition, updates by staff, and messages of support (reactions are preferred).
26 Likes
Thank you for doing this. The conversation going too far off is making the community not see the good news and only see bickering. Thank you for helping with the community moderation. Now to an on-topic post.
With the new C# changes coming with the .Net upgrade is there any plans to change how GameObjects have the some of their operators overridden for certain types of null operations?
I saw some talk about nullables, but was wondering how this might change how we do null checking on GameObjects.
Also, I haven’t seen too much talk about how the API will be upgraded behind the scenes in how some of them are implemented for method overload types that are accepted. In some areas that return arrays, lists, and other collections there are places that could benefit from having a span return overload or allowing for a span to be passed in as an argument type. I know some of the transform and gizmo commands already received a nice span overload for the method arguments, but I would like to see it in more places.
The span additions would be a great update with C# 11 pattern matchings for certain span types. Such as Span.
Are there also any plans to add more async capabilities to Unity specific life cycle methods? Awake and stuff like Start already has some support for being an async method, but I would like to see more with the potential to do this.
Last thing I was wondering what your plans for Record serialization would be. Is the team planning on starting to use Records and allow them to be serialized to be shown inside of Unity’s inspector? This would eliminate the need of having custom editors to add inspector support for Records.
To give a few quick-fire answers:
- nullable doesn’t actually change your code, think of it more like “compiler hints”, so you get compiler warnings.
- record is natively a class, but in later versions you can specify you want to create a “record struct”: I assume these should be serializable by default since they’re structs? But a record ny itseld is just a fancy class, so it probably won’t be supported.
There’s people gonna (rightfully) correct me but within this context, records basically function the same as classes 
3 Likes
This has been asked multiple times before and there were even separate threads about it. I’ve spearheaded a lot in regards to this since I and many others really do want to see a better way and want to exile unity’s fake-null from our lives. However, at least for the migration they won’t change how unity-specific null works and they will likely also not annotate most things for nullability yet. This does make sense at least since proper modern null checks will not work on unity objects as long as fake-null is around.
1 Like
Thank you for bringing up the Record Structs. I forgot to ask about that inside the post.
For the nullable stuff I mean more of like the overloads Unity does behind scenes for checking if a game object is equal to null and seeing if there is any plan to incorporate that after the .Net modernization. Nullables could be nice in some areas when dealing with null stuff. I should have separated the null checking and the nullable question into two separate sections to avoid confusion.
@Mindstyler just answered more about that below your post. Wasn’t sure if they had any changed in what was coming first or not. Last time I saw anything about that was a few months ago and a lot can change in a few months so mainly asking to make sure that information is still up to date.
By the responses the information from a couple months ago still is relevant to the initial release plan.
Yeah since the posts some months ago nothing new has actually happened / was discussed about this.
Speaking of serialization, .Net Core deprecated [Serializable] attribute. That is currently required for Unity to serialize custom types for inspector use. Will that be done away with and all types will become serializable?
2 Likes
Oh no! I was worried about this. That’s gonna be a huge pain for such a small change. Both Serializable and NonSerialized attributes are a big part of dealing with Unity’s serialization. Where did you see that it’s being deprecated? The last thing I can find is that these attributes were made non-browsable, but still not deprecated here.
Oh, I guess they didn’t fully deprecate those 2 attributes. But they are pseudo-deprecated by being hidden now. Either way, Unity will need to modernize its serialization infrastructure, and I’m curious how they will go about it.
3 Likes