|
|
20180831002506_1.jpg (134,965 bytes) 20180831002412_1.jpg (125,993 bytes) 20180831002502_1.jpg (168,929 bytes) |
|
|
Should be fixed now! * Major surgery in part of the ui code, specifically relating to "when to tell something to draw." ** Previously it was telling things to draw, once when it was time to change states, and then assuming it would actually DO that and thus it could not bother telling it again until things changed. Aka, "draw yourself until I say otherwise." ** Unity UI has a "fun" thing, however, where if an element is a child of a disabled element, then telling it to draw won't properly flip it's internal flag. Apparently. There may be some other funkiness in there, too. ** At any rate, there was quite a bit of "huh?" and "I didn't hear you" going on in the sidebar in particular, leading to things updating slowly or not at all. Things like the objectives menu getting garbled when you had more elements added, or things like space docks beyond the third not displaying unless you went to another planet and back (and sometimes not even then). ** Now we just take the approach of saying "STAY ON" every frame, or "YOU BETTER BE TURNED OFF NOW," as the case may be. Turns out that's just the sort of special tone the Unity UI requires in order for it to do its job. Yes, the snark is heavy, but this has made life intermittently frustrating for the better part of a year. ** The concern with this method had been that us telling hundreds or thousands of ui controls STAY ON or BE OFF every frame would be a performance hog. We would have to trust that the Unity UI itself had an "early out" in there saying "I'm already on, we're good" and thus not doing a whole bunch of work whenever we say STAY ON and it's already on. It seems that is the case, happily, because we still get 180+ fps in our test case with plenty going on in the UI. *** It's also worth noting that since our UI is hierarchical by nature, we wind up doing a lot fewer of the STAY ON calls than we had been thinking might happen. A lot of things early-out at the window/canvas level, and don't go any deeper than that, which makes the actual number of redundant calls per frame far lower. ** What we did NOT expect was that this would bork up various of our GUIs, most notably the main menu, tooltips, and a few other floating text windows. We had to normalize how those windows report "I should be on" or "I should be off" to match the technique of the rest of the windows. Now they do, and so it all works fine. But that did lead to some rewriting of bits of the tooltip display code, which makes how they turn on have a slightly different delay than before. Possibly faster? The sidebar reacts faster, for sure. Some of the tooltips might be slightly slower to react. We'll sort it out later, because it's pretty close to what it was before. ** The TLDR, at any rate, is that the UI actually does what we tell it now, so far as we can tell, and there aren't random missing elements on the sidebars, or elements that draw over and under other elements until you switch tabs and back. (Now the things that still draw wrong, draw wrong consistently; which is much easier to fix as well as far less prevalent!). |
- Anonymous
