Reasons for success or failure of source ports?

Voros said:

ZDoom, and it's forks. How did it become so popular?

A large dose of luck. And I don't mean that in a condescending way.

All you really need is momentum. Enough people who use your port and who mod for it, generating interest. Including from tool makers, who go and introduce eg. Doom Builder support specifically for your port. And this pool of people holds your knowledge base for newbies' editing questions, and generate mods that serve as inspiration for others.

At crucial times, ZDoom happened to introduce features that attracted players. If you remember, one of the early ZDoom WAD waves to hit /idgames were basically vanilla levels with some particle fountains thrown in. People *loved* their particle fountains. For features the developers took stuff that they saw was popular elsewhere in other games, as opposed to other most ports post-Boom which were created with some specific goals in mind. Also helpful is that the ZDoom developers did not wait until such a feature was 100% complete but introduced it at, say, 80% usefulness and worried about completing / fixing it later.

Once you get enough people playing and modding it will generate its own feedback loop to sustain and grow interest. Now the only thing you need to do is not fuck up (by eg. developer quarrels) and bingo: community standard port.

There could be an absolute KILLER source port released tomorrow but that would not be enough to 'steal' (G)ZDoom's place. Because people would have to learn how to edit for it, without custom tools, without support from a community, with no help, without knowing if people would actually be interested in playing their mod, without anything to play that shows off this killer port's features.

Voros said:

On topic, why don't we analysis a very good example: ZDoom, and it's forks. How did it become so popular?

15 years ago things were a lot different. People were eager to try out new and different stuff in Doom maps, and ZDoom delivered on that account with an actually working non-broken scripting language, the ability to create hub-based gameplay and a few other things, years before DECORATE became a thing.

That attracted lots of mappers back then, it also attracted programmers like myself to contribute and make it better.

And of course we should not forget how the actual competition for feature-driven ports basically subtracted itself from the playing field.

Back in 2002 Doom Legacy had 50000 downloads per month, i.e. it was massively popular, with far higher download numbers than even GZDoom manages today. But something went badly wrong after that high point. Instead of gradually fixing the engine, the devs got caught up in a total engine rewrite that never fully materialized, so the official release remained very, very broken. As a result the interest among mappers declined and the download numbers tanked. One should have thought that after a mod like Nimrod, interest in the engine would rise, yet it only highlighted the frustration of having to play this thing with an engine that was simply too messed up for good. And the second big Legacy mod - High Tech Hell 2 even more showed the broken-ness, it could crash the engine like crazy if you just looked at it from the wrong angle.

In short: Of the three early ports which focussed on features, it simply brought the best experience for mappers and that automatically brought the players.

Mordeth said:

If you remember, one of the early ZDoom WAD waves to hit /idgames were basically vanilla levels with some particle fountains thrown in. People *loved* their particle fountains.

I must have missed that phase, actually. The first ZDoom mods I remember were the early ones that started to use ACS. If this is really true, all I can say is - strange how some seemingly inconsequential things can affect a product.

Graf Zahl said:

I must have missed that phase, actually.

People at the time were complaining about it. Like, why claim this level is 'zdoom only' if the only thing that makes it non-vanilla are those two green particle fountains in your nukage pool?

Where did you get those download numbers from, anyway? Also I'm not gonna give up just because I lack numbers. I might have hinted to that in the past, but that's just because I had to go through a boring phase in the development.

Graf Zahl said:

years before DECORATE became a thing.

It's precisely that moment that made me switch to MBF, and then stick to Eternity. Probably one from a handful users. I really liked the more powerful Dehacked it provided back then. Artica4.wad also looked impressive and inspirational.

I've always thought that the whole particle fountain thing was just an exaggerated joke example.

printz said:

Where did you get those download numbers from, anyway?

Those are from Sourceforge which keeps download statistics for all its projects. I wish Github did that, too...

Graf Zahl said:

Back in 2002 Doom Legacy had 50000 downloads per month, i.e. it was massively popular, with far higher download numbers than even GZDoom manages today. But something went badly wrong after that high point. Instead of gradually fixing the engine, the devs got caught up in a total engine rewrite that never fully materialized, so the official release remained very, very broken. As a result the interest among mappers declined and the download numbers tanked. One should have thought that after a mod like Nimrod, interest in the engine would rise, yet it only highlighted the frustration of having to play this thing with an engine that was simply too messed up for good. And the second big Legacy mod - High Tech Hell 2 even more showed the broken-ness, it could crash the engine like crazy if you just looked at it from the wrong angle.

