GZDoom and Requiem

[printz]

Graf Zahl said:

At the moment, with Doom format maps, a subset of the portal features can be used with both engines, plus slopes, 3D midtextures and linked sectors.

Once Eternity supports UDMF the common subset will contain ACS and a mucgh larger number of action specials.

Shouldn't that be documented somewhere? I don't know which wiki is appropriate and where and how would be more sensible to write the guidelines.

[Gez]

As far as linedef types go, a good guidelines is to look at the Eternity xlat file in zdoom.pk3. It'll tell you straight away what Eternity linetypes are supported and what aren't.

Then there are things. Eternity's particle fountains are compatible with ZDoom's; as well as the polyobject starts. The ambient sounds (14000--14065 are also compatible.

There are, however, conflicts for sound sequences. ZDoom uses 1200 to 1209 for Heretic sound sequences, and a generic arg-based version at 14066, Eternity generalizes that to 1200-1299 + 1300 for arg-based version. ZDoom has 1400-1409 + 1411 for sound sequence overrider, 1411 being the arg-based one; Eternity uses 1400-1499+1500 instead. (The reason ZDoom skipped 1410 is that it's used by a Hexen thing).

To be perfectly honest, I expect the sound sequence overrides to fall in line with ZDoom's setup once Hexen support is finally added. There are six of the 1410 things right in Winnowing Hall (also five in MAP02, 4 in MAP08, and 2 in MAP13). It's not used a lot, but even one single use is enough to justify making it work. (And it's not like the 1410+ things have been used anywhere in an Eternity map.)

[hawkwind]

Vermil said:

So it does; I guess that shows up the other OpenGL ports.

Still doesn't play correctly though; like GZDoom, there are invisible barriers blocking the Chaingunners.

You're right. I've not noticed that before. I will report this. Thanks for mentioning.

UPDATE ... The next version of Risen3D, version 2.2.0.16 will emulate the doom2.exe behaviour.

[myk]

chungy said:
In seriousness, the fact that TNT2 is using weird kind of tricks to make vanilla Doom render levels in a certain way is actually worrisome.

Like I pointed out the last time this came up, it just narrows down to preference and audience aims. If you care more about port users, you won't use these hacks in a vanilla or limit removing map, judging each hack separately as not all work the same way in different ports. But if you really like vanilla intricacies and are mainly satisfied with the users of vanilla or its strongest emulators as a main player base, the hacks are game. DOSBox, Chocolate and PrBoom+ have made this latter option a solid one, so we don't need to feel humbled by more-modified port users.

It's not 2002 anymore and without this attitude all the ports wouldn't have even bothered to emulate vanilla well and the breach would have been even bigger, and the mutual intolerance worse: "Die, DOSBox freak!" "Ports must burn in hell!" But using these hacks today continues to encourage port authors to keep improving their engines in this department, is one of many options, and a sign that vanilla mapping continues to be healthy.

Gez said:
Hackless maps play well on all source ports.

That surmises it, and hacky ones utilize vanilla capabilities without restraint.

[Graf Zahl]

myk said:

That surmises it, and hacky ones utilize vanilla capabilities without restraint.

Hacks are not capabilities. They are abuses.
Regardless of how 'useful' some people may consider them.


In my opinion it shows a general problem in map making attitude, i.e. instead of 'let's make a good map' for some people it devolves into 'let's make a map with as many glitchy effects I manage to put in.'

I've rarely seen maps of this kind that play well unless the hacks were a one-time occurence and thus more or less pointless.

What's even worse is that I often get the impression that such mappers lack a fundamental understanding of how a glitch works and as a consequence often implement such things in a far worse and unstable fashion as necessary.

So, essentially, mappers that create glitch-maps sacrifice compatibility for some misunderstanding of 'coolness'.

[myk]

Graf Zahl said:
Hacks are not capabilities. They are abuses.

In my opinion it shows a general problem in map making attitude, i.e. instead of 'let's make a good map' for some people it devolves into 'let's make a map with as many glitchy effects I manage to put in.'

This is like those stereotypes about source port WADs where the mapper is accused of using features just to try to impress through the engine's "power" or simply due to an obsession with the features. It can happen on any platform but, unlike how the popular saying (or excuse) goes, it's the fault of the "player" and not the "game". As if vanilla mappers didn't have any tact or ability to discern where a particular hack looks good and where it looks bad. Yeah, hacks can look or work badly sometimes and many of us avoid them when they do, but that defect and the difficulty emulating them on some ports are different things. One hack could look perfect in vanilla and cause problems in some ports, another could look somewhat bad anywhere yet work practically anywhere. Personally I'm not a fan of slapping hacks everywhere, for reasons similar to why I'm not so hot for port features or even "detailing," but it depends on the planning, execution, design aims, time, and effort used.

[Graf Zahl]

myk said:

As if vanilla mappers didn't have any tact or ability to discern where a particular hack looks good and where it looks bad.

... and there lies the problem. There's 2 sorts of hacks:

Those which are relatively robust (self referencing sectors or using texture bleeding to cover holes, for example) - those rarely pose any problem because the reason they work depends on principles that are relatively well known. Of course, if a mapper doesn't know these principles inside out we may still get maps with mysterious holes that work with some ports and not with others.

But then there's the kind of hack where you look in disbelief at the map in an editor and ask yourself something like 'how the hell did they come up with this mess?' A good example for the second kind is the exit in Kama Sutra's MAP01. There's no fundamental principle in here, just some linedefs apparently thrown in at random until they sort-of produced the intended result - and of course it glitches like crazy if you look at it from the wrong place.

Requiem's MAP31 is somewhere in the middle, but closer to type 2. Besides, it's not even stable with software rendering. As soon as you start to look down with an engine that allows this all the hack's ugliness reveals itself.

[Phml]

This is like those stereotypes about source port WADs where the mapper is accused of using features just to try to impress through the engine's "power" or simply due to an obsession with the features.

Indeed, what Graf said is like those stereotypes in that both are often true.

Look at any famous wad using clever hacks and there'll be at least a few people praising it for the perceived technical achievement; however, finding players mentioning the gameplay aspect that particular hack improves if any? I can't say I have ever seen that - by which I mean it might well happen, but it's rare enough compared to the other attitude.

To claim vanilla mappers in general, which to me reads as "most people" of that particular group, have enough discernment to use hacks tastefully falls flat on its face when you consider the many examples of such tricks being done wrong, even in reknowed wads.

Bridges anyone? For some reason people seem to favor that horrid brown step texture, and the bridge itself often works in a clunky way if you're running fast, letting you fall down, infinitelytall monsters scratching you or being blocked by apparently nothing. Even in the Scythe series the bridges are hacky and don't always work as they should.

(That isn't to say hacks shouldn't be used. I just found that particular argument about mapper tact so directly opposed to my experience I had to react.)

[myk]

Keep in mind Kama Sutra was made by a pair of Compet~n speed runners (constant vanilla users) that didn't have any interest in ports back then. Perhaps there is some angle from where it will look bad even in vanilla, but nothing a speed runner would notice :p

Requiem's 31 really is of the experimental type, in the way KDiKDiZD will be the year it gets its Mordeth award. I think that Quake remake was a good idea as a secret but would have felt out of place as a normal level both for the theme and the amount of hacks.

As a mapper I generally don't like vanilla bridges too much because I value coop a lot, although to be honest I mostly haven't had too many problems with them, even though I'm aware they can break if lines fail to trigger while strafe running or the like.

[Graf Zahl]

Phml said:

(That isn't to say hacks shouldn't be used. I just found that particular argument about mapper tact so directly opposed to my experience I had to react.)

Indeed. Often people know the hacks but don't know anything about what makes them tick. The result is inevitably something that's easily broken - and that even happens in maps by the top mappers.

So, for example, self-referencing sectors again. Far too often mappers seem to rely on the node builder to get them to do what they want because they have no clue how to use them properly. The thing is, if you know how they work they can be made 100% robust - no holes and all. Still we get mods like Kama Sutra which break apart if the maps are subjected to another node build - which some engines unfortunately still do - even for pure gameplay related use of the BSP.

Stuff like this is the reason why GZDoom always keeps the original nodes from the map to be used for determining position by the play simulation, even though they are useless for the GL renderer.

[The Ultimate DooMer]

myk said:

This is like those stereotypes about source port WADs where the mapper is accused of using features just to try to impress through the engine's "power" or simply due to an obsession with the features.

That's what I've always said. Vanilla/Boom mappers can be just as guilty of focusing on fancy stuff (engine hacks, 10000 sectors of detail etc.) instead of the basics, funny how it never gets brought up very often...

[esselfortium]

The Ultimate DooMer said:

That's what I've always said. Vanilla/Boom mappers can be just as guilty of focusing on fancy stuff (engine hacks, 10000 sectors of detail etc.) instead of the basics, funny how it never gets brought up very often...

Overdetailing rarely ever gets complained about? Huh.

[Lars]

Vermil said:

While it isn't a showstopper, the area doesn't work correctly in GZDoom (tested in the new release); there are invisible barriers in front of the Chaingunners in GZDoom, that aren't there in Vanilla.

Makes grabbing the blue armour much easier (i.e as you aren't under fire).

Graf Zahl said:

That map needs a compatibility option. Will be changed in ZDoom ASAP.

Hi,

is the compatibility option needed for this map already built into ZDoom/GZDoom or does it need to be programmed yet? Because even with all compatibility options enabled in the menu I cannot get the chaingunner trap to work correctly. The invisible wall is always there. (Tested with ZDoom 2.6.0 and GZDoom 1.6.0)

Funny thing, the trap seems to be broken already in all YouTube gameplay videos of that map. It is however working "correctly" in ZDoom 1.22.

Lars

[Gez]

Lars said:

is the compatibility option needed for this map already built into ZDoom/GZDoom or does it need to be programmed yet?

It's this one.

[Lars]

Gez said:

It's this one.

Well, enabling that option does not fix the problem (at least on my system). Any ideas?

[Graf Zahl]

If that doesn't help - nothing will.

That's the not so nice side of gross hacks: They tend to screw up a map's physics - particularly if you use code that's not as shitty as the one Doom originally used. ZDoom's hitscan code is a lot more thorough - but in this particular case it works against the hack in this map.

[Lars]

Graf Zahl said:

That's the not so nice side of gross hacks: They tend to screw up a map's physics - particularly if you use code that's not as shitty as the one Doom originally used. ZDoom's hitscan code is a lot more thorough - but in this particular case it works against the hack in this map.

I can certainly live with it. :-) Just thought I was perhaps missing something which could make it work.