Map BSP problems #147
Comments
|
yeah, dmap hasn't been tested much yet, as far as I remember.. |
|
I can compile a 32-bit build later today and try with that. |
|
so have you tried 32bit builds yet? |
|
Hello, Sorry about the lateness! Been busy with things. |
|
any update on this? |
|
I can't reproduce the problem with latest dhewm3 (from git) on XUbuntu 18.04 x86_64 (GCC 7.5 and clang 6.0). |
|
Also works with XUbuntu 20.04 (GCC 9.3 and 10.2) so I guess this issue has been fixed accidentally. |
|
Turns out I can reproduce it after all, but only if RobertBeckebans/RBDOOM-3-BFG#436 discusses the issue, which is caused by a GCC compiler bug (at least I think it's a bug). |
Only happend if `ONATIVE` was enabled (or some other flag was set that enables the FMA extension), the root cause was that the cross product didn't return 0 when it should, but a small value < 0. Caused some faces to be missing in maps compiled with dmap. RobertBeckebans/RBDOOM-3-BFG#436 (comment) has lots of explanation. I think this is a compiler bug, this commit works around it. fixes #147
|
GCC bugreport for this: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100839 |
|
is |
|
I don't know, maybe. I'll wait a bit, hoping that someone else chimes in in the GCC bugreport to clear this up. For now my workaround should work for all GCC versions including their current development version. |
according to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100839 the real compiler flag enabling this bullshit isn't -fexpensive-optimizations but -ffp-contract=fast which for some(*) reason is default in optimized builds. I think it's best to disabled that optimization globally in case it also breaks other code (I really don't want to spend several days to hunt such an idiot bug again). I really doubt it makes any measurable performance difference. As https://twitter.com/stephentyrone/status/1399424911328874499 says that clang might also enable this in the future (though to =on instead of =fast which should be a bit saner but would still break our code), just set this option for all GCC-ish compilers incl. clang. (*) the reason of course is that GCC developers don't develop GCC for their users but to win idiotic SPEC benchmarks
Only happend if `ONATIVE` was enabled (or some other flag was set that enables the FMA extension), the root cause was that the cross product didn't return 0 when it should, but a small value < 0. Caused some faces to be missing in maps compiled with dmap. RobertBeckebans/RBDOOM-3-BFG#436 (comment) has lots of explanation. I think this is a compiler bug, this commit works around it. fixes dhewm#147
according to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100839 the real compiler flag enabling this bullshit isn't -fexpensive-optimizations but -ffp-contract=fast which for some(*) reason is default in optimized builds. I think it's best to disabled that optimization globally in case it also breaks other code (I really don't want to spend several days to hunt such an idiot bug again). I really doubt it makes any measurable performance difference. As https://twitter.com/stephentyrone/status/1399424911328874499 says that clang might also enable this in the future (though to =on instead of =fast which should be a bit saner but would still break our code), just set this option for all GCC-ish compilers incl. clang. (*) the reason of course is that GCC developers don't develop GCC for their users but to win idiotic SPEC benchmarks
I've started making maps for Doom 3, using DarkRadiant. I compile them using the 'dmap' command from Doom 3.
The problem is some geometry is rendered wrongly in-game. Here's a thread I created on the idTech4 forum, that demonstrates the problem.
The interesting thing is that these glitches aren't there when the map is compiled in stock Doom 3.
Please take a look at this testmap.
The text was updated successfully, but these errors were encountered: