- Implemented multiple adjustments to some base code and lots of cleanup to hopefully help improve performance. I have a bigger list of the exact changes that I'll put at the bottom just so you know the ins and outs (even if you don't fully understand them).
- Fixed bosses being launched by certain events and becoming stuck in a launching phase.
- Fixed bosses being poisoned and stuck in a poisoned state forever.
- Fixed enemies becoming stuck from certain flag variables (isRolling and tookDamage) and becoming unkillable.
- Fixed leaderboards saving the wrong values when exiting a game.
- Fixed crash when trying to start a second game because it was looking for a certain value in the leaderboards and the leaderboards were empty.
- Fixed certain textures disappearing when minimizing the game.
- Removed the need to press a button to go from the loading screen to the splash screen, now it's automatic after loading is finished.
Performance Updates
There were 5 different areas that jumped out the most from the last trace report that could be improved to better performance. These 5 areas were the ScreenManager.GetScreensToUpdate(), LevelManager.UpdateScoreboard(), Camera.Update(), Game1.Draw(), and Numbers.Draw().
- The ScreenManager calls GetScreensToUpdate to build the list of screens that are being used, and updating/drawing those screens. This function was called every game loop as it was in the normal ScreenManager.Update function, and thus used up a ton of resources. Basically the only thing that controlled what screen was displayed was the current game state, so now game states have been changed to call that update function only when they themselves have been changed.
- In a similar fashion, LevelManager.UpdateScoreboard is called constantly from the normal LevelManager.Update function. Now when any value on the scoreboard actually changes (kills, deaths, points, waves/survival stages completed, chest secondary health) the UpdateScoreboard function will be called.
- The Camera.Update function would use a lot of resources just trying to determine where to place the camera. Since the introduction of multi threading, this was a perfect solution. The Camera.Update is now called on a seperate thread so game resources aren't being used just to place the camera.
- In Game1.Draw, a lot of text is drawn using the custom Alignment class, but not in the ideal way, specifically the website and version number since they are drawn constantly on basically every screen. Instead of creating variables to hold specific Alignment values and then drawing them using the variable, it was condensed into one action, where the Alignment class was called directly to draw the text inside the Game1.Draw. This uses more memory because it has to create a new variable every time it gets drawn. Now there are variables before hand to hold the Alignment values, and those variables are then drawn later.
- This was also the same case for the Numbers class. This class holds all the data pertaining to damage numbers being drawn and updated. This was also changed in a similar way to above, where there is now a list of Alignment variables that are created before hand, and then drawn later.
