[lastest 2.9pre] Rendering issues

[cocka]

How many slopes do you want me to provide? There are plenty of them. All of them are rendered like that.

[Edward-san]

They look fine for me.

[cocka]

And do you use the 32 bit version? Because I tested that one. And now I tested on another computer with Windows 7 32 bit edition and the problem still remained.

[Graf Zahl]

Interesting. This seems to happen only in 32 bit Release builds. It does not happen in 64 bit at all and neither in 32 bit debug builds. This is also something completely different. The math itself is ok but for some reason the actual rendering breaks down.

[_mental_]

The bug is reproduced only when assembly files are used. With NO_ASM set in CMake (or empty path to NASM executable) 32-bit Release build via VS2015 update 2 doesn't have this problem.
So the quick workaround is to disable assembly for devbuilds.

[cocka]

but for some reason the actual rendering breaks down

Yes, the problem is still there but I noticed that if you use IDBEHOLD L the problem vanishes. As soon as the environment darkens back, the slope rendering fails again.

[Edward-san]

I would like to mention an issue I saw while testing the wad in this bug report and it's about the switch. The texture appears broken, might that be caused by the slope problem, too?

[Csonicgo]

The bug is reproduced only when assembly files are used. With NO_ASM set in CMake (or empty path to NASM executable) 32-bit Release build via VS2015 update 2 doesn't have this problem.
So the quick workaround is to disable assembly for devbuilds.

Is there any speed increase noticeable with the assembly files? I've been wondering this since the ARM platform doesn't have assembly files yet, but I haven't noticed much of a difference.