idVec3 exposes its internal data through its ToFloatPtr() method. That gets passed to openGL a lot, so clearly the code wasn't designed with portability in mind. It's pretty much locked down to the original compiler architecture.
The game is locked down to single precision in the sense that it's locked down to 32-bits. With enough time and effort baked in floating point assumptions can be overcome. With a general conversion of floating point types to double, there will be a need to have it converting from double to float when the game engine passes data to the renderer.
The map size issue isn't a problem for TDM, where our biggest map extends less than 10k units from the origin.
Hmm... When I get time, I'll have to try the test map at an X,Y of 10k,10k and see if it glitches on me when the fixes I've done are disabled.
@NagaHuntress: Why is the fix you already implemented is not enough? It seems to be working fine (I am still testing large 120k x 120k terrain, but so far so good)
I suspect the fix is good enough for your needs, but it nags in my mind that this is not the correct solution and it merely patches over the symptoms of a real problem.
At the moment I can't say with confidence if the fixes I've made fixes a rare edge case exacerbated by large coordinates. Does the first fix, correct a bug or an edge case in the edge-edge collision detector? or is it just fixing up a false positives that end up pointing the wrong way? Have the changes simply changed a bug that manifests 1 in 100 times, to 1 in 100_000 times? If I can prove and rationalise it's behaviour in the domain of interest, I would be more confident in the fix, but I can't yet, so I'm worryworting over the issue.
That's the same article that I discussed with grayman and greebo when we were first discussing the bugs in our MSVC2013 port back in January. Except that the article's had more info added since then. It didn't have any mention of _controlfp_s or FLT_EVAL_METHOD at the time. I suspect those could fix our 2013 compile without needing us to rewrite any code. I don't know whether those switches can help us with our 64-bit build in MSVC -- the chart in the article suggests not -- so we might still have to bite the bullet and track down the sensitive lines of code. That'd be something I can at least help with... I don't know enough about compilers and OS environments to try to tackle it from the other end.
From looking at the compiler options for MSVS, it seems there isn't anything for disabling SSE or forcing the FPU when compiling to 64 bit. _controlfp() won't help much for a 64 bit build, as we can't get 80-bit floats due to the compiler not allowing x87 instructions. FLT_EVAL_METHOD (if it's supported) will only tell us it's compile time policy, which will probably be 0 (no promotion of intermediate types). It does look like making a 64 bit build under MSVC will require upgrading floating type and maths, either in controlled location or overall.