#I think unity devs need to just stop
old crane
understandable
astral karma
so this doesn't totally work because for example people need console SDK updates to continue to publish their games on teh same platforms, so they can't actually stay on the same version
same with apple making breaking changes to its os's all the time
old crane
Yeah those are some valid points, personally I still feel it's worth making scheduled API changes, otherwise there will be a lot of bloat and eventual depreciated code if nothing gets removed (eventually)
astral karma
for packages we have a bit of an out with major version changes, where we're allowed to remove stuff and break and so on. but this is a bit easier because packages rarely interact with native platforms needing SDK updates
old crane
Plus packages are inherently internal, so a lot of the changes you have control over compared to public API changes
tardy jungle
i have a question.
i've always wondered why it's not a dev practice to make all the changes, refactoring, different arguments, whatever and have those publicly exposed so any new project always uses the best / newest way, and have a legacy wrapper distributed seperately for projects-to-upgrade that 'translates' or 'glues' old signatures to the new ones where possible, and have a big [Obsolete("", true) on any signature that is un-translateble
old crane
Once unity is fully (?) .NET compliant, I imagine there will be some API changes that need to happen.
old crane
i have a question.
i've always wondered why it's not a dev practice to make all ...
They do actually, for example some of the old euler methods for quaternions
astral karma
yeah that's the idea of the scriptupdater. it has limitations, though; not everything is possible to specify in the framework that it provides. it also doesn't have a ton of work happening on it, because arguably it's not the biggest problem unity has right now
tardy jungle
ok, well there are few times where something like that is available. but even then these are still integrated into the project.
why not just have a true wrapper distributed on github or smth
old crane
what would be "the biggest" issue unity is having atm?
tardy jungle
prob not being .net 6 compatible
astral karma
lol depends on who you ask. i work on dots because i believe that scaling is the most important 🙂
old crane
Ok so what would be the biggest for DOTS right now? (aside from 1.0 being released, with some minor bugs that will eventually get worked out)
tardy jungle
work on dots is really appreciated btw. really awesome
sudden moon
to be fair dots is pre release at best
tardy jungle
duh
old crane
well, yes but the work and scalability put into dots is insane
astral karma
it's a good question. i think it might depend somewhat how the 1.0 release shakes out. we have a bunch of ideas for future work; the projects on environment/terrain, animation, and ongoing graphics speed stuff seem all like big deals. we also have some continuing experiments ongoing with a dots-only runtime
tardy jungle
nice
old crane
That's the nice thing about DOTS finally being 1.0 is devs can finally work on polish rather than explicitly internal functionality
frank pond
so this doesn't totally work because for example people need console SDK updates...
that's mainly the reason why people should be used to this by now but apparently they are not. 🤷 anyway, i have no idea what you need to deal with. the forum and discord are mostly friendly. seems outside of this bubble it's hell zone
tardy jungle
apparently so
astral karma
well the nice thing with unity is that you are pretty well insulated from the various platforms breaking. so you really can have a much nicer life if we don't break people
tardy jungle
:/
old crane
that's mainly the reason why people should be used to this by now but apparently...
Make API changes and disable notifications for a week (or month)
tardy jungle
+1
old crane
we're not going to drop unity because of some API changes lmao (or at least I wont)
tardy jungle
i think some people would cry, but not drop unity
old crane
In the end it will be likely "Oh wow, this is better!" or something after the API changes
astral karma
so there was a period ca. 2019 where we really didn't give a crap about stuff breaking, and the proverbial poop really hit the fan with users
old crane
so there was a period ca. 2019 where we really didn't give a crap about stuff br...
wasnt that when the transition to .NET started?
tardy jungle
i was around at that time and 1 - i was fine with it and 2 - i didn't witness anything like that?
astral karma
i'm not sure what you mean about the transition to .net
old crane
I mean the whole unity integrating more of .NET 6 etc
astral karma
ah, we are not there yet at all. people are actively working on it though for future years
tardy jungle
oh btw, why are most classes / types of unity not sealed?
astral karma
but the adding the option to compile against .NET Standard was the first step in that direction
no idea really. maybe nobody thought of it? or maybe we don't have as much breakage from people inheriting? i bet it doesn't work that well to inherit from most builtin unity components (e.g. MeshRenderer) because of all the c++ interface goop
tardy jungle
yeah exactly. but you're wasting huuuge performance because of it
nick has just recently made a video about it. https://www.youtube.com/watch?v=d76WWAD99Yo
astral karma
eh? what performance would be gained by sealing?
astral karma
haven't gotten there yet but my bet is that it's because .net 6 is good at devirtualization
which doesn't matter for unity yet
tardy jungle
no it's not about .net 6 really. maybe .net 6 is even better at it, but it's not exclusive to it
frank pond
don't make him watch a video but give a tl;dw
tardy jungle
i chose not to because it's better described and visualized in the video than i could. especially in chat. and the video is measly 10 mins.
astral karma
it's not a bad video, but i still think it could well be specific to coreclr
i bet the perf difference would not be so dramatic on mono
tardy jungle
well, ok, haven't tested it myself on mono. but even if not, with the .net migration at hand i think it's worth looking into
astral karma
i mean, it'd be a breaking change for sure. and with core unity classes you're basically never allowed breaking changes period
also, coreclr is hardly at hand 🙂
tardy jungle
you mean the classes you can't inherit anyway?
astral karma
i mean, nobody internally has checked which ones work and which don't. but in general, making something sealed that wasn't sealed before is totally breaking.
tardy jungle
technically yes.
imho still worth it since everyone would benefit from it, it's almost no effort, and pretty easily verifyable if things still work or not
old crane
*technically* yes.
imho still worth it since everyone would benefit from it, it'...
I wouldn't say it doesn't take any effort
astral karma
i agree the effort wouldn't be the obstacle. and maybe someday when we're on coreclr, and somebody has a project that goes way faster if you seal all these types, we could do some experiments about how to do that without ruining millions of projects
the trick i would try if it were me doing it is, i would have a button that says "please go through and add sealed at the IL level to core unity classes", and it would run an ILPostprocessor on the builtin unity dll's to do that. because if you have to hit a button to make it happen, then it's not a breaking change anymore
tardy jungle
on the forums there were threads about unity thinking about allowing contributions at some point. i really wish they would. just small ones even
old crane
the trick i would try if it were me doing it is, i would have a button that says...
I know Cecil, so I could potentially test that
astral karma
well my claim is that it won't matter until we're on coreclr anyway. but i suppose you could disprove it by running that guy's benchmark on mono
old crane
yeah just a test to see if it even matters on mono
tardy jungle
i may try and see what results i get.
old crane
I wont be surprised if it does in some very specific portions of the engine
tardy jungle
still have to do other work first tho XD
e.g. figuring out how to hook into TextureImporterInspector
pain
regal ivy
yeah that's the idea of the scriptupdater. it has limitations, though; not every...
I think as long as most of the new breaking API u can auto upgrade it then shouldn't be a issue anymore
🥲 Btw upgrade production project from dots 0.51 to 1.0 is so hard due to dun have auto API upgrader. It just only able to upgrades some basic API
tardy jungle
🥲 Btw upgrade production project from dots 0.51 to 1.0 is so hard due to dun ha...
most changes in dots 1.0 require fundamentally differently flow. 'auto update script' not possible.
also, there is simply no need at all for an auto updater from 0.51 to 1.0.
because it was and still is an experimental package