Fix issues in first map of the "UAC Franchise 666" user campaign, #651 #652
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…wm#651 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.
|
This should fix the issues from #651. @walikor please test |
hi, I tested with both the 32 bit and 64 version and they work correctly, without drops in fps or errors in the console. |
|
Great, thanks for testing! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.