DRD Team

Is there a way to make a decorate entry "port-sensitive" so that it's ignored when running GZDoom but loaded normally when using ZDoom?

Thanks.

No.

And for consistency, there shouldn't be. The same DECORATE lump should give the same result regardless of implementation, whether it be in ZDoom (the reference standard), GZDoom, Skulltag, ScoreDoom, Vavoom, whatever...

What were you trying to achieve with that?

Gez wrote:And for consistency, there shouldn't be. The same DECORATE lump should give the same result regardless of implementation, whether it be in ZDoom (the reference standard), GZDoom, Skulltag, ScoreDoom, Vavoom, whatever...

What were you trying to achieve with that?

I was thinking more in the lines of commenting out code ala //////, that is, placing some kind of tag at the beginning of the entry in order to disable it. Let's make it a "/NG/" (or "no GZDoom") for this example. That way only GZDoom would ignore it so there would be no room for inconsistency or even mistakes: if you don't want GZDoom to ignore it, don't use "/NG/" Well, you get the idea.

This is the reason for the question:
I created this as a replacement for the default GZDoom spectre which still has some ugly pink pigment residues to it and isn't hard to see at all, something I believe was intended for the original Doom where spectres would completely blend into the environment under certain circumstances.

Since the ZDoom can handle the fuzzy effect just right, I didn't want it to use the new spectre, which's only part of a much larger decorate modification.

Obviously I don't have a problem using 2 different wads, but I tend to aim for simplification.

In that case: Don't do it at all! Either people like GZDoom's spectre as it is or they'd want to replace it themselves. But don't try to think for others preemptively.

Graf Zahl wrote:In that case: Don't do it at all! Either people like GZDoom's spectre as it is or they'd want to replace it themselves. But don't try to think for others preemptively.

And who said I was going to release it? I'm doing this for me. Talking about thinking for others...

If you've installed ZDoom and GZDoom in separate directories, you can autoload different mods.

If it's just for you, you can as well edit gzdoom.pk3 directly...

(As an aside, EDGE has a very nice fuzz effect emulation based on using a "fuzz map" texture. If I knew a bit of OpenGL I'd try implementing something like that. From what I understand of the effect, I'd guess it uses the sprite's dimension and alpha map to cut out a part of said fuzz map and displays the result as a sprite? With some scrolling or animation done to the fuzz map itself so it's not static.)

Gez wrote:If you've installed ZDoom and GZDoom in separate directories, you can autoload different mods

Indeed I have, but I use ZDL 3.1a so no need for autoload anything that way.

Gez wrote:If it's just for you, you can as well edit gzdoom.pk3 directly...

Even more pointless. I always use the latest SVN build so editing the pk3 like everyday would be most inconvenient. Also, I heard Graf Zahl advising against modifying the pk3 as it would render any bug report or help advice completely useless.

I'll just stick to continue loading different wads, but I wonder if Randy would accept this as a valid feature request.

If you request such a feature it'd be closed on sight because it's against the philosophy of keeping things compatible. There's good reasons that a proper means to distinguish between ZDoom derived engines in user-made content was never made.

If I may interject - there's just some things that GZDoom's renderer handles better than ZDoom's - or in some cases - differently. Even in one Skulltag project that I'm on, there are often ACS checkers just for telling apart the renderer, because when mapped in one certain way something may look better than it does another way in OpenGL. The user would never be able to tell the difference except the classic "it's GL" or "it's software", but the differences are huge - the software versions stays within palette in a different way than the GL version does.

Also, there's a lot of tricks with portals - some only work on Software, some only work on GL.

You're gonna curse me forever for this post, Graf, but the fundamental differences just can't be ignored, and that's why we do things that way.

Telling which renderer is used is not the same as telling which port is used. You can perfectly play GZDoom in software. Let's say you don't like the look of OpenGL rendering, but you want to play a Legacy map (one which does not have 3D floors) that uses some FraggleScript, and you can't get Legacy to work on your computer because it's old and buggy. There's only one choice available: GZDoom.

(The example is kinda contrived, but it's to show you can find reasons to use GZDoom in software mode instead of ZDoom.) Likewise, there are several ZDoom-compatible ports with an OpenGL renderer.

So you can't rely on "it's GZDoom so it's OpenGL" or "it's not GZDoom so it's software".