I was using Doom Legacy in early 2000s after I found Doomworld and starting playing PWADs, but after late 2000s, I noticed new PWADs in Legacy had serious problems about missing/bad textures due to its buggy node builder, and even used other node builders to manual rebuild nodes didn't worked well so I decided try and switch to ZDooM/GZDooM(I already interested at that time) and I'm happy I did. Shame the Legacy seems better now but I already stuck at GZDooM and unless something needed Legacy only or I won't try it again I guess... :(

Hell Theatre said:

The more I think about it, the more I believe that the reason is very simple:

ZDoom was a port that dared to break barriers. While the rest of the community was focussed on demo compatibility like a hypnotized rabbit - thereby bringing actual progress in other areas to a virtual standstill - or even in non-demo-compatible ports an unhealthy focus of "we must preserve every vanilla glitch as closely as possible - other things are secondary", ZDoom was basically the only port that went ahead and fixed many of these glitches - some small and some with such a big impact on how the game feels that it's hard to switch back, once you take the increased robustness for granted. One particular issue that's important to me is the sliding against blocking two-sided walls, which was overlooked in Doom.exe, but to my knowledge, ZDoom is the only engine which ever fixed this. For all others it was like "demo compatibility and 100% reproduction of vanilla behavior is more important".

So from an outsider's standpoint, ZDoom just handles a lot better than all these 'compatible' engines combined, and once you add its editing capabilities to the picture you get a winner, all it needed to take off into space was that one mod that would draw in even non-Doomers, and it got that with Brutal Doom and its offspring.

This is a very biased, and flat-out incorrect portrait of the history. "Back in the day", ZDoom was grabbing code from other ports, just like anyone else. Many of those "broken barriers" were conceived in different ports. "Hypnotized rabbit?" Just to mention a few: Boom and MBF, brought massive stability, scores of new linedefs, and new abilities. Legacy brought 3d floors, split-screen, colored sectors, GL rendering (as did others), and much more. Edge and Doomsday brought tons of advanced features, advanced rendering. SMMU, and then Eternity brought advanced game setup scripting, and handfuls of various features. And then there's FraggleScript - a massively-complex undertaking. ZDoom had its lion's share of contributions too. But it was, by no means, on it's own forging ahead, while everyone else was "hypnotized with demo compatibility".

Both new editing features and demo compatibility are quite possible, it's just that ZDoom "took the easy way out", and tossed the concept of demo compatibility, which, for years, make it feel very un-Doom-like. Graf can be credited for working some compatibility back into ZDoom, though I think he would have rather been doing something else for ZDoom. (Note: I do not mean for this to be a slight against ZDoom. That was the vision of ZDoom's devs, and it was executed quite admirably).

Get your history straight before you go off all half-cocked and throw every other port under the bus.

Factors that contribute to ZDoom's popularity are:
1. A large, strong forum, which equates to a large web presence.
2. Relatively solid, capable port
3. ZDoom devs have traditionally catered to map author's desires via requests on the forum, whereas other port devs have concentrated on their own features and desires.
4. As Mordeth eloquently stated, luck was a factor as well, way back when.

When someone researches Doom on the web, they find ZDoom at the top of the page. So, port popularity promotes more popularity. Nothing wrong with that.

Also, 12,000 downloads is nothing to shake a stick at. And neither is 30 downloads per week. Some of that is a product of how many revisions are released, especially if map authors are using bleeding edge features of a port. Some ports are nearly feature-complete, in the eyes of the developers, and only bug fixes are released.

All ports have a place on my hard drive, as all ports encapsulate a particular developer's vision. One of those developers was id Software. Mocking demo compatibility is mocking id Software's creation, cause the only scientific way to strictly emulate that exact vanilla experience is through strict demo compatibility. Some of us believe that the vanilla feel is a good thing...a requirement, in fact. Getting compilable source code that properly emulates original Doom is an accomplishment. Other things are secondary to some of us.

kb1 said:

All ports have a place on my hard drive, as all ports encapsulate a particular developer's vision. One of those developers was id Software. Mocking demo compatibility is mocking id Software's creation, cause the only scientific way to strictly emulate that exact vanilla experience is through strict demo compatibility. Some of us believe that the vanilla feel is a good thing...a requirement, in fact. Getting compilable source code that properly emulates original Doom is an accomplishment. Other things are secondary to some of us.

