Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
entryway

zdoom sky vs gzdoom sky (271+254 actions)

Recommended Posts

Which is meant to be the proper behavior? Eternity gives the same result as GZDoom, by the way.

Share this post


Link to post
Gez said:

Which is meant to be the proper behavior? Eternity gives the same result as GZDoom, by the way.

GZDoom's behavior is correct IMO. PrBoom/GlBoom work in the same way.

Share this post


Link to post

Interesting.

The formula for MBF-type sky scrolling is one of the last remnants of the PrBoom roots of my code.

The oldest ZDoom version I could test is 2.0.63a which also has this bug.

Share this post


Link to post

It is so hard to make wad compatible with just prboom/glboom and zdoom/gzdoom. Almost impossible :( Every fucking thing works differently with every fucking version. Shit with zdoom, but cool with gzdoom; cool with gzdoom, but shit with glboom-plus; cool with both gzdoom and glboom/prboom - shit with zdoom :(

The only way to have correct behavior and avoid WTF comments is adding supported ports with needed settings... :(

Share this post


Link to post

This is a bug and I already reported it to the person who needs to fix it. Apparently it got never ever tested because nobody has used it yet.

Share this post


Link to post

Interestingly, Eternity gives a result that is different from both.

ZDoom: I can see "RAN" out the window, everything else in the sky is blank white.
GZDoom: I can see "GRAF" and a mirrored RA if I hug the window and look to the left.
Eternity: I can see "RANDY" in full, and a mirrored GRA when looking to the left as above.

Share this post


Link to post

no difference between 271 and 272 in gzdoom

must be something like that in gl_skydome.cpp
fz = TO_GL((skyflip ? z : -z));

Share this post


Link to post

Already fixed. It was indeed completely missing from the sky rendering code.

But there's still a coordinate discrepancy between ZDoom and the other ports. Something in the setup also isn't completely correct.

Share this post


Link to post
Gez said:

ZDoom: I can see "RAN" out the window, everything else in the sky is blank white.
Eternity: I can see "RANDY" in full, and a mirrored GRA when looking to the left as above.

That only happens if you have sky stretch on - that's because ZDoom is stretching it on both the X and Y axes, while Eternity is only stretching it on the Y axis, leaving the X axis alone. I get identical results in ZDoom and EE if I turn sky stretch off.

Share this post


Link to post

EE's sky stretch algorithm originated from SMMU, and only does what's necessary to actually cover the vertical space created by the ability to look up and down. I assume that also stretching on the horizontal axis is some kind of aesthetic decision in ZDoom, since it is not required from a technical standpoint.

Share this post


Link to post
Quasar said:

EE's sky stretch algorithm originated from SMMU, and only does what's necessary to actually cover the vertical space created by the ability to look up and down. I assume that also stretching on the horizontal axis is some kind of aesthetic decision in ZDoom, since it is not required from a technical standpoint.

Is there a way to disable screen stretching in Eternity? Maybe I'm just dumb and can't find the option but I never mouselook and the stretching looks hideous.

Share this post


Link to post
Graf Zahl said:

It's to preserve the aspect ratio. Which doesn't change the fact that it's ugly.

Yes, stretching is shit and should be removed from zdoom too and replaced with something GL has

arrrgh said:

Is there a way to disable screen stretching in Eternity? Maybe I'm just dumb and can't find the option but I never mouselook and the stretching looks hideous.

There is config variable and even GUI setting IIRC, but both methods are shit

With mlook you will have something like that
http://prboom-plus.sourceforge.net/Screenshot_Doom_20091111_143627.png
or that
http://prboom-plus.sourceforge.net/Screenshot_Doom_20091111_172112.png
instead of that
http://prboom-plus.sourceforge.net/Screenshot_Doom_20091111_143609.png

I am happy gzdoom and glboom-plus do not use stretching at all any more

Share this post


Link to post
arrrgh said:

Is there a way to disable screen stretching in Eternity? Maybe I'm just dumb and can't find the option but I never mouselook and the stretching looks hideous.

Yes & no comment. Mouse Options - page down.

Share this post


Link to post
GreyGhost said:

Yes & no comment. Mouse Options - page down.


That's one of the things I've always had to remind myself in EE - I always expect things like sky stretching to be in display options or something similar. But putting it in mouse options seems to make sense from a programmer's standpoint, so whatever.

Share this post


Link to post
entryway said:

Yes, stretching is shit and should be removed from zdoom too and replaced with something GL has


There is config variable and even GUI setting IIRC, but both methods are shit
I am happy gzdoom and glboom-plus do not use stretching at all any more


I may be the only one, but *not* stretching can look just as shitty as stretching! for example, in prboom-plus, the sky cuts of abruptly; there is no smooth transition in the skybox(at least on my machine)

Share this post


Link to post

* sigh * the fact of the matter is that Doom was not intended for mouselooking. Someone (I?) should make some nice cubemaps or full 3D skyboxes that replicate the ones from Doom and Doom II for ports that can support it.

Actually, on that note, which ports do support cubemap skyboxes?

Share this post


Link to post

ok ... Vavoom, GZDoom and Risen3D. Correct me if I'm wrong, but I thought glBoom and Doomsday could support them as well? What about ZDoomGL? I only ask because recently I've found that the way most Doom ports handle skies is to stretch them or add some unsightly 'smudge' effect at the top, which looks ugly IMO. I figure if I make some cubemap skyboxes for ports that support it, maybe we can cut down on the ugliness.

Share this post


Link to post

Skyboxes can be achieved in Doomsday using the skymodel features but it does not currently support automatically creating a skybox from a cubemap texture.

The skymodel features have been in the engine for many years now and there are quite a few different interpretations of the of the IWAD original skies to choose from.

Share this post


Link to post
Patrick said:

* sigh * the fact of the matter is that Doom was not intended for mouselooking.


Yet the games spun off the doom engine *are* intended for mouselooking. how do *they* handle it? Taller skies? Then that's how to fix it. Is it possible to edit the original [final]doom[2] skies to make them fit the mouselooking range of software engines?

Share this post


Link to post
Csonicgo said:

Yet the games spun off the doom engine *are* intended for mouselooking. how do *they* handle it? Taller skies? Then that's how to fix it. Is it possible to edit the original [final]doom[2] skies to make them fit the mouselooking range of software engines?

Well, yeah, and it's been done several times by different people, but considering the billions of PWADs with custom skies that's not really a solution.

Share this post


Link to post
Patrick said:

Someone (I?) should make some nice cubemaps or full 3D skyboxes that replicate the ones from Doom and Doom II for ports that can support it.

Absolutely.

To make them work as transparently as possible, I suggest the source port computes a hash of the sky image, and looks up that hash in some text lump to determine which skybox to use. This allows custom skies to work properly.

EDGE supports six-sided skyboxes too.

Share this post


Link to post
Patrick said:

glBoom and Doomsday could support them as well?


Code for this is readily available from several sources so sure, they could easily add it. This feature cost me an hour or 2 when I first implemented it.


[B]What about ZDoomGL?



That port is dead. Timmie hasn't worked on it for years and he seems to have disappeared so there's nothing to expect here.

For what it's worth the last version still had serious performance issues on larger maps and wasn't really usable.


I only ask because recently I've found that the way most Doom ports handle skies is to stretch them or add some unsightly 'smudge' effect at the top, which looks ugly IMO. I figure if I make some cubemap skyboxes for ports that support it, maybe we can cut down on the ugliness.


Even if you made such skies, they'd still not be the same as the originals meaning that many people won't use them.

Share this post


Link to post
Patrick said:

Someone (I?) should make some nice cubemaps or full 3D skyboxes that replicate the ones from Doom and Doom II for ports that can support it.

Ultimate Doom (4 skies), Doom II (+3 =7), TNT (+3 =10), Plutonia (+3 =13), Heretic (3 +3=16), Hexen (+6 skies not counting the two sky walls = 22), Chex Quest (3 skies total +3=25), HacX (+3 =28), the Master Levels (hey, they're official) and most popular megawads (+a lot = a freakin' lot)...

Graf Zahl said:

That port is dead. Timmie hasn't worked on it for years and he seems to have disappeared so there's nothing to expect here.

And even if he's back tomorrow, he's not going to work on it anymore since the last news was that he had started a total rewrite from scratch; presumably that's what he'd want to continue.

Share this post


Link to post
Gez said:

Ultimate Doom (4 skies), Doom II (+3 =7), TNT (+3 =10), Plutonia (+3 =13), Heretic (3 +3=16), Hexen (+6 skies not counting the two sky walls = 22), Chex Quest (3 skies total +3=25), HacX (+3 =28), the Master Levels (hey, they're official) and most popular megawads (+a lot = a freakin' lot)...



Even if the sheer amount wasn't a problem let's not forget one other factor:

The sky images (especially Doom1's first 3 skies) are so iconic that replacing them with something similar but not the same is not a solution.

Share this post


Link to post
Graf Zahl said:

Code for this is readily available from several sources so sure, they could easily add it. This feature cost me an hour or 2 when I first implemented it.

Cubemap costs about 15 minutes of work I think, but it needs additional lump and I do not want to think about and parse

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×