mirror of
https://github.com/dhewm/dhewm3.git
synced 2025-03-20 01:31:09 +00:00
cc5f1d9fd2
somehow the collision code managed to spread NaNs on Win32, which caused
a horrible framerate, "GetPointOutsideObstacles: no valid point found"
warnings in the console and assertions in debug builds.
Didn't happen in Vanilla Doom3 though.
At the location I changed the code in, I saw the following values in the
debugger:
normal: {x=0.00610326231 y=5.58793545e-09 z=1.19209290e-07 }
trmEdge->start: {x=-1358.00000 y=913.948975 z=25.2637405 }
start: {x=-1358.00000 y=916.000000 z=34.0000000 }
end: {x=-1358.00000 y=810.000000 z=34.0000000 }
dist (normal*trmEdge->start): -8.28822231
d1: 9.53674316e-07
d2: 9.53674316e-07
f1 (d1/(d1-d2)): inf
"normal" isn't normalized and also very small (in all directions),
"start" and "end" have quite different y values, but still doing scalar
multiplications of each with "normal" gave the same result..
No idea what this all means exactly, but checking if d1 - d2 is (almost)
0 to prevent INF solved the problems. In the end it will be some tiny
differences in floating point calculations between different platforms
and compilers..
In my test d1-d2 was exactly 0, but I compare with FLT_EPSILON to be
on the safer side.
|
||
|---|---|---|
| .. | ||
| cm | ||
| d3xp | ||
| framework | ||
| game | ||
| idlib | ||
| libs/imgui | ||
| MayaImport | ||
| renderer | ||
| sound | ||
| sys | ||
| tools | ||
| TypeInfo | ||
| ui | ||
| CMakeLists.txt | ||
| config.h.in | ||
| mmakefile.src | ||