Dev Diary - January 2009

[GShock]

** This thread discusses the Content article: Dev Diary - January 2009 **

I do remind the first Pentium CPU. With calc i had a result, with the Pentium i had another. There was an article that described exactly how to recreate it and i was like "what the hell..."
lol

[norb]

Yeah that's how I felt. I had no idea it was not to be counted on. I feel a little foolish because it's pretty common knowledge, but that's one more lesson learned.

[norb]

I finally got all of the code converted. Of course it is super buggy as it was a lot of code. Now the testers are working out the kinks and just trying to get us back to where we were before this all started. I think that I put out a good build last night, we'll see.

[ironsight]

Norb, i just read that dev diary link posted here. Yeah, if you're dealing strictly with whole numbers, integer calculations are the way to go. However, keep in mind with most programming languages at least the one's i've programmed in, dealing with integer instrucions with complex calculations (4/5 /= 1) will still result in rounding off to the nearest whole number. But since integer calcs will not include precision decimal places, odds are at least resultants will be equalized among various arithmetic rounding-off algorithms.
Don't know what kind of precision your vector calculations require, but its remotely possible due to subtle differences among processor's they could still vary every once in a great great while.

Have you tried FP instructions with fixed decimal places if you need more precision? Such as rounding off to XX.XXXX?... Then format the resultant to XX.X
That most likely would equalize resultants among various processors with a little more precision if needed.

[norb]

Thanks Ironsight. I did look into rounding off, but I just can't take chances on this, it has to be as exact as possible. So now I'm using a fixed point 64bit int. I tried other combos, but they just didn't work. Our map can get too large. I'm pretty happy with the results so far. We shall see.

[cenla]

another way to mitigate floating point precision issues is to make sure you always compute variables on the same order of magnitude starting with the smallest (i.e. closest to zero) first and then working your way up.

Also take a look at http://en.wikipedia.org/wiki/Horner_scheme which is another technique for mitigating FP precision issues.

Another approach which you basicallly have taken to the extreme by using fixed point math is to make sure that you use floating point intervals that are exactly representable in binary format such as 32 or 64-bit FP IEEE. For example using 32-bit ieee 0.08 is really 0.0799999982 whereas 0.0625 is exactly 0.0625. If you add each of these numbers 1000 times, then the result would be 80.0010681152 and 62.5000000000

[norb]

cenla, you obviously know way more about this stuff than I do. Having to do it all myself, does not allow me too much time to delve into any one part too deeply. When faced with something like this, I search the net for the best solution and then try it. I think this solution is going to work. Though I had atof errors last night, gotta test again tonight.

But thanks for the link and I will look into it later tonight, appreciate it.

[norb]

Good news! Last night we had the first completely synced MP battle with JC. Matt and JC played the battle to completion and sent the logs. They were perfectly in sync the entire time. I know it's just one game, but this has never been done before. So it's proof that the approach works. I'm sure there are more kinks to work out, but at least I know all that work didn't go to waste.

[Chamberlain]

Alright Norb !!!

Thanks for the update which is Great News !!!!

We are getting closer & closer boys !!!!

:woohoo: :silly: :woohoo: :silly:

Chamberlain