ZDoom

Cacodemon345 wrote:I think the changes to the sky code seems to be causing those bugs.

We keep having to tell you not to make brain-dead posts. This is falling into the territory of moderator action, now. When Graf asked you to stop, Gez asked you to stop, and I asked you to stop at least twice, that's more than enough for the warning you just got.

I think the changes to the sky code seems to be causing those bugs.

User was warned for this post -Rachael

A hypothesis: could it be that the skybox in some cases would not be initialized depending on some events, for instance if the wad is launched from GZDB and GZDoom main window does not have the active focus yet.. (in fullscreen mode only)? This suddenly occurred to me because it's always corrected if you switch fullscreen off and on. And I did some more testing with builds that went wrong: they seem to go okay when I drop the the wad on the GZDoom icon instead of launching it from GZDB..

Edit: I do see some changes in the code related to sky a couple of days earlier before the error occurred in the builds mentioned earlier (d694e19f0 & 785a6c2ce). Don't know it this could be related though)

This actually sounds like an uninitialized variable somewhere.
Hmm...

So today I started to get the latest builds from GitHub, and just before getting previous commits, I wanted to test the latest version first, so I compiled the latest code and guess what: the bug does no longer occur on the old Intel gpu with GL 4.0.
As an extra test I checked with the latest devbuild from today (build 4pre-524-ge3c78ab83) and this one was okay too. On the GL 4.2 laptop however both builds still show the strange skybox behaviour.

Was GZDoom code changed very recently changed in this respect? If not than I think indeed only the older intel gpu's are to blame. In that case for me this issue needs no longer be addressed (there is a simple work around by switching Fullscreen off and back on, or by using borderless window).

Yes, I agree. But you never know

The first one is likely to my eyes. I don't think the weapon renderer actually uses code from the world renderer.

Graf Zahl wrote:There's still two uncompiled revisions in between those two...

So it's one of these commit's that introduced this behaviour on older intel gpu's:

67cb6e63b cleanup of the 2D interface.
d904fba05 trying to clean up the weapon renderer.
c2ac98535 split off the utility functions from gl_weapon.cpp.

I could try to track it down with the original plan since 2 of the builds are not present on AppVeyor.

Graf Zahl wrote:Since this happened in another issue I fixed a few hours ago: Are you using 32 or 64 bit builds?

64 only.

Since this happened in another issue I fixed a few hours ago: Are you using 32 or 64 bit builds?

Cacodemon345 wrote:I'm assuming it to be related to a Intel GPU-side issue. They're GPUs that has poor OpenGL support.

Certainly it's possible that it's related to older Intel GPU's, but that's not the whole story, because it worked flawlessly with build 1345c8e7 and the builds before that.

I'm assuming it to be related to a Intel GPU-side issue. They're GPUs that has poor OpenGL support.

I cannot reproduce it even with that particular revision. The odd thing is that between those two only 2D code was supposed to have changed.

There's still two uncompiled revisions in between those two...

Yes, thank you, that really made things easier

With this I was able to narrow it down to the following builds:

Screenshot build 1345c8e7 (OK):


Screenshot build c2ac9853 (WRONG):



Note that the weapon sprite also is wrong here, which was corrected separately later.