Id Software did not care as much about demo compatibility as you do. They happily updated their engine several times without any care about the ensuing desyncs, thinking it simpler to just re-record the demos for the title loop rather than bother with putting versioning and branching in the gameplay. Did they mock themselves by doing so?

Gez said:

Id Software did not care as much about demo compatibility as you do. They happily updated their engine several times without any care about the ensuing desyncs, thinking it simpler to just re-record the demos for the title loop rather than bother with putting versioning and branching in the gameplay. Did they mock themselves by doing so?

Yeah, they dropped the ball a little bit. Not sure why you've asked this - you're smart enough and knowledegable enough to make as good of guesses as I am. Is this a sarcastic question? Are you being serious?

For benefit of the doubt's sake, I'll give it a shot:

If I were tasked with bringing Doom up to version 1.9, I might justify breaking demos with these points:
. There were only so many demos to be broken at that time. It probably wasn't known how big the demo scene would become, and how important it was to maintain demo sync.
. It was more important to fix the bugs quickly, so demos from that point could be consistent.
. Carmack was under pressure to start Quake, and to port Doom to other systems.
. Demo reliability was always in flux while Doom was being developed. Maybe they just forgot to go back and fix it.

. On the minimum spec PCs Doom was targeting, compatibility code took extra memory space they couldn't afford.
. The demo version number wasn't even added until Doom 1.4, I think. Demo support in multiplayer was still being ironed-out. It was in its infancy.
. The "Doom feel" we all (most of us) know and love was still being created and tweaked.

It is feasible to be concerned with compatibility at this stage, but at the beginning, id would have had to keep around a lot of older code to support the relatively small number of demos that had been built up to that point.

And, don't forget: Carmack grabbed PrBoom for his modern phone port of Doom, which had some good demo support. Maybe that influenced his decision (along with dozens of other things, I'm sure.)

Please ZDoomers: No need to get defensive when someone discusses the importance of vanilla demo compatibility. It was made clear, very early on, that ZDoom was ditching the prospect of demo compatibility, to tighten up Doom's calculations, and to ease the ability to add new features. That's why you fork source code - to make your own version that does what you want it to do - nothing wrong with that. Obviously, lots of people appreciate that approach. No one's dissing your precious, man!

Going to put this out there, but Vanilla Doom and Linux Doom 1.10 has code to refuse to play a demo from an older version with the message "Demo is from a different game version!". So making demos compatible was avoided by just refusing to play those demos.

kb1 said:

Please ZDoomers: No need to get defensive when someone discusses the importance of vanilla demo compatibility. It was made clear, very early on, that ZDoom was ditching the prospect of demo compatibility, to tighten up Doom's calculations, and to ease the ability to add new features. That's why you fork source code - to make your own version that does what you want it to do - nothing wrong with that. Obviously, lots of people appreciate that approach. No one's dissing your precious, man!

Your passive-aggressive stabs at ZDoom are getting really tiresome. It isn't us that keeps making statements like "ZDoom isn't really Doom anymore" or constantly stating that a true Doom port must have demo compatibility. Not to mention the constant tale about how we are the aggressors.

Voros said:

Checking out the DoomWiki page, it mentions it has true-color renderering, which surprised me. Did Delphi do it first before QZDoom?

