Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Support no domain reload #417
Ready to merge.
One of our users needs this with a priority if possible. @daleeidd if you're working today could you please give this a review? If not it's fine. Thanks!
What / why
The speedup entering/exiting playmode when domain reload is disabled in 2019.3 is incredible.
As noted in #373, crest did not support this option before now.
If the domain is not reloaded, any static variables will retain there value across the transition. There is a special callback that can be used to initialise these variables if needed. More info: https://docs.unity3d.com/2019.3/Documentation/Manual/DomainReloading.html
Some of our statics don't need to be reset across reloads. Some statics didnt need to be statics at all (for example, some shader param ids where private, and members of a class that were basically a singleton, so there was no point making them static - e.g.
The remaining statics received (re)initialisation in the callback. The callback isn't usable pre-2019.3, so i've left initialisation both in line in the variable declaration, and in the callback function.
I could have ifdef'd out the entire callback function (
(A final note, it would be good agree a coding standard for statics (perhaps here: https://github.com/crest-ocean/crest/blob/master/CONTRIBUTING.md ). I think they were originally
I ran the example scenes in both 2018.4 and 2019.3 and all seems fine here. I ran a standalone build from 2019.3 as well and it seemed to work.
None that i'm aware of, besides the pitfall of double initialisation, which i'm not sure can be easily resolved in a way that is elegant and works on versions pre-2019.3 and after.
Looks ok to me. It tested fine too. Hopefully I didn't miss something.
Couldn't collections like Dictionary be kept as readonly and just use
I think it would have been nice to keep the
As far as static prefixes go, I believe code intelligence makes it somewhat obsolete. No prefix will reduce friction for new contributors. Microsoft recommends against for public static fields
moosichu left a comment
I've not had a chance to go through everything. My personal opinion is that we should keep our dependency on callbacks for resetting state low, and should prioritise keeping things readonly over keeping them static (especially in classes we instantiate once). However, for statics which were accessed across class boundaries, a dependency system might be needed for this which is beyond the scope of this.
I responded to comments directly, thanks for those
Yeah tom made he same comment, i changed it to do it that way
Yeah its tricky and kinda contradicts the next comment below.. so ive left it as is
Yeah that was my approach as well, hopefully i've found a good balance. if anything looks like it should not be static in addition to the ones ive changed let me know
@daleeidd good catch on the static events. looking at that one revealed something pretty funky in the code - currently every ocean chunk registers the begin camera rendering event, only to set the same static reference. i.e.
thanks for thoughts on coding standards too, we can discuss on discord if that makes sense
I just realised that the static event handler wasn't necessary this time round since