Endless GZDoom 1.5.06 frustrations - testable WAD included

[real_trisk]

Fake contrast is not a 'new feature'. It's something that goes back to the very first released version of Doom.
The only thing that changed since 1.4.x was the way it's controlled to unify the handling between ZDoom and GZDoom. Apparently you had switched it off before and never noticed. I could still see it, albeit with much weaker lighting difference (which was a bug, btw, in the way GZDoom calculated it)

I mean the handling of it was changed. I don't see an option to turn fake contrast on and off in the 1.4.x I'm running. Something must have changed, because I never mess with the default settings.

... and there lies the problem. If you find some non-standard trick producing unexpected result all warning signs should flash. This doesn't mean you found a new editing feature but most likely a bug. I know the Doom community's tendency to abuse those but if it's a bug it may eventually get fixed. Case in point is the warping.

You are giving me WAYYY too much credit there. I don't go out trying to break the engine. I'm not nearly good enough of a mapper or familiar enough with the engine to do something like that. I usually lay awake at night and dream up "wouldn't it be cool if I..." scenarios for my levels, then the next day sit down and try to figure out how to do it. In the case of skyboxes, I saw the viewer thing, figured it worked exactly like Serious Engine, made a sector and placed the viewer in it, and viola, it worked! I wasn't rubbing my hands together thinking, "haha, I really put one over on Graf with this!"

In other words, it was changed because the old implementation did break some level and produced inconsistent results. Bad luck for you that you exploited an engine bug.

Well, I can't argue with this, I guess I did just unluckily stumble into using a bug, but I didn't purposely exploit it. Again, I haven't been mapping long enough to even know there was a difference from one version to the next. All I did was put my texture in and it worked, and now it doesn't. (Which BTW, I fixed now) Thanks for the highly evident degree of compassion you display, though!

You can have a sector skybox inside a cubemap one. Keep the sector with all of your lens flares and such, but give the floor and ceiling F_SKY1 and use horizons on the sidedefs. Then define the actual cubemap textures in GLDEFS. This should also accommodate for any geometry you want to put in there. Fiddly, but it should work.

And that worked! It's crazy, but it worked beautifully. Thank you so much for the solution suggestion! It still isn't as powerful as what I was doing before, but it is close. Thanks again! I still think it is convoluted compared to what I was doing, but as long as I get the results, I'm happy.

What you're suggesting basically translates to "don't update the engine any more because it might break something in someone's map."

That isn't even remotely close to what I'm suggesting. What I'm begging for is that more care be taken to maintain compatibility with previous versions, which is not an unreasonable request from a user's standpoint. I don't consider using all the features of the engine as fully as I possibly can, or figuring out creative new ways of using techniques to be exploiting them. Take, as an example, XYBillboarding sprites. I use this on literally tens of thousands of sprites in my latest level pack. From misty fog to leaves on trees to algae in water to lens flares on light sources. Lots of other people use them for lens flairs, but I hope I've discovered some novel new ways of using them, including animating them with warping. So what happens if the fundamental way that GZDoom addresses XYbillboards changes? Let's say their rotation is altered to clamp to the upper left pixel of the sprite? (I know this is silly and impossible, it's just an example.) In this example, not only are my maps broken to utter uselessness because thousands of sprites now look wrong, but many other people's maps would suddenly look terrible as well. This is not being backwards compatible.

To continue with this example though, if a new form of XYBillboarding is implemented under a new Decorate definition, perhaps +XYTopLeft or something similar, we get the best of both worlds: total compatibility with old maps, but a cool new toy to play with! (Again, this is just a silly example, but I think you get my point.)

Anyhoo, thanks to those that helped me fix my problems, my levels are now on track to release within the next few days, hopefully.
Ben

[Graf Zahl]

I mean the handling of it was changed. I don't see an option to turn fake contrast on and off in the 1.4.x I'm running. Something must have changed, because I never mess with the default settings.

Of course something was changed - and the most likely reason was to fix some other compatibility problem. Changes like this aren't made on a whim - they are always made to make behavior more consistent with other existing Doom engines or more importantly, Doom.exe itself.

Unfortunately I can't find the specific code that caused this change so I can't tell you the precise reason.

EDIT: I finally had the chance to do some detailed investigation of what was changed. It looks like when the fake contrast code was changed to match ZDoom's one small but important detail was overlooked: Due to imprecisions, the fake contrast in the software renderer gets implicitly switched off if the light level is larger than 252. But with hardware rendering's much greater color precision this did not happen, of course. In the next version it will be like it was in 1.4.x again - although I still recommend not to create such skyboxes.

[Nash]

Will there be complains along the lines of "how come there's no lighting difference between 252 and 253???!?!?!1111 wtf gzdoom" or does it not matter?

(This is a legit question)

[Graf Zahl]

There will be a lighting difference, albeit a very small one. I only made some minor tweaks to the fake contrast calculation so that its intensity diminishes for very bright light levels and goes away completely for 253 and above, so that the visual results are closer to the software renderer. The diminishing does not exist for the software renderer but is necessary so that smoothly fading light effects don't suddenly jump between fake contrast on and off but instead handle it gradually.

