MTW wrote:NeoThermic wrote:MTW wrote:I am just saying that I am quite pissed off about the Defcon problem.
Do you have any idea how large of a problem the Defcon problem was to solve? Do you have any idea at all? Please, humour me with an answer.
NeoThermic
I don't care. This could have been solved by porting it in house, while the windows version was still in development, thus avoiding shipping a version of Defcon for Windows that was broken.
Well, no it couldn't be solved while porting in-house. It couldn't be solved while the windows version was still in development. So not only are you being ignorant of the issue, you're refusing to correct that.
Lets backtrack to the beta, since the NDA has expired, I can tell you this (Although having been quite a while since this all happened, this is generally from memory),
First, The early betas of Defcon had major sync errors. These sync errors were all between windows versions, and a lot of time was spent correcting them. Once they were corrected, gameplay issues were solved, and things progressed nicely. The first indication any of us had that the Mac version might be an issue was one night when John asked us to join a game which desynced on the spot. The desyncing clients were always the Mac ones. The previous experience that IV had of porting was the very-fast Darwinia port, so the testing of Mac clients was done close enough to Defcon's release that had it been without issue, you would have seen same day release of Mac and Windows versions.
However, the issue was deeper than this. Defcon's net protocol was passing around floats. Floats are an.. intresting datatype in which you often come across floating-point errors. For example, 2.0f might actually be 1.9999999998 to the computer. That's a floating point error. Thing is, each compiler on each platform has slightly different floating point errors. This means that while 2.0f to a windows build might be 1.9999999998, to a Mac build it might be 1.9999999997 (for example). These errors meant that the game would slowly fall out of sync until it was enough to trigger a sync error. To this end, the solution was to write a fixed-point math lib. All math functions that Defcon used had to be rewritten to take into account this new fixed-point math lib. Floats had to be changed to fixed-point data types, functions like sin() and cos() had to be overloaded, and everything had to be tested. Considering the amount of work that went into writing this lib and testing it (not forgetting that it also had to be applied to the Windows and Linux clients), for it to take 7 months and 20 days is quite good.
So, can you really sit there and complain about this? Can you honestly say that porting in-house would have magically avoided this problem? If you answer yes to either of these questions then xander's label applies very well.
NeoThermic
