[Fixed] [2.9pre-1532] Sloped floor rendering glitch

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

[2.9pre-1532] Sloped floor rendering glitch

Postby BFeely » Sat Nov 26, 2016 10:22 pm

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

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.
BFeely
 
Joined: 11 Mar 2004

Re: [2.9pre-1532] Sloped floor rendering glitch

Postby Rachael » Sat Nov 26, 2016 10:39 pm

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

Additionally, what map is it and what are the idmypos coordinates?
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Graphics Processor: nVidia with Vulkan support

Re: [2.9pre-1532] Sloped floor rendering glitch

Postby BFeely » Sat Nov 26, 2016 10:51 pm

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.
BFeely
 
Joined: 11 Mar 2004

Re: [2.9pre-1532] Sloped floor rendering glitch

Postby Rachael » Sat Nov 26, 2016 10:53 pm

Can you please post a link?
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Graphics Processor: nVidia with Vulkan support

Re: [2.9pre-1532] Sloped floor rendering glitch

Postby Rachael » Sat Nov 26, 2016 11:55 pm

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
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Graphics Processor: nVidia with Vulkan support

Re: [2.9pre-1532] Sloped floor rendering glitch

Postby Edward-san » Sun Nov 27, 2016 3:02 am

It was already mentioned here but of course it would get lost, so yeah it's better keep this thread open.
Edward-san
Mathematics is the language with which God has written the universe. (Galilei)
 
Joined: 17 Oct 2009

Re: [2.9pre-1532] Sloped floor rendering glitch

Postby Rachael » Sun Nov 27, 2016 12:00 pm

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...
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Graphics Processor: nVidia with Vulkan support

Re: [2.9pre-1532] Sloped floor rendering glitch

Postby Graf Zahl » Sun Nov 27, 2016 12:34 pm

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.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: [2.9pre-1532] Sloped floor rendering glitch

Postby Rachael » Sun Nov 27, 2016 12:42 pm

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.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Graphics Processor: nVidia with Vulkan support

Re: [2.9pre-1532] Sloped floor rendering glitch

Postby Graf Zahl » Sun Nov 27, 2016 12:55 pm

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%.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: [2.9pre-1532] Sloped floor rendering glitch

Postby Rachael » Sun Nov 27, 2016 12:57 pm

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.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Graphics Processor: nVidia with Vulkan support

Re: [2.9pre-1532] Sloped floor rendering glitch

Postby Rachael » Sun Nov 27, 2016 1:44 pm

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.
Last edited by Rachael on Sun Nov 27, 2016 4:41 pm, edited 1 time in total.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Graphics Processor: nVidia with Vulkan support

Re: [2.9pre-1532] Sloped floor rendering glitch

Postby Graf Zahl » Sun Nov 27, 2016 2:15 pm

So, are you saying the C version is FASTER???
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: [2.9pre-1532] Sloped floor rendering glitch

Postby Gez » Sun Nov 27, 2016 2:18 pm

You misread, the ASM version takes about 10 ms less per frame, so it's slightly faster.
Gez
 
 
 
Joined: 06 Jul 2007

Re: [2.9pre-1532] Sloped floor rendering glitch

Postby Rachael » Sun Nov 27, 2016 2:19 pm

Graf Zahl wrote: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.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Graphics Processor: nVidia with Vulkan support

Next

Return to Closed Bugs

Who is online

Users browsing this forum: kipo and 0 guests