This week has been one of fixing bugs and generally stabilising the system so as to put me in a good position for the next phase of development.
The above graph shows raised issues (red) vs fixed issues (green). Over the last few weeks a lot of testing has taken place resulting in many red issues being raised. The volume of these issues was such, that I was finding them faster than I was fixing them!
However, over the last week or so, the tables have turned, with my fix rate exceeding the detection rate. I’m now in a happy position where there are only 2 minor issues left and both of these are enhancements rather than genuine issues. This means that I am now in a good solid position for the next phase of development!
Although many things got fixed over the last week, I’ll just go over the two main issues that were addressed:
Chronos replays were too slow!
This was an interesting bug and one that can be seen in the Chronos video.
The original replay functionality would wait for the time of one frame or larger to pass and then display the next frame. This is all well and good, but if the machine is doing other stuff, the next frame request could be several frames in the future. However, because of the way the system was coded, it would still retrieve the next frame in sequence – thus resulting in a slow playback.
To fix this, I simply changed the system to always retrieve the frame for the currently calculated time, regardless of how far in the future. This ensures, that even under heavy system load, the correct frame is always displayed for the elapsed time!
Irregular formation graphical bugs!
This issue has been a thorn in my side for a while. It was intermittent in nature, thus making it very difficult to track down. An obvious case of this bug can be seen in the Chronos video, where one can see the malformed irregular units.
Whilst fixing the code for this, I discovered that many mathematical ‘bodges’ had been put into the irregular unit calculation code. I decided to remove these, as I was fairly certain that it was these ‘bodges’ that were causing the graphical anomalies.
Once removed, I spent a bit of time trying to figure out why they were added in the first place. The result was rather surprising…
It seems that Ancient Armies was calculating unit widths incorrectly!!!! 😯
Before I go into the how and why, here is a question for you:
If I have a row of 5 men, each with 1 metre of frontage, how wide would the formation be?
Got the answer yet?
If you guessed 5 mtrs, you guessed wrong! 😛
The correct answer is that the resultant formation should be 4 metres wide.
However, Ancient Armies was originally and incorrectly calculating 5 metres of width. This meant that the code for generating the irregular unit shapes had many bodges in it to try and mitigate the incorrectly calculated widths.
Once I knew that this was the core issue, it was relatively simple to fix and meant that the code for calculating the irregular unit shapes could now work with no bodges in it! 😎
For those that are still unconvinced, lets consider our hypothetical man:
As you can see he has a frontage of 1 metre centred around himself.
Now if I pop him into a 5 man formation, this is what I get:
As you can see from the above diagram, the correct unit width is 4 metres!
This is because Ancient Armies unit markers represent where the men actually are, it does not represent their raw frontages. Frontages are only used to calculate the spacing between each individual man. For the men on the ends, this spacing is irrelevant – hence the 4 metres width! 🙂
That’s it for this week. Next week should be more interesting as I can now start work on formation changes…