GZdoom's software mode draws transferred skies at a wrong height

[Antroid]

In the attached screenshots, the left half of the room has a normal sky and the right half is a sector that has the same sky texture transferred into it via action 271 (not sure why it happens to be mirrored but that's not important I think).

 

The one with a perfectly mirrored sky is Zdoom 2.8.1, and the one where the two halves are vertically offset is GZdoom 3.1.0. The offset doesn't seem to be affected by the video mode (including different aspect ratios) or hud size. However, in the opengl mode GZdoom doesn't have the wrong offset and renders it correctly, as you can see in the third screenshot.

 

If a zdoom wad is making use of transferred skies that don't tile vertically, and someone plays it in gzdoom's software mode, there might be visual glitches with the sky. If this isn't something that's gonna be fixed, how should I go about making my zdoom level with transferred skies look the same in both sourceports? Maybe if I know what causes this difference, I can somehow counteract it. I can use the texture offset to move the transferred sky, but that affects both sourceports, and fixing it for gzdoom breaks it for zdoom. The best I can figure for now is to set it between the two heights, so it's less wrong in each sourceport.

[Graf Zahl]

The first thing that you need to do is a bug report. It's not the first time I heard of this so you may check out a more recent devbuild to see if it was already fixed

[Gez]

1 hour ago, Antroid said:

In the attached screenshots, the left half of the room has a normal sky and the right half is a sector that has the same sky texture transferred into it via action 271 (not sure why it happens to be mirrored but that's not important I think).

That's because you want action 272 instead.

 

Vanilla Doom always flips the sky when projecting it. MBF added action 271 to project without flipping and action 272 to project with flipping.

[ukiro]

Hah, was going to report this same thing. The height is indeed rendered wrong, 200px tall skies should cover the world view vertically (when not looking up or down) but it seems the current implementation wants 240 pixels to do this across all video modes.

[Antroid]

2 hours ago, Graf Zahl said:

The first thing that you need to do is a bug report. It's not the first time I heard of this so you may check out a more recent devbuild to see if it was already fixed

Pardon my ignorance here for a sec. Am I right in assuming this is where I get the devbuilds? The bug still persists in the latest version (gzdoom-x64-g3.2pre-116-g2e33165.7z). Also, Avast was screaming about its gzdoom.exe being totally suspicious so I had to add the folder to the exceptions list, but that's probably normal..?

 

Anyway, when I post the bug where I'm assuming I'm supposed to do it, which is here, should I put the latest devbuild version in the title or the latest "official" (or whatever it's called) GZdoom release, 3.1.0?

 

 

1 hour ago, Gez said:

That's because you want action 272 instead.

 

Vanilla Doom always flips the sky when projecting it. MBF added action 271 to project without flipping and action 272 to project with flipping.

Huh, I didn't know it flipped them by default. Never had them side by side like this so it never came up, but I remember the other action which flips it. Wasn't aware that they were reversed like this. Thanks for clarifying.

 

 

1 hour ago, ukiro said:

Hah, was going to report this same thing. The height is indeed rendered wrong, 200px tall skies should cover the world view vertically (when not looking up or down) but it seems the current implementation wants 240 pixels to do this across all video modes.

In my case it's just standard 128 height skies, and setting the texture to -16 vertically seemed to make it right, though that might not be pixel-exact. For now I settled on making it -8 so it fortunately looks passable in both ports.

[Graf Zahl]

48 minutes ago, Antroid said:

Pardon my ignorance here for a sec. Am I right in assuming this is where I get the devbuilds? The bug still persists in the latest version (gzdoom-x64-g3.2pre-116-g2e33165.7z). Also, Avast was screaming about its gzdoom.exe being totally suspicious so I had to add the folder to the exceptions list, but that's probably normal..?

 

That's not normal but those files are definitely clean.

 

48 minutes ago, Antroid said:

 

Anyway, when I post the bug where I'm assuming I'm supposed to do it, which is here, should I put the latest devbuild version in the title or the latest "official" (or whatever it's called) GZdoom release, 3.1.0?

 

Report the bug for 3.1.0 but mention the latest build with which you could confirm it in the message.

 

 

[Antroid]

13 hours ago, Graf Zahl said:

Report the bug for 3.1.0 but mention the latest build with which you could confirm it in the message.

Done. Had to register under a different username though, and use a work email (fantastic idea, no?). Turns out I already had an account there but it had been "deactivated" and "could only be activated by an administrator". I wonder if that's because of total inactivity (I don't recall participating at all) or I had done something stupid and got banned. : > Hopefully this doesn't count as ban evasion or something.

[Graf Zahl]

You should have asked to reactivate the old accout. There's even some sticky message about it.

This was done because last year some asshole hijacked some old, inactive accounts with weak passwords and used them for shitposting.

 

[Rachael]

You can also report bugs without registering. Not every nook and cranny of the internet needs 500 pages of your life's story and your social security and/or national id number. :)

 

(the bug is now fixed, btw)

Edited July 11, 2017 by Rachael