[2.9pre-1532] Sloped floor rendering glitch

[dpJudas]

What are those sparkles about? It sounds like drawing the subsector lines like I'm doing in the poly renderer won't work in some situations?

[Graf Zahl]

Those are math imprecisions. I render linedefs as one polygon, but if a line gets split into multiple segs you get two subsectors or more whose edges border this linedef, i.e. the polygons on both side are not a perfect match. And sometimes that leads to single pixels not being drawn.
The only solution for this is to add intermediate vertices at the splitting location when rendering the wall. Of course this costs a bit of processing time.

[dpJudas]

Ah, so because I render by subsector lines, while you render by linedefs, you need to compensate for that. My walls strictly speaking bends a little bit then. Makes me wonder which approach is faster, unless there's a specific reason why it has to be by linedef ofc.

[Graf Zahl]

Rendering per-linedef is faster, because the amount of draw calls is reduced, even when adding the intermediate vertices. Otherwise each seg would have to run through the entire processing code which is all CPU time. And when pushing to the GPU, doing it as one polygon is simply less work than rendering each seg separately.

A similar approach may be usable for subsectors belonging to the same sector, the main reason this isn't done is that it'd increase the overhead for dynamic lights quite a bit because everything visible in a sector, as opposed to a subsector would have to be processed. It may be faster ultimately but I never went through with that part yet. NVidia drivers are capable to internally batching this stuff so that it won't cause slowdowns, but on AMD/Intel it might bring some improvements.

[simc]

After some investigation, it appears this only affects the old x86-ASM renderer. Meaning, this problem does not occur in 64-bit builds.

When the slope rendering problems started they did occure both in 32 and 64-bit versions. But there were two different types of the error. Both 32 and 64-bit version showed some slopes just as a pixelated mess:
64-bit:

---

32-bit:

64-bit:

32-bit:

However in the same wad and the same ZDoom version the 32-bit version showed all the other slopes with the same "flooding" error what was described here earlier. 64-bit version rendered those slopes without errors.

---

32-bit zdoom-2.9pre-415-g346fae8 (March 12th 2016) had no problems with slopes.

32-bit zdoom-2.9pre-506-g1648a71 (March 30th 2016) had no problems rendering slopes - but atleast KZDoom7.wad crashes at startup.
32-bit zdoom-2.9pre-854-g1722902 (April 25th 2016) KZDoom7.wad and my own wads crash at start up. (Both have slopes)

32-bit zdoom-2.9pre-928-g841a579 (May 8th 2016) has two type of slope errors: pixeled and flooding.
64-bit zdoom-x64-2.9pre-1021-gde0301a (June 16 2016) has pixeled slopes
64-bit zdoom-x64-2.9pre-1117-g5c182c7 (July 14 2016) has pixeled slopes

32-bit zdoom-2.9pre-1148-g4345623 (July 24 2016) has only the "flooding" type of slope error described in this topic earlier. Evey sloped floor and ceiling.

[Graf Zahl]

That pixelated mess was something completely different, it just got a texture scaling factor wrong. The current glitch is an assembly drawer not doing what it should, while the C version of the same drawer is fine.

[Graf Zahl]

Since this was a problem with the assembly code, it's no longer relevant.