Intellectual debts

I am just putting this here for now. I think that people should see it and make their own judgments.

https://github.com/coelckers/gzdoom/commit/126c80d597f340f5fc70fdfa74810d029baa51ef#diff-9a400c2233133f87e3099df2e8431783R607
https://github.com/team-eternity/eternity/blob/master/source/p_portal.cpp#L367

https://github.com/coelckers/gzdoom/commit/126c80d597f340f5fc70fdfa74810d029baa51ef#diff-9a400c2233133f87e3099df2e8431783R650
https://github.com/team-eternity/eternity/blob/master/source/p_portal.cpp#L446

https://github.com/coelckers/gzdoom/commit/126c80d597f340f5fc70fdfa74810d029baa51ef#diff-9a400c2233133f87e3099df2e8431783R806
https://github.com/team-eternity/eternity/blob/master/source/p_portal.cpp#L628

The ZDoom giveth, and the ZDoom taketh away...

I'm not convinced that this is anything more than code looking similar because they need to do exactly the same thing and there is pretty much only one way of doing it.

andrewj said:

...because they need to do exactly the same thing...

So then, starting totally from scratch with zero reference to our implementation, whoever wrote this *just happened* to stumble onto the exact same linkoffset grouping system as SoM spent several months of his life hacking on, and that happens to be the only possible solution to linked portals. Hmm.