[NeuralStunner]

I probably won't notice, because I find fake contrast exceedingly ugly and leave it tuned off.

I remember working on vanilla maps and going "what is this crap?" when I noticed certain walls being absurdly brighter or dimmer. So, good riddance.

[The Ultimate DooMer]

That shouldn't be necessary under any circumstance. Not too many people would play it if that was the case.

Such mods frequently get ridiculed because they give the impression that the creator was incompetent by depending on certain glitches.

Personally I don't see what's wrong about shipping a project with a specific GZDoom version that's proven to work...it's not hard to create a folder just for that project and copy the IWAD and the zip contents into it, and it guarantees that the user will be able to play the project without any bugs introduced in later GZDoom versions.

I'm close to releasing a big update to Serpent that came about because of said bugs, and 1.5.06 is still the only version that works 100% because of this bug (granted it's not a game-breaker like the 2-sided poly bug was, but it still looks fugly when lighting up a torch). Whether I ship it with 1.5.06 or not I haven't decided yet, but every time I play it with a newer version, I'm always worried that I'll find something broken like I did recently.

[Graf Zahl]

Personally I don't see what's wrong about shipping a project with a specific GZDoom version that's proven to work...it's not hard to create a folder just for that project and copy the IWAD and the zip contents into it, and it guarantees that the user will be able to play the project without any bugs introduced in later GZDoom versions.

It also guarantees that the project will be rendered unplayable should something render that version inoperable on future systems. I have lost count how many changes I needed to add to get around performance issues or slight incompatibilities with certain hardware. The worst thing was the notorious ATI crash. So if that version the mod is tied to gets in a similar situation - bad luck, can't be played anymore.

Should the engine get ported to a new OS - eek, screwed you!

You do not want that to happen. Remember Caverns of Darkness? It should be the ultimate warning sign why shipping a mod with a custom EXE is a very bad idea. You are cutting yourself off from all future improvements.


Concerning your bug link - that only occurs with texture based lighting. Shader based lights work fine. So anyone with a recent graphics card should have no problem playing it. It'd still be nice if someone could help me track down the revision that caused the change. I sadly don't have time to do it.

[Enjay]

Concerning your bug link - that only occurs with texture based lighting. Shader based lights work fine. So anyone with a recent graphics card should have no problem playing it.

However, it is perhaps worth pointing out that with my GTX285 (assuming that it still qualifies as a reasonably new card) using shaders for dynamic lights is off by default. So with TUD's example file (in the DRD thread) I get the visual problem by default when puking script 2. In fact, it wasn't until you made your post above that I checked and found that shader lights were off and that switching them on fixed the problem.

Perhaps, like other shader effects, shader lights should be on by default for cards that can handle them unless it would cause problems. eg Can a shader-warping flat or a brightmapped texture/sprite be illuminated by a shader light or would it trigger the "only one shader per surface" limit?

[Graf Zahl]

It's off by default because on some ATI cards it caused serious issues. No idea if the drivers got fixed by now. If so I'd enable it by default.

I'll still need some help tracking down the cause of this though

[Demolisher]

Shader Lights on my ATI card have to be turned off, as if a light gets split, like down a staircase, it causes horrendous framerate drops, from 45-60 to 10-15. With it disabled it looks almost the same, but avoids the slowdowns.

[Graf Zahl]

What card do you have?

[Demolisher]

The problems specifically were real_trisks's E2M4 Redux, where hardware shaders fell apart on the first teleport you see upon start-up.

AMD A8 - 3500M APU with Radeon HD Graphics 1.50 GHz
6.00 gb RAM (5.48 usable)
Windows 7 Home Premium SP1 64-bit OS

[Graf Zahl]

Hm, ok, from what I found that's pretty low end with bad performance to be expected.

Also have a look here: http://forum.drdteam.org/viewtopic.php?f=22&t=5814
I re-uploaded all my benchmark stuff from 2 years ago. I'd like to see the values your card produces.

[Demolisher]

It ran slightly better on my lava spewing laptop with the nVidia 8600m. When I get back home in about 2 weeks I can try it with an nvidia card with about the same power (similar frame rates on modern games) to see if it's an ATI issue. The funny thing is that it's only the shaders that cause problems, and the majority of the problems are when the light is split, or needs to be drawn on multiple surfaces. Also, Skyrim on Ultra settings + the Official Hi-Res Texture pack runs 30-40 FPS solidly. RAGE runs around 40-50, and RAGE hates ATI cards. I can get you benchmarks next week, probably Tuesday-Wednesday, I have a lot of paperwork for checking out of my base.

[Graf Zahl]

I can tell you outright that a Geforce 8600 does not have these performance issues. I owned one for almost 5 years.
The main problem with the lights is that they need to transfer quite a bit of data to the GPU and if these transfers are slow for some reason performance will break down quite drastically.