DelphiDoom was the first source port to implement a true color software rendering. This was back in 2007 (doomworld thread is https://www.doomworld.com/vb/source-ports/40463-32-bit-software-renderer/)

At that time maybe the hardware was not ready for that, since a decent machine of that era like a Pentium 4 was struggling to even reach the 35 FPS of the build-in TICRATE at 1024x768 resulution. This was probably the reason that DelphiDoom didn't succeded to gain popularity. I had to wait 4 - 5 years for multi core systems to become widely available to implement multithreading and make the renderer fast. Today even with a slow mobile Celeron can perform decently. FullHD resolution with external textures requires a corei3/corei5 class PC though.

Another true color port followed in 2011 (_bruce_ 's port) https://www.doomworld.com/vb/source-ports/57202-doom-in-true-colour-testers-for-exe-welcome-src-snapshot-links-updated/. Unfortunatelly there weren't any downloads available last time I've checked.

Mocha Doom added true color at 2012,
https://www.doomworld.com/vb/source-ports/62142-mocha-doom-v1-6-released-fullscreen-truecolor-n-stuff/.

kb1 said:

Other things are secondary to some of us.

Indeed, and that goes both ways. The real question is, in what direction it goes stronger?

While I certainly do not agree with Hell Theatre's wording of the issue, he got one thing right: There's many people who simply do not care about this thing, they never play demos, or if they do, just use another port.

I'm sorry to break the news to you, but in the larger picture, demo compatibility is a total geek feature. It requires a degree of dedication to the issue that goes way beyond what normally happens in software development. Software development at large is all about improving one's product in the most efficient way possible, to add new features to get more sales (or downloads.)
Demo compatibility is an entirely different beast. Essentially it's conservatism taken to the extreme. Depending on what you want to get out of your engine it's either prohibitive to keep or extremely limiting in what else you can do. For a purely COMMERCIAL product the investment of time and work into such a thing is simply not economic, it brings no revenue - it only takes resources away from more important things.

kb1 said:

Yeah, they dropped the ball a little bit. Not sure why you've asked this - you're smart enough and knowledegable enough to make as good of guesses as I am. Is this a sarcastic question? Are you being serious?

It's called a rhetorical question. And yes I'm serious.

The demo system is just a bonus from the netcode. What was important for Id Software was that netgames and demos don't desync within one given version, compatibility between different versions was never thought about, besides a basic versioning and error message they added after v1.2.

The ability of keeping sync with demos of different versions of the program is a feature that was never present in vanilla Doom. It's an advanced port feature; just like 3D floors or sloped surfaces or whatever.

It is certainly nifty that a port such as PrBoom+ can handle demos from any version of the official doom.exe as well as a handful of early ports. It's handy to have a single program that can play back most demos in existence, and it's certainly a worthwhile goal.

But it's not necessary or a requirement. It's an added extra feature that is cool in its own right, but that wasn't part of doom.exe. Claiming that demo compatibility is a requirement makes to me about as much sense as claiming that 3D floors and slopes are a requirement.

Id software didn't try to maintain backward demo compatibility while fixing bugs and adding new features when they updated Doom from 0.99 to 1.9. (And I'll point out that there are three different versions numbered 1.9, which aren't fully demo compatible between each other because of slight differences in lost soul and teleporter behaviors.) From a technical point of view, source ports are further iterations of the original doom.exe, since what did they do but fix bugs and add new features, exactly like id themselves did?

And from that point of view I'll quote The Man himself:

John Carmack said:

Some project ideas:

Port it to your favorite operating system.

Add some rendering features -- transparency, look up / down, slopes,
etc.

Add some game features -- weapons, jumping, ducking, flying, etc.

Create a packet server based internet game.

Create a client / server based internet game.

Do a 3D accelerated version.

I think this list shows how further versions of Doom would have ended up looking if id didn't move on to Quake instead, because that's the stuff Carmack was thinking about. Some of these features (transparency, looking up and down, jumping and flying) had at that time already been added to the Doom engine in Heretic, Hexen, and Strife, so it would have made sense to backport them to Doom in a highly hypothetical "Doom III" in classic Doom engine.

Graf Zahl: You're exaggerating, actually. Vanilla Doom, Boom and MBF demo compatibility can be kept in check, by simply reducing all new features to their vanilla Doom base when they're missing. I had zero trouble with demo compatibility when I made linked portals work, though of course I was helped by Quasar having already copied a lot of code from ZDoom for the 3D clipping movement and using that instead of the 2.5D clipping (and also enforcing 3D clipping when linked portals are present). I spent more time fixing demo bugs which were already there (or wasted my time when the solution was to specify -spechits), not so much because of my contributions.

I also plan something like it with slopes: there are no slopes in MBF, so old demos won't be affected. The intended logic is to use P_GetFloorHeight(sector, x, y) instead of sector->floorheight. Without slopes, the function will just be equivalent with the second operation.

I agree I don't want to even think about supporting demo compatibility with previous Eternity versions, because then any presence of bugs would be fatal (they would have to stay in the code forever), and only a god is that perfect with bugs. Alternatively, hmm... why not record heavier demos? Stuff like sounds playing and sprites moving and other visual stuff updating, hmm…

I still find Hell Theatre's dismissive posting annoying, to be blunt. I really like seeing the demo loop run flawlessly when playing some vanilla or Boom megawad, for example. On the other hand, kb1 is far too concerned with Doom port justice. I appreciate his concern, but it doesn't have to be so dramatic. No port is being threatened. If GZDoom steals the spotlight too often, it's up to other ports to keep up.

printz said:

Graf Zahl: You're exaggerating, actually. Vanilla Doom, Boom and MBF demo compatibility can be kept in check, by simply reducing all new features to their vanilla Doom base when they're missing.

No, I don't think I am exaggerating. It's just that we are not thinking about the same type of features that need to be guarded.

The real tricky stuff with demo compatibility is not map physics but ensuring that the order of execution remains fixed, in particular this means that the thinker chain, which lies at the bottom of nearly everything, is a hands-off item - as is the blockmap into which the actors get linked. Both of these needs to be meticulously preserved to run demos as intended. And this can become a problem with refactoring some basic parts in the engine. I had to do multiple changes here over the years to ensure that features interact properly, especially with frame interpolation which can be extremely sensitive to items not being run in a well defined order.

For example, it will be very hard to do an inventory like ZDoom's within the confines of demo compatibility, because much of how it works would simply whack the defined order of execution.
12 years ago ZDoom went the totally radical route of tossing out everything that constituted 'inventory' in Doom and built something new, something entirely different and these changes have been one of the cornerstones of today's mods. And nearly all the changes that had been done back then are virtually the antithesis of demo-preserving behavior.

Stuff like slopes and portals, which are map-static are far easier to deal with, all you have to make sure is that for unsloped geometry the calculations do not change, and that can be verified on a per-function basis. The same is true for portals, if you make sure that portal aware code does nothing if no portal is in play, you are on the safe side, assuming the code doesn't contain any hidden errors.

kb1 said:

Yeah, they dropped the ball a little bit.

Uh, what?


You call not caring about 100% backwards compatibility 'dropping the ball'? In a commercial product? I beg to laugh.

I mean, seriously, what do we want? Right now there's a whole fleet of source ports that virtually cater to the same small group, because the all-dominating feature of demo compatibility is guiding their ways.

Why do we need 4, 5, or even 6 ports that can do the same thing? I'd rather have one that puts its entire focus on this feature, doing it really well, and allowing all the others to be more liberal in what they so - and yet they all voluntarily put themselves into the same straitjacket - because some people at some time arbitrarily declared that a 'real' Doom port has to be demo-compatible.


About all the backstory, all the other feature-rich ports would still compete with ZDoom today, had they not dropped the ball on their own. The demand for these ports clearly was there, they just failed to capitalize on it.
None of them was pushed out of business, they all can only blame themselves for their eventual demise and descent into irrelevance. ZDoom had the luck to be the only advanced port to eventually gain a dedicated developer who really cared about the game and not just the new features. Without that I think it wouldn't be where it is today.

Hell Theatre said:

only advanced port

Yes, "only." Sticking around here for 19 years has definitely not been a sign of dedication on my part.

Hell Theatre said:

ZDoom had the luck to be the only advanced port to eventually gain a dedicated developer who really cared about the game and not just the new features. Without that I think it wouldn't be where it is today.

Only. Heh.

We all know chu is a dedicated developer of 3DGE, which it is the successor EDGE. The mere fact that EDGE has a successor shows how dedicated this dev is.

wesley released a new version of Doom Legacy after all these years. So he didn't give up, just took a long break.

GhostlyDeath also released a new version of ReMooD a few months back.

Fraggle released a new version of Chocolate Doom too.

Eternity is improved each and everyday, even though I don't follow it (I really should).

Point is, ZDoom isn't the only one. It's probably the only one that became popular among the newbies, which tend to be the majority of society. ZDoom is easy to setup, mostly user-friendly and has powerful features. That's why it's so damn popular. And the extra development being done by Graf makes it even better for modern times.

All those ports above aren't dead. They do get updated and have dedicated devs (how much dedicated depends but nonetheless dedicated). A programmer wouldn't simply just throw away all his/her work just like that, unless he/she believe it's finished/enough/not-enough-free-time/too-old-for-this-must-pass-on-torch/etc. To programmer, it's basically their own child. You would have to be a sick monster to abandon your child willingly and with no regrets.

Voros said:

Only. Heh.

We all know chu is a dedicated developer of 3DGE, which it is the successor EDGE. The mere fact that EDGE has a successor shows how dedicated this dev is.

wesley released a new version of Doom Legacy after all these years. So he didn't give up, just took a long break.

GhostlyDeath also released a new version of ReMooD a few months back.

All these developers came in when the port they currently work on had already descended into obscurity. Had they been there before things went bad they might be in a better position now.

Voros said:

Fraggle released a new version of Chocolate Doom too.

Chocolate Doom hardly qualifies as a modern feature centric engine so it's not even in the same class as the stuff I was talking about.

Voros said:

Eternity is improved each and everyday, even though I don't follow it (I really should).

It is now, but back at the time about which I was talking it was a fringe port that just made its belated transition from DOS to Windows.

The crucial decisions that made ZDoom what it is today were made 10-13 years ago. Maybe some of the other ports will catch up not only in features but also in users, but it's a long road.

Hell Theatre said:

Right now there's a whole fleet of source ports that virtually cater to the same small group, because the all-dominating feature of demo compatibility is guiding their ways.

There's no reason a port can't focus on retaining demo compatibility while still greatly expanding what the engine can do. Odamex, despite having some bugs, significantly expands the engine beyond vanilla limitations. I'm convinced that a port as powerful as Zandronum for example could have kept certain dmflags and optional game logic in place to retain demo compatibility while still expanding the engine as much as it does. The thing is, demo compat was never the main focus, so optional logic changes and dmflags and stuff to retain it properly weren't implemented along the way.

Demo compat generally only matters to a hardcore subset of Doomers while the majority of casual fans want as few restrictions as possible. Combine that desire with a long, reasonably successful development history and you end up with a "hot seller" like ZDoom. Other ports cater to other, smaller demographics which is why they are downloaded less. Considering that development isn't / should not be a popularity contest, this hardly means those ports are dead as some posts in this thread seem to imply, they're just catering to a different audience.

I'd advance the idea that success is not measured in downloads per day but in pleasing your target audience.

There's nothing that can be done to make people like more than one port. It's in our nature to choose sides and stay there or move to another. Most seem to be in the ZDoom side apparently.

But all those ports I mentioned are used by various people. Sure probably not regularly, but still used. They aren't obscure.

But you're right about one thing. It'll take a long time for any of those ports to win the popularity contest.

I still honestly believe that a few ports could stand to find ways to merge some of their features with each other and continue work together, i.e. Eternity and Odamex, (One has a load of awesome features, the other a pretty decent if still buggy C/S setup, both with dedicated userbases already) Eternity and prBoom+, (prBoom + only having a few features that Eternity lacks) Doomsday and Risen3D, (They're probably too separate at this point though, I'm unsure how much Risen3D has Doomsday doesn't/will implement differently) etc. Of course I'm also not a programmer and probably sound incompetent every time I bring it up.

Death Egg said:

I still honestly believe that a few ports could stand to find ways to merge some of their features with each other and continue work together, i.e. Eternity and Odamex

I've had very pleasant dreams about this (Oda and EE merging), though sadly that will probably remain a dream. We did have ladna working on a C/S branch for EE but he left Team Eternity before this was finished, which follows into my next point...

Ladna is now working on D2K, which hopes to be some kind of megaport that appears to be trying to do and support everything.

Altazimuth said:

Ladna is now working on D2K, which hopes to be some kind of megaport that appears to be trying to do and support everything.

Looking at the commit history it sadly looks like this will turn out to be another vaporware project with high ambitions but ultimately not delivering. Only one single commit in the last 7 months doesn't look like he's actually working on it.

Merging software projects and their teams can be risky for the projects and it generally only works when both sides are forced to do it for business purposes. Progress on both software would halt while the merge was taking place. At least when it comes to Doom ports, they may have a common base.

RestlessRodent said:

At least when it comes to Doom ports, they may have a common base.

Depends on the ports. I guess it may be possible to merge Eternity and PrBoom+, but try that with a port that has deviated further from the mainline and things will look a lot different.

Graf Zahl said:

Depends on the ports. I guess it may be possible to merge Eternity and PrBoom+, but try that with a port that has deviated further from the mainline and things will look a lot different.

I would be really happy to see a GLEternity+.

What's with everyone's obsession with true 3D (hardware) rendering? Especially Hell Theatre who seems to think that it's a vital thing for popularity.

I might see where true colour would be useful: Doom's stock palette can be too limiting when you want new textures. But otherwise I really like the vanilla Doom palette/colourmap/sprite rendering combo.