View Issue Details
ID | Project | Category | Date Submitted | Last Update | |
---|---|---|---|---|---|
0016329 | Stars Beyond Reach | Suggestion | Apr 22, 2015 11:03 am | Apr 23, 2015 11:07 am | |
Reporter | ptarth | Assigned To | Chris_McElligottPark | ||
Status | closed | Resolution | won't fix | ||
Product Version | 0.800 (New HUD) | ||||
Summary | 0016329: Text updates occur before calculations are finalized | ||||
Description | I don't know much about how Unity optimizes. I know that in my own programming experiences graphical displays eat up a ton of system resources. I've noticed that as the game is running its bookkeeping at the start/end of a turn, the GUI display values change several times. I'm guessing that the display is being refreshed before the calculations are complete, which probably is using up a lot more cycles than is necessary. Cutting the display update until after all the calculations may improve performance. Then again, I still don't know how Unity works. | ||||
Tags | No tags attached. | ||||
|
This isn't really a unity thing, it's a factor of how we're handling threading. In order to not lock up the game (and then have it be completely nonresponsive and window trying to kill the program as well), all of the between-turn stuff is happening on something like 14 simultaneous separate threads. Some of those do in fact update numbers before the turn is complete, and that's unavoidable unless we want to have a "the number you see is not the actual number that has been calculated" bit of logic, which would be super complicated and add a lot to processing power. Overall you are correct that the between-turn times are being slowed down a bit by the fact that the game is rendering frames still. That's pretty much unavoidable, but the background threads are being given higher priority during that period and so the majority of the processing goes there. Unity inherently lowers the framerate when stuff like that happens, which is a really nice feature... well, it's kind of an OS-level feature, but still. Anyway, TLDR: it's being handled as efficiently as possible already unless the screen were to just be frozen during between-turn calculations. In the cases where between-turn times are too slow at the moment, it has to do with certain algorithms likely running millions or hundreds of millions of calculations where they should be optimized to run more like a few thousand or tens of thousands. We just have to always identify those cases when they come up, and optimize those as they arise. It's a whack-a-mole sort of situation. Pretty much everything else that the game does performance-cost-wise pales in comparison to those cases when they do arise. |
|
Thanks for the insight. I only get to dabble in real programing so learning more is always nice. |
|
It's always a pleasure! |
Date Modified | Username | Field | Change |
---|---|---|---|
Apr 22, 2015 11:03 am | ptarth | New Issue | |
Apr 23, 2015 11:00 am | Chris_McElligottPark | Note Added: 0040160 | |
Apr 23, 2015 11:00 am | Chris_McElligottPark | Status | new => closed |
Apr 23, 2015 11:00 am | Chris_McElligottPark | Assigned To | => Chris_McElligottPark |
Apr 23, 2015 11:00 am | Chris_McElligottPark | Resolution | open => won't fix |
Apr 23, 2015 11:04 am | ptarth | Note Added: 0040162 | |
Apr 23, 2015 11:07 am | Chris_McElligottPark | Note Added: 0040163 |