Then also they just happened to choose the exact same algorithm to build the table, but their implementation only ended up differing in ways that are not important. For example, renaming linkoffset into Displacement, changing the default -1 value to 0, replacing a plain C reallocating array (which has been there since EE was still written in C) with a container object, turning a recursion into a do/while loop. Changing variable names i and p to x and y for no actual good reason (it makes less sense as "x" and "y", so there's no logical reason someone working from scratch would use x and y in that context; the numbers are not x-y coordinates).

On top of that, they just happen to have the next step that our code has (building a portal blockmap) commented out, as if it didn't turn out to be necessary or just hasn't been gotten to yet. How'd that get there on its own? It's quite a stretch to believe that this hypothetical totally independent implementation we're discussing would end up with commented out code from ours.

You should probably be aware that Edward850 has already looked into this and is suspicious himself.

Quasar said:

You should probably be aware that Edward850 has already looked into this and is suspicious himself.

Suspicious of what? Copy-and-pasting code from one engine into another isn't wrongdoing.

dugan said:

Suspicious of what? Copy-and-pasting code from one engine into another isn't wrongdoing.

It is when one is GPLv3 plus request for attribution, and the other is BSD and is blatantly disregarding the request. That is nothing short of the worst kind of disrespect that one programmer can show to another. This isn't even MY code here, it's SoM's. I'm sure I can get him to weigh in here eventually next time I catch him.

dugan said:

Suspicious of what? Copy-and-pasting code from one engine into another isn't wrongdoing.

It absolutely is if it lacks proper attribution. The thing is it's not a copy-and-paste job, but the core idea is suspiciously similar.

(Also ZDoom and Eternity run under incompatible licenses so you can't just copy and paste code legally anyway)

Quasar said:

It is when one is GPLv3 plus request for attribution, and the other is BSD and is blatantly disregarding the request.

Edward850 said:

(Also ZDoom and Eternity run under incompatible licenses so you can't just copy and paste code legally anyway)

Okay, I see the problem now.

Quasar said:

Then also they just happened to choose the exact same algorithm to build the table

Copyright does not prevent someone using the same algorithm.

You may well be right that big chunks of code were copied and refactored for the new code environment. All I am saying is that I compared the code in the links you gave and did not see absolute proof of a copy-n-paste job.

andrewj said:

Copyright does not prevent someone using the same algorithm.

You may well be right that big chunks of code were copied and refactored for the new code environment. All I am saying is that I compared the code in the links you gave and did not see absolute proof of a copy-n-paste job.

True, it doesn't. And SoM doesn't hold patents on it; we don't even believe in those. But why not be totally upfront about this? Why sneak around and be obscuritan about it? I've said before that if people came to us and talked about it in a civil manner, we'd be happy to share the code w/o any questions of legality etc. getting in the way. It's how a community would aim to function. Instead of what I'm seeing, which is, whether intended or not, coming off as taking direct aim at the wind under EE's wings with the current ongoing completion of its portals by printz.

This is not the first time this kind of thing has happened (it is the third actually) and I thought my displeasures were made clear during those incidents. I HOPED that being willing to work through them would lessen their reoccurence in the future. Clearly not, however.

andrewj said:

I'm not convinced that this is anything more than code looking similar because they need to do exactly the same thing and there is pretty much only one way of doing it.

Precisely.

No, there's not a single bit of Eternity code in there, not even in refactored form.
The only thing I took was the concept of grouping the level by portals and storing the displacements, but for the implementation itself I deliberately avoided looking at it.

That part you listed is probably the closest it will ever come to look similar to Eternity because that entire collection algorithm is nearly completely dictated by the concept itself and implementing that (especially when it incurs identical limitations) will inevitably cause situations where the resulting code may look similar because it ultimately needs to so the same job.

Quasar said:

But why not be totally upfront about this?

What's there to say? The goal is clearly to make portals work, and that by necessity will lead to situations where the same things need to be done. If I had to take your code to do the job, I'd ask. But my clearly stated goal is to do it WITHOUT using any Eternity code at all.

But you know, instead of starting a public shitstorm you could have asked privately first.

Of course, if you get ideas and features from Eternity or other ports, it would be nice to say the inspiration -- and saying that thing will not imply that you copied code directly. This is so even if nobody will use other ports than ZDoom because ZDoom already has everything integrated, all the research work done by others will be acknowledged.

Actually, the attribution is there, but I couldn't commit the header file yesterday for technical reasons (it caused some self-destructing circular dependencies) and it got too late. I just finished restructuring the stuff so I could finally commit the last of the changes.

BTW, I never claimed I cooked this up all on my own, if you follow the discussions in the ZDoom forum you'll notice that immediately. No need to take credit for work I did not do.

If Quasar had just asked what's up, that would have been perfectly acceptable and the matter resolved but throwing around some accusations without even doing one single bit of verification and asking in private - I'm sorry, but I find that attitude rather disappointing.

So the situation is cleared up, attribution will be given and both ports will have that feature. Crisis averted!

Quasar said:

Instead of what I'm seeing, which is, whether intended or not, coming off as taking direct aim at the wind under EE's wings with the current ongoing completion of its portals by printz.

You must have missed that this was started by a third-party contribution, which dates back from "Tue Oct 21, 2014" according to the ZDoom forum software. I think you'll agree that it's a bit older than Printz's work on EE's portals.

http://forum.zdoom.org/viewtopic.php?f=18&t=46916

The pull request for portals was created on "Dec 16, 2014" based on the oldest commits it contains. Again, a bit older than Printz's work.
https://github.com/rheit/zdoom/pull/336

Graf did reorient the implementation towards a more Eternity-like system, even if less flexible than what's demonstrated in the video, because it allows the portals to have a deeper implementation. This has been debated back and forth. It's possible that this was inspired by Printz's work, which showed that the Eternity approach could be made fully functional by replacing direct access to x/y/z pos variables by accessor functions that can then be made portal-aware.

I don't know. I must say I have noticed a pattern, however:

. Programmer of non-ZDoom source port makes something interesting, making his port unique.

. Feature appears in ZDoom a short while later.

Especially with Eternity:
. unlimited polyobjs
. now portals

It seems a bit predatory to me. Don't get me wrong - I get it. In fact, I'd love for my port to support those things, and others. In fact, I'd love for my port to be able to do something meaningful with every WAD file thrown at it. But, my implementations will at least be compatible, wherever possible.

It was kinda dickish to break out Eternity's star feature in ZDoom, even before Team Eternity is done with it. That's a cheap blow. Doesn't matter that ZDoom had an older hackish portal feature.

kb1 said:

It was kinda dickish to break out Eternity's star feature in ZDoom, even before Team Eternity is done with it. That's a cheap blow. Doesn't matter that ZDoom had an older hackish portal feature.

This sounds like you're suggesting ZDoom isn't allowed to add features because it is ZDoom. I can't justify that no matter which angle. "But somebody else did X first" is not a valid complaint.
It's also way too late because the Boom standard, and the features it added, is already a thing.

Graf Zahl said:

What's there to say? The goal is clearly to make portals work, and that by necessity will lead to situations where the same things need to be done. If I had to take your code to do the job, I'd ask. But my clearly stated goal is to do it WITHOUT using any Eternity code at all.

But you know, instead of starting a public shitstorm you could have asked privately first.

Not trying to start a shitstorm, which so far this is not, and I see no reason for it to turn into one at this point since there is dialogue going on. If it is going to turn into one, I will close the thread.

Yes, I could have taken my concern to you directly first and that probably would have been better in retrospect so I don't disagree there. Conversely you also could talk to me or SoM and say "BTW we are implementing linked portals; I did look at the groups approach to get the gist of it, and I am working on my own implementation of a system without further reference," before committing it in a public repo where it can be interpreted the wrong way due to lack of documentation on how it was derived.

Gez, I am aware that this has been slowly progressed toward for a while now, I saw the original thread back when it first started. I just found the timing of this new push a bit coincidental given what's going on in our team right now. I never meant to imply the idea of having linked portals in ZDoom started last month - what it looked like to me is that somebody got fed up with it not being finished, looked at our code, and rearranged the key parts of it to get the system finished in time to beat us to the punch. I don't see how anybody could not think that would be a bit upsetting to me given the time scale involved here.

Predatory?

There are some adjectives that could be used describing ZDoom's features being taken from other ports, but that's one that I wouldn't use.

For many years, Eternity and ZDoom both mutually benefited from each others' development. In fact, you could say that neither engine would be where it is today, without the other.

Predatory would imply that ZDoom is trying to crush Eternity, but I have to ask, what would that really accomplish? ZDoom doesn't NEED to do that, and I would argue against any desire to do so considering how much Eternity has already helped ZDoom.

If you want to support Eternity's development, just USE it. I do - and I keep throwing things at it, wondering what will stick. I would love to see it support even more features than it already does.

Graf Zahl said:

But you know, instead of starting a public shitstorm you could have asked privately first.

Graf Zahl said:

If Quasar had just asked what's up, that would have been perfectly acceptable and the matter resolved but throwing around some accusations without even doing one single bit of verification and asking in private - I'm sorry, but I find that attitude rather disappointing.

Let's not be overly dramatic now. All I see here is a discussion among parties who had concerns. Granted a little more research wouldn't hurt but this is hardly a 'shitstorm', especially around here.

kb1 said:

I don't know. I must say I have noticed a pattern, however:

. Programmer of non-ZDoom source port makes something interesting, making his port unique.

. Feature appears in ZDoom a short while later.

Especially with Eternity:
. unlimited polyobjs
. now portals

I'm sorry, but if people are interested in keeping stuff unique to their ports, Doom is probably the wrong game to develop for.

kb1 said:

It seems a bit predatory to me.

Like Eternity getting nearly complete support for ZDoom's ACS features?
Seriously, this is all open source and to some degree these projects will always copy from each other - and normally both should profit.

Or let's assume Eternity got DECORATE support. I think that'd be a boon for many developers because it'd give instant access to lots of external resources that don't have to be translated to EDF first. Why should that bother me? Did I complain when the Vavoom guy took all the stuff many years ago?

Why Eternity seems to be fated to remain such a niche port is one of those mysteries nobody will ever be able to answer, but I doubt it has to do anything with ZDoom's feature set and how much it matches Eternity.
Anyway, here's my take:
Eternity's main competitor is not ZDoom, it's PrBoom+! Right now with so little content that works on Eternity but not on PrBoom+ these two are virtually exchangeable for playing mods. And if that doesn't change it won't find many mappers.
But it might change if there's ZDoom/Eternity mods that can NOT be played with PrBoom and some decent specification and feature set to get people in.
In fact I believe if we could hammer out a common UDMF sub-standard that supports the features both ports share it might boost its popularity a lot. In that case, it will by default become the port of choice for those who don't like how ZDoom has altered some things - and I wouldn't be surprised if then it'll also find some dedicated mappers that will try to experiment with the features it has but ZDoom does not!



About the portal stuff in ZDoom, the discussion had been going on for several weeks already, and I have tried the other way around with first making the external contribution work - but I always ran into the same situation - it requires so much support code for its flexibility that I decided to lay down the groundwork for actual linked portals first, so that I know what I'm up against.

And to be clear: The entire code this discussion is about, is NOT the portal code itself - because nothing exists yet -, it's merely creating the offset table that is required to link it all together. And there's simply not many options to do it, in the end they'll inevitably look very similar.

As for the actual portal code that's to come, no, I won't try to do it like Eternity. I have my own ideas about that and how to keep the amount of support code low.

I feel another issue with the lack of Eternity adoption is the lack of proper support in GZDoom Builder (which could be made easier with the completion of a UDMF spec). While I've tried remedying this somewhat by making a config, there's only so much I can do on my own. When I tried reaching out to MaxED in the thread he ignored me (and Death Egg, who asked about the possibility of having visual editor slopes for an Eternity config).

I enjoy both ports, but at the end of the day what I don't want to see is one port that is almost completely ubiquitous, which is something that ZDoom and its derivatives are approaching when it comes to the less hardcore audience. Though the more casual player might pick up Doomsday, chances are they're picking up (G)Zdoom or Zandronum. I firmly believe that this happening would only harm the community, which is why I'm such a firm supporter of Eternity as an advanced port that could stand alongside ZDoom, as opposed to at odds with.

I'd like to consider myself not immensely close to the issue, and my personal verdict is that the code needs attribution, and ideally in future contributors could be a bit more transparent and compliant with licenses in future, as well as asking beforehand the original coder(s) (as a formality).

Altazimuth said:

I firmly believe that this happening would only harm the community, which is why I'm such a firm supporter of Eternity as an advanced port that could stand alongside ZDoom, as opposed to at odds with.

This is precisely why I would like to see Eternity adopt a lot more advanced features, and why I see no problem with cross-compatibility between the two. Innovation is a two-way street; that's the way it's always been and that's the way it should remain. There's nothing that says Eternity can't pick up more of ZDoom's features. At any rate, I do wish it would get more popular because that team does come up with some great ideas.

If it were up to just me I'd shamelessly copy non-invasive ZDoom code back, but the Team Eternity chief advised me not to mix the licenses, and I also agree that it's fun to come up with my separate variants.

So did ZDoom not implement those movable wall portals yet? Just to shift the discussion into a more technical domain, I'm wondering: don't they require BSP redrawing? They would involve moving one of the portal linedefs. I tried something in Eternity (no upload) like here and here without moving lines, it would even clip correctly, but with some visual glitches when sprites were involved. Basically when the corridors became closer together, they would overlap on the map.

Altazimuth said:

I feel another issue with the lack of Eternity adoption is the lack of proper support in GZDoom Builder (which could be made easier with the completion of a UDMF spec). While I've tried remedying this somewhat by making a config, there's only so much I can do on my own. When I tried reaching out to MaxED in the thread he ignored me (and Death Egg, who asked about the possibility of having visual editor slopes for an Eternity config).

The Eternity map editor feature set right now is based on MBF, but with many new static init linedef specials (such as portal and attached surface setups) and a few new thing types. It also supports setting wall textures and flats to floors and ceilings. Beyond that, you will have to edit stuff not accessible from Doom Builder: EXTRADATA, EDF and some ACS where available. For adding new things that you defined in EDF you'll still have "unknown things" in the map editor, just like how it would happen with a new Dehacked editor.

All in all what I'm trying to say is that the map editor support is not such a big problem, though it helps if you can edit the configuration file in case it's missing.

printz said:

If it were up to just me I'd shamelessly copy non-invasive ZDoom code back, but the Team Eternity chief advised me not to mix the licenses, and I also agree that it's fun to come up with my separate variants.

I like your attitude. ;) If there's something in software development in general I absolutely despise it's NIH-syndrome (Not Invented Here) It's the biggest reason why so many competing and incompatible 'standards' exist, because nobody is willing to give in and give the other side some credit, for whatever reason.

I'd agree that for backwards compatibility's sake alone it makes sense in many regards, but what about some things that actually do not interfere with anything, e.g. Hexen's pillar movers or Strife's animated doors?

I also believe that this licensing crap is ultimately doing more harm than good for everyone involved - on both sides! See this discussion which only comes from the fact that I could not just borrow the original code with proper attribution - instead I had to re-implement something rather simple and not surprisingly the result was quite close to what it was supposed to replace.
To be honest, I would have preferred just to take SoM's code, put a proper copyright notice on it and be done with it.

printz said:

So did ZDoom not implement those movable wall portals yet?
Just to shift the discussion into a more technical domain, I'm wondering: don't they require BSP redrawing? They would involve moving one of the portal linedefs.

Those movable wall portals are just portals put on a polyobject. The rendering part of it is already working, it actually depends on ZDoom attaching a mini-BSP to each polyobject which allows them to move around more freely. Since for the renderer a polyobject wall is nothing special after it has been processed this part works with relatively additional work.

The main problem is the movement code right now. The submission came with a very rough implementation which actually should work for the most part. The actual problem for us developers right now is more that it requires quite drastic changes to how functions like P_CheckPosition and P_TryMove work. That's why I need some baseline idea how to handle linked portals without having the other stuff break them later - that's what I'm working at right now.

printz said:

The Eternity map editor feature set right now is based on MBF, but with many new static init linedef specials (such as portal and attached surface setups) and a few new thing types. It also supports setting wall textures and flats to floors and ceilings. Beyond that, you will have to edit stuff not accessible from Doom Builder: EXTRADATA, EDF and some ACS where available. For adding new things that you defined in EDF you'll still have "unknown things" in the map editor, just like how it would happen with a new Dehacked editor.

Yeah, but looking at all of it, there already is a good deal of Hexen-linedef support, if that got systematically completed by the essentials, you'd be a good deal further to the goal.
Nothing against Extradata in general, but it always has been a kludge that actually should have been retired 8 years ago when the UDMF-standard was finalized (by Quasar of all people if I may so note!)

Eruanna said:

Innovation is a two-way street; that's the way it's always been and that's the way it should remain.

Agreed. As a good example for this, just look at ZDoom's polyobject code.
The original idea was just to make it work like in Eternity, i.e. remove the limitation to one subsector. But after that was done Randy came up with the idea to attach some mini-BSP to each polyobject (to be precise to each polyobject fragment in a subsector) which made the feature what it is today.

That's how innovation mostly works: Take a good idea and improve on it!
And that's why people and companies who are more concerned with hoarding their trade secrets rarely are at the forefront of innovation, they are too much concerned with 'protecting' themselves from others' innovation.

Graf is so far nothing but right I think. I have stupid old suspicions going back to things that happened in the past that should just be forgotten about so that everyone can move forward in the future.

I will answer in the case of Extended ACS at least, everything has been implemented in EE exclusively using the ZDoom Wiki documentation or by studying the output of the ACS compiler. Several DECORATE pointers were also implemented through the same process. It's just the simplest way for us to keep our licensing situation trivial, even though we *can* use code directly from ZDoom (we're stuck with it whether we like it or not, you cannot just "quit being GPL" from a legal POV so far as past contributors' code goes) - it's just admittedly a pain to track what is under BSD or not and have intervening license headers and delimiting comments on "this part goes back to being GPL" - never mind the undefined mess of functions under different licenses calling each other and whatnot. Easier for us to "clean room" it from the specs.

I prefer a setup where we do benefit from each other and have interop. I was going to say I felt like there was some assymmetry in the credit given, but I see that the README.TXT with ZDoom does mention us, so, that's appreciated.

And again I'll clear up something further - when you say you would rather be able to use our code and give attribution, well, I've been trying to make it clear that that can be possible in these circumstances. It would consist of the conversation I was referring to earlier, saying "I'm interested in doing this, is it alright to use your code?" - virtually all of the portal code is owned only be me, SoM, or printz.

Because of that we're able to license it however we see fit and, in truth, my views on licensing have shifted dramatically over the past two years and I feel much more willing to let my code be used under different licenses - so long as people are being respectful about it. I intend to soon release a significant portion of the "elib" library code and framework stuff, which I own entirely, separately under the MIT license.

I'll again concede that there was no intended slight here, and that my posting this w/o researching further was an overreaction.

Quasar said:

I will answer in the case of Extended ACS at least, everything has been implemented in EE exclusively using the ZDoom Wiki documentation or by studying the output of the ACS compiler. Several DECORATE pointers were also implemented through the same process. It's just the simplest way for us to keep our licensing situation trivial, even though we *can* use code directly from ZDoom (we're stuck with it whether we like it or not, you cannot just "quit being GPL" from a legal POV so far as past contributors' code goes) - it's just admittedly a pain to track what is under BSD or not and have intervening license headers and delimiting comments on "this part goes back to being GPL" - never mind the undefined mess of functions under different licenses calling each other and whatnot. Easier for us to "clean room" it from the specs.

You know, if I could I'd switch ZDoom over to the GPL in a heartbeat. Sadly there's not much I can do about the blocking issues. The Build code in the software renderer is far too intermingled with the rest, Randy won't let go of FMod and the OPL code is out of my league. So nothing happens on these three fronts. :(

Quasar said:

I prefer a setup where we do benefit from each other and have interop. I was going to say I felt like there was some assymmetry in the credit given, but I see that the README.TXT with ZDoom does mention us, so, that's appreciated.

Good that we agree on that. I think it'd be in both ports best interests if there was a greater span of compatible features.

Quasar said:

And again I'll clear up something further - when you say you would rather be able to use our code and give attribution, well, I've been trying to make it clear that that can be possible in these circumstances. It would consist of the conversation I was referring to earlier, saying "I'm interested in doing this, is it alright to use your code?" - virtually all of the portal code is owned only be me, SoM, or printz.

Because of that we're able to license it however we see fit and, in truth, my views on licensing have shifted dramatically over the past two years and I feel much more willing to let my code be used under different licenses - so long as people are being respectful about it. I intend to soon release a significant portion of the "elib" library code and framework stuff, which I own entirely, separately under the MIT license.

Thanks for clearing that up. Asmittedly, my plans will be somewhat different than how Printz approached the portals - since ZDoom allows linking actors into multiple blockmap blocks I think I can exploit this to simplify matters significantly (like linking stuff into the blocks and sector lists at both sides of the portal and make the iterating code aware of potential offsets) - but just being able to look at the code for reference and then giving proper credit for those portions will be a great help.

As for the other way around, if you are concerned about licensing issues with ZDoom code - as long as it's written by me you do not need to worry. If you feel uncomfortable with mixing the licenses you may change it - as long as we can agree that the above still applies to this code, too.

Graf Zahl said:

I'm sorry, but if people are interested in keeping stuff unique to their ports, Doom is probably the wrong game to develop for.



Like Eternity getting nearly complete support for ZDoom's ACS features?
Seriously, this is all open source and to some degree these projects will always copy from each other - and normally both should profit.

Or let's assume Eternity got DECORATE support. I think that'd be a boon for many developers because it'd give instant access to lots of external resources that don't have to be translated to EDF first. Why should that bother me? Did I complain when the Vavoom guy took all the stuff many years ago?

Why Eternity seems to be fated to remain such a niche port is one of those mysteries nobody will ever be able to answer, but I doubt it has to do anything with ZDoom's feature set and how much it matches Eternity.
Anyway, here's my take:
Eternity's main competitor is not ZDoom, it's PrBoom+! Right now with so little content that works on Eternity but not on PrBoom+ these two are virtually exchangeable for playing mods. And if that doesn't change it won't find many mappers.
But it might change if there's ZDoom/Eternity mods that can NOT be played with PrBoom and some decent specification and feature set to get people in.
In fact I believe if we could hammer out a common UDMF sub-standard that supports the features both ports share it might boost its popularity a lot. In that case, it will by default become the port of choice for those who don't like how ZDoom has altered some things - and I wouldn't be surprised if then it'll also find some dedicated mappers that will try to experiment with the features it has but ZDoom does not!



About the portal stuff in ZDoom, the discussion had been going on for several weeks already, and I have tried the other way around with first making the external contribution work - but I always ran into the same situation - it requires so much support code for its flexibility that I decided to lay down the groundwork for actual linked portals first, so that I know what I'm up against.

And to be clear: The entire code this discussion is about, is NOT the portal code itself - because nothing exists yet -, it's merely creating the offset table that is required to link it all together. And there's simply not many options to do it, in the end they'll inevitably look very similar.

As for the actual portal code that's to come, no, I won't try to do it like Eternity. I have my own ideas about that and how to keep the amount of support code low.

Oh, drama! (not towards Graf, towards some other responders). Naw, I expect ZDoom and others to adopt each other's features, of course. In the case of ACS, that was adopted after it was quite mature, and let's be honest - it wasn't exactly a novel feature that made ZDoom stand out.

Eternity's portals, however, are in their infancy, and, yes, they are a ground-breaking feature that makes Eternity stand on its own. I assume that people want honest impressions, so I gave one, and I'll state it again for the spastic: I think Eternity should be allowed to work exclusively on their new feature exclusively - at least until they finish the code!

What if ZDoom finishes portals before Eternity? In my opinion, it would be dickish to release that code for a while - that's all I meant. It's not about competition - (I'm not sure how to apply that term to Doom source ports). I just feel that Team Eternity should enjoy their due credit for their invention for a little while, before everyone snatches up the idea, in a predatory fashion. Does that make sense?

Maybe I overreacted to the thought - I'll concede to that. Not trying to sling shit, but I should have expected that it would look that way. Glad to know that some cooperation is forthcoming - that's the best possible consequence of this thread!

Edit: Totally agree with hammering out the common spec - that's always the right thing to do.

kb1 said:

Eternity's portals, however, are in their infancy, and, yes, they are a ground-breaking feature that makes Eternity stand on its own. I assume that people want honest impressions, so I gave one, and I'll state it again for the spastic: I think Eternity should be allowed to work exclusively on their new feature exclusively - at least until they finish the code!

If this community waited for others to finish projects that they first thought up or started first, then nothing would ever get done. Eternity has many awesome things but let us recall the UDMF standard that was mostly brought about through the initial work and encouragement of Quasar himself. It's been in ZDoom for years, is it even implemented in EE yet? I know that for a very long time it was not.

For the record, I'm not trying to rag on Quasar here.

That was a common map standard. It is not the same as engine features.