[since gl rewrite] Buggy skybox in a zombie horde map

[Edward-san]

From this zandronum ticket, download this extracted and reworked wad file: http://www.mediafire.com/download/g3qn0 ... n/ze12.pk3 , load map ze12, then watch the skybox.

In my hardware, ie Intel sandybridge mobile, gzdoom 323 (zandronum 1.x), the sky appears blue as normal, but in trunk I can see the sky as it lost the blue color, so it's black on the zenit point area. Screenshot on trunk: https://imgur.com/eSRXtBI

[Edward-san]

Interestingly, the problem I mention above happens in the debug build, but in release mode the skybox is a big HOM like ibm5155 reported over that ticket.

[Graf Zahl]

The sky texture being used here is 32x32 pixels which is certainly a contributing factor to the problem.

[Edward-san]

I'm bisecting the gzdoom commits to find the 'culprit' commit. I'll let you know asap.

[Edward-san]

It started from r564 ...

[Edward-san]

Sorry to bump, but do you have any clue on this? I'd like to give an answer to the modders before zan 2.0 comes out.

[Graf Zahl]

No, I haven't had any time to look into it.

[Graf Zahl]

Should be better now.

[Edward-san]

Since the change is made only for 2.x, I've made an attempt to adapt the code to zandronum 2.0 like this:

from:

Code: Select all

		if (texh < 128)
		{
			// smaller sky textures must be tiled. We restrict it to 128 sky pixels, though
			gl_RenderState.mModelMatrix.translate(0.f, -1250.f, 0.f);
			gl_RenderState.mModelMatrix.scale(1.f, 128/230.f, 1.f);
			yscale = 128 / texh;	// intentionally left as integer.
		}
		else if (texh < 200)

to:

Code: Select all

		// [EP] Adapt GZDoom fad3a5410 to current Zandronum codebase
		if (texh < 128)
		{
			gl.Translatef(0.f, -1250.f, 0.f);
			gl.Scalef(1.f, 128/230.f, 1.f);
		}
		else if (texh < 200)

Originally, in gzdoom r900 there was no 'yscale' to begin with. This seems to work fine, but I don't know if 'yscale' can be omitted like that. What do you think? Torr wants to know this.

[Graf Zahl]

The scale is for making smaller textures repeat to the height of 128, because that's what the software renderer does. If you look in the 'else' part of the old code you see a 'glScale' on the texture matrix - that's what this scale variable is there for.

[Edward-san]

Are you talking about this code:

Code: Select all

		else
		{
			gl.Translatef(0.f, (-40 + tex->tex->SkyOffset + skyoffset)*skyoffsetfactor, 0.f);
			gl.Scalef(1.f, 1.2f * 1.17f, 1.f);
			gl.MatrixMode(GL_TEXTURE);
			gl.PushMatrix();
			gl.LoadIdentity();
			gl.Scalef(1.f, 240.f / texh, 1.f);
			gl.MatrixMode(GL_MODELVIEW);
			texscale = true;
		}

?

Zandronum has no such code, because it was introduced in gzdoom r1333. After manually porting it, I'll see about the 'yscale' part...

[edit] Assuming the guess is right, I made a patch for old gzdoom r900 + r1333, attached here. Since I'd like to test this, are there doom2 pwads with as many sky texture sizes as possible, other than the example wad here and normal doom2.wad ?

[Graf Zahl]

The current sky positioning was based on many available ZDoom wads with tall skies. If you port these changes to the GL renderer you should also port the equivalent changes to the software renderer, because it had the positioning somewhat wrong, too.

Here's the thread that prompted the changes to both, highlighting the post with a list of mods:

http://forum.zdoom.org/viewtopic.php?p=468076#p468076

So the obvious problem is, that the broken positioning has been fixed in ZDoom long ago (at a time where I did thorough checks with available mods to get the best results) but not in Skulltag/Zandronum so you maybe have to look out for mods that depend on the old code.

[Edward-san]

The sky positioning problem fix (ie zdoom r1976-r1979) was backported during the code upgrade long time ago, so indeed that should be okay to backport both gzdoom 1333 and the fix, I guess. Thanks for the wads, I'll check them.