[Ezepov]

problems with alpha (5568 works fine)




problems with "ghosts"




sometimes transparent enemies (dn64revisited.grp first level аnd some other .grp)



Windows XP Service Pack 3 build 5.1.2600
Celeron D 3.20Ghz
GeForce 8400GS/PCIe/SSE2 3.3.0
eduke32_win32_20160908-5857

[Daedolon]

It's a known Polymost issue. Never seen the floating Dukes before, though.

[Hendricks266]

I can replicate the "ghosts" problem, and it confuses me very much. It's going to be a hard problem to bisect since the conditions to trigger the flickering are hard to pin down.

Can someone check that dn64revisited map to see if the pig cop is supposed to be translucent?

[Hendricks266]

It looks like the ghosts were introduced in my latest commit.

[Mark]

Hendricks is a spirit medium.

[Hendricks266]

Ghosts fixed in r5858.

[Ezepov]

Thanks! One more bug ( only polymost )

[Mblackwell]

I... can't reproduce in 5858. Is there a specific set of steps you did before it happened?

[Ezepov]

I just start eduke32.exe 5858. Third line of chairs "blinks". Only the third. Only from this side.
.

[Mblackwell]

What's your system and hardware?

Can anyone else confirm since I can't?

[Mark]

Confirmed. Same issue for me.
5858 vista 32bit nvidia 750ti video card

It glitches in Mapster too. So as a quick test I deleted and remade those 2 sectors for the seats and the glitch disappeared. No idea what is causing it.

Problem exists in 5854 too. Time to narrow it down.

I went back as far as 5775 and the glitch is still there. Someone more ambitious can search earlier versions to find where it started.

[Ezepov]

Mblackwell, on 09 September 2016 - 02:37 PM, said:

What's your system and hardware?

Windows XP 32bit Service Pack 3 build 5.1.2600
Celeron D 3.20Ghz
GeForce 8400GS/PCIe/SSE2 3.3.0

[Mblackwell]

Confirmed. It's 100% a 32bit problem. I double checked using Windows 64bit and 32bit binaries in Wine.

[Mark]

5593 was OK. So its somewhere between that and 5775

[Mblackwell]

Happened somewhere between 5700 and 5694.

I don't have a good 32bit build environment setup so I can't test beyond what's in synthesis.

[Mark]

5617 is the first bad one

I hate bisecting but I sure seem to be doing it a lot anyway. I must be subconsiously enjoying it. The thrill of the hunt.

[filipetolhuizen]

Daedolon, on 09 September 2016 - 02:29 AM, said:

It's a known Polymost issue. Never seen the floating Dukes before, though.

Does anyone know which is the last build that doesn't show this?

[Ezepov]

Good alpha - 5568

[filipetolhuizen]

Ezepov, on 12 September 2016 - 02:17 AM, said:

Good alpha - 5568

Thanks! MIDI also works on this. Sticking with this build until it gets fixed.

[Hendricks266]

Ezepov, on 12 September 2016 - 02:17 AM, said:

Good alpha - 5568

Is this really the last build that does not have the problem? No changes were made to the engine between 5568 and 5581.

[Ezepov]

5617 - broken alpha
5608 - good alpha

how about "blinking bug" ?

e1l1


e3l1


e1l2


5617 - blinking
5608 - normal

I think "blink" and "alpha" is the same bug

Windows XP 32bit Service Pack 3 build 5.1.2600
Celeron D 3.20Ghz
GeForce 8400GS/PCIe/SSE2 3.3.0
polymost

[Sledgehammer]

Very annoying bug, at first I thought it was caused by shitty Intel HD Graphics card, but then I tested newest EDuke32 builds on several PCs with nVidia GPUs and x86 Windows 7. However, I believe I had blink issues with x64 builds too and with polymer, need to repair my screen to make 100% sure though.

[Hendricks266]

I can't seem to reproduce this bug on any of my machines, which is frustrating. Doubly frustrating is that none of the commits between 5608 and 5617 touch the engine, so there is no obvious culprit, and both Ezepov and Mark confirm this bisection. We have already ruled out compiler regressions; no upgrades were performed to synthesis at that time.

[Sledgehammer]

Here is my favorite one, this was the first one I noticed. Although there was worse which I experienced when I played Dark Side map, sprites on doors (blue ones, you know, which looks like arc) are blinking too.

Attached thumbnail(s)

• 

[Danukem]

Since this is a "blinking" bug, do you notice any difference when you change your vsync setting? I would be interested to know if it looks any different as you cycle vsync between off, on, and adaptive.

[Sledgehammer]

I can say that I saw blinks on polymer, but it doesn't happen very often and isn't very obvious compared to polymost (I guess it would work the same with v-sync). I'll check it out right now and come back with screenshots.

Update: Here are results

Polymost

V-Sync: off


V-Sync: on


V-Sync: adaptive


Dark Side (v-sync on):


As you can see, there is no impact from v-sync. Here are different renders:

Polymer:





Classic:




It seems like there is no issues with polymer at all, but I had some blinking on my PC on polymer with nVidia card on E1L3 (build 5899 at least), however, I can't test the game right now on it since I need to repair my screen.

Also, Ezepov is right that it happens when you move. Basically it happens when you look at polygons from specific positions and angle (that's what I did when I took screenshots).

[Ezepov]

I don't notice any difference when change vsync. Polygons "blink" not constantly but only when you move.
I tested debug versions:
eduke32_win32_debug_20161020-5905
eduke32_win32_debug_20160206-5617
they have no "blinking" bug.

[AdrenalinDragon]

Ezepov, on 23 October 2016 - 02:02 AM, said:

I tested debug versions:
eduke32_win32_debug_20161020-5905
they have no "blinking" bug.

YES! Finally, a new version of EDuke32 where the flickering bug doesn't happen for me on Polymost! THANK YOU!

[Hendricks266]

If it still happens with release builds, it's still a problem.

I've found a third instance of r5617 reported as the first synthesis build with the problem (bottom comment), which totally baffles me.

[Hendricks266]

Ezepov, on 09 September 2016 - 07:12 AM, said:

Thanks! One more bug ( only polymost )

This is the most slippery, devilish bug I have ever encountered. I have bisected it to three different revisions touching Polymost under different compiler settings and versions, and made it go away by disabling either of two compiler optimizations ("-ftree-pre" and "-ftree-vrp" for those interested). Either there is some horrifically nasty compiler bug in play, or there is undefined behavior buried deep in our code that is only exposed in certain circumstances.