Sky texture offset is ignored
Closed this issue · 11 comments
Hello :)
I have noticed that Crispy-DOOM ignores the Y offest i can assign in the TEXTURE lump.
Is that as intended or a bug?
Because Eternity Engine and GZDoom shift the texture patch the amount i enter in the TEXTURE lump.
Here is a test-WAD for DOOM with texture patches Y axis shifted 60 pixels up:
I think this is the explanation:
Lines 380 to 382 in 793aaab
Seems so. I have added another patch to the texture and the Y shift worked, but only in the positive number way.
Negative numbers shifted something but the patch was cut where it should not be.
So it is not a bug. It is meant to be so and i have to rethink what i am doing.
I wanted to use the same patches for multiple ports. EE for example needs 528 pixels height to cover the whole mouselook area. So i thought shifting this bigger patch in the texture lump 60 pixels up would fit for Crispy and Inter.
Woof ignores the offset in the Texture lump too, but that is no problem thanks to the Skydefs lump.
And thank you for this info :)
As this is not a bug it can be closed.
Here is an updated version which supports Crispy-DOOM too. So Crispy can benefit of tall and wide skies too, even it can not animate them.
Crispy uses the upper parts of the changed SKY1,2,3 textures without scrolling.
And Woof's SKYDEF lump shifts those static Crispy parts so far up that there is the sky below the static Crispy images viewable and scrolls them.
The graphics are far from finished. But technically it works.
As this is a normal behavior that affects single patch textures it can be closed.
Sorry for being late with my advice, but you could probably just use MBF sky transfers which work in about any advanced source port and which you could modify like any other wall texture.
Hi Fabian,
no problem about late answer :)
I know about MBF Sky transfers. But i do not want to build a map, i want to create a sky ressource pack with wider and taller skies, that have scrolling backgrounds when the port is able to work with the Skydefs, Emapinfo or Zmapinfo lump.
So ports like Crispy and Inter have tall and wide skies and Woof, EE and GZDoom can scroll them.
Thanks to the knowlege you gave me from Crispy's code i had organised the Sky1,2 and 3 textures so that Crispy and Inter do not have to shift the Y axys and the Skydefs capable ports shift this texture up and scroll it.
Dankeschön :)
Gern geschehen!
Colleagues, turns out, current approach is simply correct and "vanilla-compatible", and even Woof using it. Why so? Let's have a look at doom.wad:
See? SKY1 is shifted 8 pixels up. Should this be taken into account in skies drawing, here's what we'll see straight on E1M1, a black line of "empty pixels":
This 8 pixel offset of SKY1 is not unknown to me. I saw it many years ago as i extracted the graphic and wondered why the graphic is only 120 pixel high, but never paid much attention to it.
In my opinion Chocolate/Crispy/Inter-DOOM and Woof handle it as intended and i know these Yangshou Mountains this way since the 90s. So why use this offset and shift the graphic 8 pixels up?
With status bar on we have 15 pixels from the top of the mountain to the upper end of the screen. With this offset we only have 7 pixels in between. Less then the half.
Eventually this 8 pixel offset was an oversight and no one found it neccesary to correct it with the non-use of this y offset in mind.
The other thing is, when the texture is shifted 8 pixels up, we can see the bottom even in 4:3 aspect ratio at E1M1's green armor and that is not a good thing. Julias 16:9 picture shows it even more. It is good as it is.
Btw, because i know Eternity Engine can use the offset for one patch textures,
i looked in E1M1 at the original DOOM.WAD SKY1 and counted 15 pixels between top of the mountain and upper end of the screen.
Same amount as in Choco, Crispy, Inter and Woof.
And when standing at the green armor there is no black 8 pixel high stripe.
When i use another texture in a pwad as SKY1 the offset works.
It seems EE ignores the offset for the original SKY1 texture for a good reason too.
It seems EE ignores the offset for the original SKY1 texture for a good reason too.
Apparently: