[2.9pre-1532] Sloped floor rendering glitch

[BFeely]

Sloped floors (and ceilings too) appear to have taken on a weird glitch in the ZDoom software renderer - see the bottom of the floor:


Also occurs in the latest QZDoom snapshot, only in the 8-bit renderer, not the truecolor renderer, the experimental polygon renderer, or the GZDoom renderer.

[Rachael]

What mod is this? Can you post a link and/or copy?

Additionally, what map is it and what are the idmypos coordinates?

[BFeely]

Sonic.wad, map07 at the beginning.
Also saw the glitch on map03.
Same glitch occurs with void.wad; it appears it affects all sloped floors and ceilings.

[Rachael]

Can you please post a link?

[Rachael]

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

I think I (may) have found the offending function, but I cannot fix it because there are way too many assembly instructions for me to try and calculate by hand. This will have to be fixed by Randi.

https://github.com/rheit/zdoom/blob/mas ... 2.asm#L235

[Edward-san]

It was already mentioned here but of course it would get lost, so yeah it's better keep this thread open.

[Rachael]

Perhaps what might be best is to disable the sloped fill drawer ASM pre-processor directives until this is fixed? Although, considering it only affects 32-bit builds, I doubt it's that important...

It seems to work just fine in 64-bit builds though, which forces the use of C code, granted I am testing on a modern processor but I am still getting really good frame rates without the particular ASM code here...

[Graf Zahl]

To be honest, I think all asm code should be put under review if it is still beneficial. Of course, with 32 bit you got only 8 registers, as opposed to 16 in 64 bit which can make a difference.

[Rachael]

I can cripple my processor down to about 775 MHz and force ZDoom to run on a single core (not that it'll make any difference), then run tests with and without ASM code enabled.

[Graf Zahl]

That's really not what I meant, but someone should eventually run some comparisons of the C and ASM drawers, record how much time is spent in there compared to the rest of the engine and check if there is sufficient gain to justify it. That can be done on a fast CPU just as well.

The important thing is if ditching asm makes it go from, say 50% to 60% or from 50% to 51%.

[Rachael]

That's almost what I was going to do. I was going to use Frozen Time and record the bridge area, expecting it likely to be a large enough render that I can very accurately record its actual milliseconds per frame rather than FPS - using a savegame to record results from both builds with the exact same setup.

Of course this won't rate the individual drawers, themselves, since there are so many of them, but it should give some clue as to the benefits of having ASM in the larger picture.

[Rachael]

The frame rate is extremely variable.

I tested both "r_columnmethod"s with both builds - forcing the 1col and 4col drawers does not make a huge impact (the 4col drawers are *slightly* faster but not much).

On a core i7 processor clocked at 775MHz and forced to run single-core, the NoASM build hovers around an average of 370-380 ms per frame, while the ASM build hovers around 360-370 ms per frame. This is about 5% difference. Both builds were compiled as 32-bit.

This is my updated setup that I used (~25mb) - I included everything to get it going for convenience. Simply copy zdoom.exe from either the ASM or NoASM folder and just run it. I included a savegame right at the bridge, too.

[Graf Zahl]

So, are you saying the C version is FASTER???

[Gez]

You misread, the ASM version takes about 10 ms less per frame, so it's slightly faster.

[Rachael]

So, are you saying the C version is FASTER???

No, it's slower, but only a slight bit. NoASM = C.

Keeping in mind, the MS counter was wildly going between 200 - 450 ms for whatever reason. I really had to guestimate by what number appeared the most often every frame. It would help if ZDoom had a stat profiler of some sort like GZDoom does.

So yes, there are benefits to having ASM, but unless you're running a very complicated mod you won't even notice the difference.

With my processor at full speed (2.5GHz), I got about ~105 ms with ASM enabled, and about ~108 ms without.