search

dhewm / dhewm3

dhewm 3 main repository
https://dhewm3.org/
GNU General Public License v3.0
1.74k stars 341 forks source link

Map BSP problems #147

Closed ghost closed 3 years ago

ghost commented 8 years ago

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.

DanielGibson commented 8 years ago

yeah, dmap hasn't been tested much yet, as far as I remember.. I wonder if this also happens in 32bit builds of dhewm3 (might be a 64bit issue)?

ghost commented 8 years ago

I can compile a 32-bit build later today and try with that.

DanielGibson commented 7 years ago

so have you tried 32bit builds yet?

ghost commented 7 years ago

Hello,

Sorry about the lateness! Been busy with things. Unfortunately no, I haven't had the chance to try yet. I've got a laptop running 32-bit Linux which I meant to test it with, but it's at my parent's place which I haven't managed to visit yet in the meantime.

DanielGibson commented 5 years ago

any update on this?

DanielGibson commented 3 years ago

I can't reproduce the problem with latest dhewm3 (from git) on XUbuntu 18.04 x86_64 (GCC 7.5 and clang 6.0).

DanielGibson commented 3 years ago

Also works with XUbuntu 20.04 (GCC 9.3 and 10.2) so I guess this issue has been fixed accidentally.

DanielGibson commented 3 years ago

Turns out I can reproduce it after all, but only if ONATIVE is enabled in CMake - this would've been relevant information.

https://github.com/RobertBeckebans/RBDOOM-3-BFG/issues/436 discusses the issue, which is caused by a GCC compiler bug (at least I think it's a bug).

DanielGibson commented 3 years ago

GCC bugreport for this: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100839

BielBdeLuna commented 3 years ago

is -ffp-contract=off the solution?

DanielGibson commented 3 years ago

I don't know, maybe. TBH all this doesn't make sense to me and I hope that the guy who answered there was mistaken and GCC doesn't really believe that breaking the language standard in normal optimization modes is acceptable.

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.