Common features for ZDoom and Eternity

[Hell Theatre]

I've been thinking about making a map that works on both these ports.
From what I could gather there seems to be some good overlap of supported features.
What I cannot find, however, is some comprehensive list of these mapping features.
Has anything like that ever been compiled?

[Gez]

Common mapping features:

• Polyobjects
  
• Attached sectors (aka linked sectors)
  
• Slopes, at least decorative ones (not sure EE handles slope physics)
  
• Portals, with some caveats as well
  
• 3D middle textures
  
• Using flats and wall textures interchangeably (flats on a wall, walls on a flat).
  
• PNG graphics for textures
  
• A lot of ACS stuff, with the caveat of not having Hexen/UDMF map finalized in EE, so you have to cheat
  
• Content definition languages allowing custom monsters and decorations, but you'll have to duplicate the code since DECORATE and EDF are different
  
• MAPINFO, but again, in different formats.
  

[Graf Zahl]

Gez said:

Common mapping features:

Slopes, at least decorative ones (not sure EE handles slope physics)

Eternity's slopes are indeed decorative. There is no slope math at all in the game code.

Portals, with some caveats as well

It should be noted that GZDoom's OpenGL renderer has far better portal support and no problems with complex constructs.

A lot of ACS stuff, with the caveat of not having Hexen/UDMF map finalized in EE, so you have to cheat

It's not that bad. ZDoom allows loading a map-specific ACS lump through MAPINFO, just like Eternity.

Content definition languages allowing custom monsters and decorations, but you'll have to duplicate the code since DECORATE and EDF are different

MAPINFO, but again, in different formats.

That's indeed the spots where you have to duplicate your work. Same for terrain definitions, sounds and a few other things.

It should also be noted that in order to make good use of common features an Extradata lump is unavoidable. With the exception of the colormap feature for sectors, ZDoom supports all features that get exposed here.

[chungy]

Eternity has a (slow-moving) goal to be compatible with ZDoom anyway. It's probably best to just make your map for ZDoom and not worry about Eternity.

[Graf Zahl]

Now, I wonder what Quasar has to say about THAT kind of advice!

This is the stuff that keeps stopping Eternity cold in its tracks.

[printz]

Graf Zahl said:

This is the stuff that keeps stopping Eternity cold in its tracks.

Reasons I've slowed down developing Eternity:

0. other things to spend my time on. Including other projects which are all mine, no team or community syncing required.

1. demo compatibility is time consuming both to test and to hunt for bugs. It's the kind of stuff that keeps me awake at night because I lose track otherwise. Like I said on chat, it's like ball and chains. Everything I add to the main releases has to be run through hundreds of demos and validated before uploading.

2. maintaining compatibility with true Hexen gameplay and with ZDoom mapping interface is less than exciting. Also makes me feel like I'm not innovating anything. But in truth I can't escape it, because reinventing the wheel for well-established features isn't good either.

3. for any cool new features I should implement UDMF, but the prerequisite for that is point (2.)

If it were my own personal project, I'd care much less about ZDoom compatibility. I'd probably be leaner with it, other than demo compatibility still being important. I'd make my own quick UDMF implementation and supply users with already-made GZDoomBuilder/SLADE/Eureka configurations, so they can start mapping quickly enough. Saying this makes me want to do exactly that, but it would be a failure on my team working skills, isolating myself like that.

