DRD Team

The bug was never fixed. I got it myself with almost every revision between 555 and 604.

The problem is just that I don't know what's causing it. It looks like the z-buffer contains invalid data but I haven'd found out yet why.

With svn versions after 1304 I get this glitch on startup



just for a split second, and then it is ok.

Does not occur with 1327.

Happens again with 1337.

That's actually a very old issue. I've noticed it more frequently recently, but still don't know what causes it. It seems more likely to happen if the computer is a bit strained for resources while the game starts.

Something vaguely interesting is that (while starting Jimmy's jukebox), I saw one of the light column things that was behind a wall before the rest of the geometry was drawn. Didn't manage to capture that on a screenshot and the map hasn't replicated the issue yet.

Happens on latest stable. I renamed my ini and it still happened. Doesn't happen in zdoom.

win7 x64, gtx260 with drivers from couple of months ago, something isn't "initialized" properly for the initial frame rendering ?

Obviously. I have no idea what, though.

If I run Gzdoom through QZDL launcher and just start a new game it doesn't happen, BUT if I run it directly through explorer the glitch happens. (Maybe it has to do with the IWAD selection window ?)

But if I run through QZDL, bring down the console, press ESC then start a new game, the glitch still happens and the console is semi-visible, half-screen <-- wtf inconsistency

EDIT: Yeah, if I run gzdoom with the -iwad doom2.wad parameter, the glitch never happens, except with the console ESC thingy (which makes the meltdown effect seems laggy)

I use qZDL all the time and it happens to me, so that's not it.

In my case, the undrawn geometry space is black, likely because I have R_ClearBuffer set to black.

The glitch only occurs the first time I begin a game (from menu). As soon as the screen wipe is finished, the space is filled. If using -map, I never see it at all as the game begins immediately. (No isssues with -warpwipe though.)

@ NeuralStunner

If you launch from a gzdoom shortcut with "-iwad doom2.wad" parameter to avoid the IWAD selection window, does the glitch happen ?

VGA wrote:If you launch from a gzdoom shortcut with "-iwad doom2.wad" parameter to avoid the IWAD selection window, does the glitch happen ?

It does.

This is actually something I too would ike to see fixed. However what makes it even harder to track down is that it does not happen all the time... sometimes I can start GZDoom several times in a row without the glitch ever appearing, then suddenly it is there again, then suddenly gone again.

The glitch only seems to appear with screen wipe styles enabled. And it does not matter which style is activated, it happens with all of them. When set to None, the glitch disappears. So perhaps that would be a place where to look into the code again?

I also find it quite intriguing that it is the same area of the map that is affected across different computers. The effect looks exactly the same for me as it does in NeoHippo's screenshot.

Hmmm, going in display options and then starting a new game prevents the glitch from happening. Even if I change nothing. But only if using my ini. If I rename my ini and do the same, the glitch happens. I'm using hires options, rescaling etc if it matters.

Nvidia here. 1680x1050, vsync, autoloading lights.pk3 and brightmaps.pk3

1) I did the test about 25 times, if I first go to options and then start a new game, the glitch doesn't happen. But not with the default options, but my own. With the defaults, it still happens anyway.

2) If I don't see the IWAD selection window (shortcut with -iwad parameter or through QZDL) the glitch doesn't happen. But with my options. With the defaults it happens anyway.

Here is my ini :
http://www2.zshare.ma/mzuv9r5qw9ui

Lmao this is crazy.

Bringing down the console and then using the menu 100% reverses all the above behaviour in all of the cases I described. The glitch repeatedly happens when it normally wouldn't and doesn't happen when it should. It absolutely results in the opposite of what I expect. In each case.

It happens for me too, but it gets normal when the effect ends. I'm getting it with Melt effect only.
I have AMD Athlon II X2 255 (3,1 GHz 2-core), 8 GB RAM and nVidia GeForce 9200. I don't have this thing with any other game. Well, I don't even know about any game that uses fades like this.

The issue is caused by uninitialized member angletime of vertex_t structure. The fix is quite obvious.

Spoiler: Patch

---

Code: Select all

Index: src/r_defs.h
===================================================================
--- src/r_defs.h	(revision 1598)
+++ src/r_defs.h	(working copy)
@@ -98,6 +98,7 @@
 		x = y = 0;
 		fx = fy = 0;
 		viewangle = 0;
+		angletime = 0;
 		dirty = true;
 		numheights = numsectors = 0;
 		sectors = NULL;

Wow! Something this simple? I guess that's why nobody ever found it before. Thanks a lot.