Some progress that doesn't fit nicely on any milestone:
- I fixed the transparency issue with barbarian camps, which may be of interest to
@Flintlock . The issue was that we were only treating the last PCX index as transparent, when it should be the last two. This was just the first PCX to use that second-to-last index.
- I made the barbarian warriors not-selectable. This code is horrible because we don't have enough concepts of players yet to make it proper. But after I'd clicked on them and realize it was selected, I wanted to fix it.
And the main area I'm investigating now is performance. After
@Puppeteer added the victorious warrior, I noticed that the UI paused for a bit when I brought up the disband popup, specifically the warrior paused. So, I have:
- Creating a PcxPerformancePolishing branch
- Added a Stopwatch object for Game.cs and DisbandConfirmation.cs, which starts in the _EnterTree() method (called when a Godot object first enters the tree), and stops at the end of the _Ready() method. This lets us see how long it takes to load something, and I'm about 82% sure that it is being started and stopped in approximately the right place (although in the case of Game.cs, it would be even better if we could start it when you pressed the main menu button).
- Starting adding some caching for PCX and ImageTexture loading in Util.cs, suspecting that may be a good part of the load time. So far, this is the all-arguments version of LoadTextureFromPCX, and the LoadPCX method.
So far, the game scene doesn't load any quicker, but the DisbandConfirmation has gone from 225 ms, to 205 ms with only PCX caching, to 145 ms with texture caching. Which is still really slow for loading a popup, but if you told me upfront that 35 minutes could save me 35% or more on
car insurance load time, I'd be pretty happy.
There's still a lot of room to explore that way too, notably a lot of PCXs and textures are not going through the caching load method and are loading from disk and/or recreating the texture every time.
Performance specs are with Civ3 loaded from a 7200 RPM, 2 TB hard drive, with a 3.6 GHz Core i5 2500k processor. I found it interesting that, based on the data so far, spinning rust is not the main limiting factor despite having egregious amounts of disk loads. Most likely the loads are close enough together that either the HDD cache is caching the data, or we're loading things very close to each other on the disk so it's close to sequential load times, or both.
(I also have not yet dealt with cache invalidation with this new cache, as that is a hard problem. But more relevantly, we probably don't need to invalidate it until the player goes back to the main menu, or we figure out a way to consume way more memory)