[Li'l devil]

Hell Theatre said:

I've been thinking about making a map that works on both these ports.

Nobody uses Eternity, so just make a regular ZDoom map.

[Coraline]

ChekaAgent said:

Nobody uses Eternity

Wow...

[Hell Theatre]

Wow, I wouldn't have expected such a response...

Yes, I understand that Eternity has some problems gaining traction, that was one of the reasons why I was asking - to give it some momentum by making a cross-port map that actually does more than just Boom stuff. I like that port but as things are right now I see that it needs any help it can get.

What worries me most reading post like Printz's is that demo compatibility focus that seems to be the main driving point here.

While I understand on one hand that it is a good meter for keeping gameplay compatible I also see it as the one major roadblock for advancing the engine - especially when the ultimate design is to support 3 or 4 different games with all their features and idiosyncracies. This either needs some massive redundancy or compromises.

The ultimate question is, is demo compatibility really that important? Although I use Eternity for playing regularly, i almost never use it to play back demos, for that PrBoom+ is clearly the better engine. As a selling point it is clearly not working and I have the feeling that in some ways it is the thing that has held Eternity back more than any other thing.

[Graf Zahl]

printz said:

Reasons I've slowed down developing Eternity:

No need for justification. I wasn't talking about developer side but the problems that seem to exist finding a user base. And the lack of maps is clearly one of the reasons - and then seeing people give advice to switch to another port is the least thing I'd want to hear.

I also had my downtime periods on ZDoom, if you check the changelogs you might notice that from mid 2012-mid 2013 I haven't done much at all. That's perfectly normal.

[Li'l devil]

Ok, can someone here tell me what features Eternity has, that other ports don't? Maybe I'm missing something. I always thought that Eternity is an obsolete port.

[Jon]

ChekaAgent said:

Nobody uses Eternity, so just make a regular ZDoom map.

ChekaAgent said:

Ok, can someone here tell me what features Eternity has, that other ports don't? Maybe I'm missing something. I always thought that Eternity is an obsolete port.

Suggestion: if you do not use Eternity, stay away from Eternity threads. If you want to learn about Eternity, The wiki, as always, is a good starting point.

Hell Theatre said:

While I understand on one hand that it is a good meter for keeping gameplay compatible I also see it as the one major roadblock for advancing the engine - especially when the ultimate design is to support 3 or 4 different games with all their features and idiosyncracies. This either needs some massive redundancy or compromises.

If the game support was really partitioned, I'd be tempted to suggest that "classic"/demo-compat Doom and "modern-features" doom were considered entirely separate. That way one wouldn't hold back the other.

The ultimate question is, is demo compatibility really that important? Although I use Eternity for playing regularly, i almost never use it to play back demos, for that PrBoom+ is clearly the better engine. As a selling point it is clearly not working and I have the feeling that in some ways it is the thing that has held Eternity back more than any other thing.

I think this is a good question and I would have the same concerns.

[Graf Zahl]

@ChekaAgent:
Play Vaporware and you'll know.

[printz]

Hell Theatre said:

The ultimate question is, is demo compatibility really that important? Although I use Eternity for playing regularly, i almost never use it to play back demos, for that PrBoom+ is clearly the better engine. As a selling point it is clearly not working and I have the feeling that in some ways it is the thing that has held Eternity back more than any other thing.

Ideally for me, everything that PrBoom+ can run should be playable by Eternity. For example I want to add support for tricks such as "linguortals" (vanilla Doom displaced seg holographic illusions) by merely copying the way PrBoom+ or Chocolate Doom emulate them. There are a few dumber tricks which are harder to emulate and whose use is questionable however, such as the all-ghosts bug. Can you still exit a level if you're affected by that bug? Assume I'm not using E1M8-style exits...

[HavoX]

ChekaAgent said:

Nobody uses Eternity

[citation needed]

[Li'l devil]

Ohhh.. I don't know why I said that. I guess, sometimes I just want to post some shit without thinking. And now everybody's gonna quote that..

[plums]

printz, is Eternity demo-stable for demos that allow jumping? That's something that's been on my mind lately, for whatever reason. I'm not aware of any other ports that are.

[Da Werecat]

I think the importance of compatibility is a valid question. Do you really need another PrBoom+ embedded in Eternity? Is it worth the effort of maintaining a codebase full of compatibility branching? Maintaining demo compatibility with Eternity itself must be inconvenient enough.

Unification with ZDoom also seems to be a double-edged sword. On one hand, Eternity will have more wads to run - more reasons to try it. On the other hand, it will have less exclusives - more reasons to stick with ZDoom.

[Danfun64]

I still want this to happen after Eternity reaches its next stable release. Also, I would love to see Eternity with PrBoom-Plus demo and compatibility features and Chocolate/Crispy Doom's netcode.

[plums]

Danfun64 said:

I still want this to happen after Eternity reaches its next stable release.

Well that answers my question, thanks.

[printz]

Danfun64 said:

I still want this to happen after Eternity reaches its next stable release. Also, I would love to see Eternity with PrBoom-Plus demo and compatibility features and Chocolate/Crispy Doom's netcode.

That was an idea. Now that I've complained about merely vanilla/Boom/MBF demo support, I'm not sure I'd want to deal with that. It would require draconian quality control.

[Danfun64]

In other words, you think implementing Eternity Engine demo compatibility with itself is an Awesome but Impractical idea.

Thus is the state of Doom Source Ports, where nothing after Boom (except maybe MBF) is considered a true standard. ZDoom 1.23 could have been a standard, and maybe one day will if Kilgore gives the ZDaemon port to somebody else who is willing to make it GPL open source and merge it with Odamex.

In a way I envy how the Quake series has standards (Quake (1) has Netquake, Quakeworld, and Darkplaces, Quake 2 and games made afterwards only have one protocol). It's a pity that (Darkplaces exclusive standalone mods notwithstanding) Quake has a map format where textures are baked in and can't be replaced in vanilla without changing the map itself, Quake 2 (and Wolf ET, ROTW, and Doom 3...Doom 3 BFG?) has(/have) horrible multiplatform support due the dll system they use, Quake 3's VM uses a non-free compiler and the game itself has no SP campaign, etc.

[Graf Zahl]

Danfun64 said:

In other words, you think implementing Eternity Engine demo compatibility with itself is an Awesome but Impractical idea.

To be honest, that's where I place the combination of demo compatibility with advanced editing features. Demo compatibility, by necessity, requires a strict enforcement of a rigid engine design, but new features normally require a decent amount of flexibility, the ability to refactor and change. These two things will constantly be at odds with each other and stand in each other's way.

Just a simple example: Portal support normally requires that there is no possibility to skip a linedef when moving around, otherwise you may miss the portal. Demo compatibility, on the other hand, requires that all the idiosyncracies of Doom's sloppy movement code are perfectly preserved, and that includes the gross oversights in determining move step size for high speeds (and of which wallrunning is a consequence.)
So in order to counter this, there's three options: Either fix the design, thereby breaking demo compatibility, add a crutch to work around the problem or just replicate the entire set of broken code and use the version that'd best suitable. So, the first one will provide a clean but demo-incompatible code base, the second one will add more convolution to a code base that's already far too convoluted and the third one will add a massive amount of redundancy that needs to be maintained.
And so it goes for other advanced features as well - as a more invasive thing, slope physics will be the ultimate nightmare for a demo compatible engine.

Danfun64 said:

ZDoom 1.23 could have been a standard, and maybe one day will if Kilgore gives the ZDaemon port to somebody else who is willing to make it GPL open source and merge it with Odamex.

ZDoom 1.23 won't be a good standard. If you really want a decent ZDoom-based standard, it should be 2.0.63a minus DECORATE. By that time most of the 1.23 bugs had been fixed and the engine was in an overall far more stable state.

[Hell Theatre]

Thanks everybody for all the info.

I started experimenting with some more advanced features, trying to remain compatible.

But I think I now know why Eternity is not gaining much popularity. It all boils down to one simple but disappointing fact:

Mapping with Extradata is an utter chore, it is no fun at all. Stuff won't show up in the editor, you always have to edit a text file by hand and won't get any visual feedback. Only if you start the map for testing it will become visible.

So to avoid the stress this induces I decided to go for GZDoom now. It also got great portal support but all the rest can be done through a native map format that the editor can fully handle. I am really amazed how well GZDoom Builder supports all these extensions.

So to sum all up, here's some advice for the Eternity team:

All the features you got, all the great engine underneath, is nearly useless without good editor support. As such I strongly suggest for the time being, stop focussing on other things, like the recently announced Aeon support and make sure that the UDMF implementation is completed, by that I mean good support of as many of Hexen's and ZDoom's linedef actions as possible and a decent specification of engine-specific extensions. I believe that once this is out, the maps will come nearly automatically.

All the rest is just window-dressing if mapping for this engine involves such a messy kludge like Extradata and I wonder how many mappers before me were turned off by this.

Out of curiosity: Why did ZDoom even add support for that, it doesn't look like anything of genuine value for an engine that already has fully functional UDMF support.

[Graf Zahl]

Hell Theatre said:

Out of curiosity: Why did ZDoom even add support for that, it doesn't look like anything of genuine value for an engine that already has fully functional UDMF support.

Actually, the only reason was to get some access to a realistic map that was using linked portals. Of course, while at it, I made sure it wasn't just a means to an end but fully working to the extent that was possible.

[printz]

Just discovered that on Mac, if I apply compiler optimizations higher than a certain level, but still below the recommended default, many demos will desync! I know what I'm supposed to do: hunt down the cause and patch it. I assume it's some undefined behavior that's stable on Windows.

While I hate to complain and I almost never do it, I can consider that there are better uses of my time than maintaining a demo-syncing system for which I have minimal audience other than 2-3 guys who probably care more about features and common ZDoom stuff. But what would Eternity be without demo playback? Just a ZDoom retry and alternative. Hell, just remove playback (including the iconic Doom startup demos -- never liked how other ports just cycle the title screens without demos) altogether while at it.

It's all a fine task of keeping balance while adding all kinds of game and platform support, but I think it's a bit like bottle ship building, right? Just call it Bottle Doom.

[Graf Zahl]

printz said:

Hell, just remove playback (including the iconic Doom startup demos -- never liked how other ports just cycle the title screens without demos) altogether while at it.

That just shows how different tastes can be. I'm glad that ZDoom doesn't torture me with these demos. :D

[Hell Theatre]

printz said:

But what would Eternity be without demo playback?

I think that's the important question here. But try to see it from the outside.

Going back in history, I see it was 8(!) years ago that Quasar of all people started the UDMF discussion. And after the spec was out, what happened?
Graf Zahl took the specification and churned out a working implementation in less than a week! Eternity? No such luck. Its users had to wait a virtual Eternity and it's still not really in a releasable state, because it is missing one crucial bit: Support of Hexen-style linedef types.

I'm sorry, but if the developers show such an attitude, the question, what the port wants to be, becomes irrelevant. If you have a good feature, see it through, make sure it's complete and without major problems, and then go on to the next thing.

Not starting A, starting B, letting A rot before taking up work again, and then, luckily have a new developer come in and finish it 10 years later (Thanks to you Printz, btw, for finally tackling it...) and then maybe think about B again, but not before wasting some time on C or D.

I had my fun studying the changelogs of Eternity and ZDoom, and the most crucial difference I see is that in ZDoom it very rarely happens that a feature gets half implemented, and then forgotten - and in the few times it happened there were profound reasons for abandoning it but looking at a selection of examples:

• 3D floors were in the mainline, ready to use, 6 weeks after the initial submission
  
• Voxels took 10 weeks from the first commit to being ready. And GZDoom was almost as fast.
  
• The menu rewrite which looks like one of the most intense pieces of refactoring took less than a month!
  

So, it basically never happened that some interesting stuff was teased about, but then development came to a standstill for years to come, while developers were busy with less pressing features.

But with Eternity:

• Portals were started more than 10 years ago and never managed to get to a finished state until very recently.
  
• UDMF was announced 'soon to come'. Too bad that 'soon' amounted to 8 years.
  
• Hexen line action support seems to be on/off and apparently be put repeatedly on the shelf.
  
• Announcements about new features (e.g. Aeon) are being made, before the far more urgent stuff is moved out of the way.
  

So what does Eternity want to be?
Seriously, it'd be some huge progress if that running joke of being eternally late no longer applies! That name with the abovementioned development strategy is just an open invitation for some bad wordplay and that stuff tends to stick.

So demo compatiblity or not? It's either "That other port like PrBoom" or "That other port like ZDoom". Where's Eternity's own identity? It even got its #1 place in best portal support taken away by GZDoom now!

For the other popular ports it is easier:
ZDoom clearly is about being the most feature-rich port for mapping.
PrBoom is clearly is about being the ultimate port for demo playback.
Doomsday is clearly about providing some visual enhancements to the stock maps.

But in both categories it competes in, Eternity is just second place, due to its features it can't be optimized for demo playback as aggressively, and due to demo concerns it can't be aggressively optimized for new features. Both halves will constantly stand in each other's way.

If you ask me, the only place where it could thrive is to have good editing features, preferably compatible with ZDoom to the maximum degree possible, and then focus on good demo compatibility with itself, but not getting hung up on all the minute details that are required for vanilla demo playback. Imagine that: Here's some random ZDoom map, but if you want to watch the demo, get Eternity first. Of course that won't happen because nearly everything between both ports is incompatible, all definition files would have to be duplicated, so the engine is already out of the picture.

[Graf Zahl]

Hell Theatre said:

• 3D floors were in the mainline, ready to use, 6 weeks after the initial submission
  
• Voxels took 10 weeks from the first commit to being ready. And GZDoom was almost as fast.
  
• The menu rewrite which looks like one of the most intense pieces of refactoring took less than a month!
  

... and the scripting branch has been in work for 8 years on and off, on and off, and earlier this year was finally ready for the DECORATE related stuff, not even the actual scripting language.

Also don't forget the tagline "Wait for Doomscript!" This dates back 17 years, btw. ;)

So, even ZDoom got some features that seemed to take forever. Don't forget that these are still mostly hobby projects. We developers got to deal with real life as well.

But in the case of UDMF I have to agree. Sitting that one out for year after year while working on far less important things has hurt Eternity incredibly.

[Gez]

A large part of why ZDoom could afford to wait for Doomscript for 17 years is that
1. It's not really important: most maps made don't have any script at all after all.
2. ZDoom had ACS and then DECORATE and extended them so much that Doomscript is largely redundant. It could certainly be a better, cleaner alternative with less bloat and old compatibility cruft; but people have been able to recreate Mortal Kombat and Donkey Kong in ZDoom with what's already there.

So what does that say for Eternity? As nice as Aeon promises to be, it's not a real priority. The priority should be for UDMF and Hexen format support first, then support for non-Doom games (mostly Heretic, Hexen, and Strife) second, and then you can put Aeon at the third place.


As a side-note, the original plan for DoomScript was basically DECORATE as an UnrealScript dialect, needing to be compiled externally. I don't know about you, but I'm glad that the DoomScript from 1999 actually never came to be. :D