What do you think about Eternity Engine?

I always liked to test all engines and since I have Mapped and/or MODed for various, now the time for Eternity Engine has come.

What I would like to know is your opinion about this Source Port.

I know nothing about this engine, except that has some similarities with Boom. Why this engine seems to be forgotten, and we cannot find many PWADs designed for this, instead for Boom?

Salutes.

Karnizero said:

Why this engine seems to be forgotten

Forgotten? Far from it. Eternity seems very popular actually.

Karnizero said:

and we cannot find many PWADs designed for this, instead for Boom?

Eternity did not have a large and stable feature base for that long.

Eternity holds a lot of promise; I think this year we'll see a lot of awesomeness.

Csonicgo said:

Eternity holds a lot of promise; I think this year we'll see a lot of awesomeness.

Yeah. And we'll also see a widespread usage of Linux on Desktops.

I've tried to like it, because it has enticing capabilities that other ports lack (well, linked portals anyway) while maintaining a classic aesthetic, but most of its potential is just that, potential, and it remains as potential for all of perpetuity, so it's hard for me to stay excited about it. I might be a little bit more excited when it actually has working linked portal clipping code, when it actually has a non-deprecated method of scripting, when it actually has Heretic support, Hexen support, and UDMF support, etc...

Furthermore, while Quasar is absolutely in the right in following his own interests, such as Strife executable hacking, instead of working on these features (he's coding for fun, afterall) the result is that the port's development doesn't have enough momentum or organization behind it to keep me faithful. On top of that, this is a port which would be difficult for new developers to work on - it's still in C, it relies on some complex re-inventions of C++ features, and it has some overarching structural problems, so I'm also less than confident about Eternity's long-term survival.

Sorry to be pessimistic, but I felt this viewpoint was worth sharing.

I think it's the best-looking software renderer around right now. I've started using it as my single player port of choice for playing random WADs.

Creaphis said:

it has some overarching structural problems

Proof?

Creaphis said:

I might be a little bit more excited when it actually has working linked portal clipping code, when it actually has a non-deprecated method of scripting, when it actually has Heretic support, Hexen support, and UDMF support, etc...

Scripting is my domain and I'm still looking at ECMAScript as the solution. It would help if I could ascertain exactly what Mozilla's stance is to the further maintenance of SpiderMonkey. They haven't made any statements one way or another about it for a very long time. Plus there are just other things that are higher priority to me at the moment, like the impending EDF rewrite. Some of these things really do need to get done *before* we think about adding a new scripting language, since they will affect the way it needs to work.

Portals are SoM's thing. I myself had hoped that they would be finished a long time ago, so we're in the same boat there.

Creaphis said:

Furthermore, while Quasar is absolutely in the right in following his own interests, such as Strife executable hacking,

I have personally viewed my work on Strife as work on Eternity, since I intend EE to have high fidelity in its Strife support. It's indirect work, but it's still important.

Creaphis said:

On top of that, this is a port which would be difficult for new developers to work on - it's still in C, it relies on some complex re-inventions of C++ features,

That's kind of nonsense I am afraid. C is a simpler language and is a direct subset of C++. If you know C++, you are automatically functional in C.

For that matter we're not looking for new developers right now anyway. Ever heard the phrase "Too many cooks in the kitchen?" That's what you get when you have too many people throwing in their contributions without any checks or balances between them. At most we could use one other person, to replace Joe who quit.

The metatable is an elegant solution to enable EE to use the same kind of extensible structs that are in ZDoom. C++ doesn't natively support these any better than C. The STL does not even contain a hash table class, only a map, which is *not* the same thing.

Creaphis said:

and it has some overarching structural problems, so I'm also less than confident about Eternity's long-term survival.

Not sure what you're referring to here :) The only part of Eternity that I would currently call a structural problem is the netcode, and EE is not really meant to be a major multiplayer port so it's kind of a nonissue to me. The line special system does need to be reworked, but as you know that is already on the short-term TODO list ;)

Quasar said:

The STL does not even contain a hash table class, only a map, which is *not* the same thing.

Care to elaborate, like what you need from a "real" hash table class which std::map cannot do?

(I think std::map is one of the best things in the whole damn language)

andrewj said:

Care to elaborate, like what you need from a "real" hash table class which std::map cannot do?

(I think std::map is one of the best things in the whole damn language)

O(1) access time, chiefly. map and multimap only guarantee O(log N).

EE's ehash_t also has constant-time insert, delete, and iteration increment.

This is very important when doing potentially dozens or even hundreds of hash resolutions per game tic, which could be the case once the Aeon scripting system is in place.

Quasar said:

O(1) access time, chiefly.

Aha, I see.

'tis strange that C++ lacks a standard hash table class, Stroustrup has a simple implementation (hash_map) in his C++ book, but you'd think the standard groups would've endorsed a standard one by now....

andrewj said:

Aha, I see.

'tis strange that C++ lacks a standard hash table class, Stroustrup has a simple implementation (hash_map) in his C++ book, but you'd think the standard groups would've endorsed a standard one by now....

SGI STL even has hashmap, but it failed to pass the standardization committee last time, mainly due to nothing else besides the deadline passing before they could consider it, IIRC.

Maybe they will finally rectify that in C++1x, but then, I don't expect Microsoft to pay that standard any more heed than they have C99 (which is exactly zero).

Quasar said:

Scripting is my domain and I'm still looking at ECMAScript as the solution. It would help if I could ascertain exactly what Mozilla's stance is to the further maintenance of SpiderMonkey. They haven't made any statements one way or another about it for a very long time.

Last time I've heard about it, they were borrowing some code from WebKit to speed things up.

C++ is not C and even MS cannot afford to have an outdated compiler. I think they will implement new standards there. They still need to market their compiler, even in the future.

C99, well, let's be honest. No serious project uses C anymore unless it's exceedingly simple, based on old legacy code that cannot be changed or is supposed to be a general purpose library - and most of these wouldn't even consider C99 for various reasons, MS is the least from.

It sure sucks but it's obvious that since MS has gotten away for 10 years not implementing C99, the demand apparently is not there.

Graf Zahl said:

C99, well, let's be honest. No serious project uses C anymore unless it's exceedingly simple, based on old legacy code that cannot be changed or is supposed to be a general purpose library - and most of these wouldn't even consider C99 for various reasons, MS is the least from.

Serious projects still use C, I doubt ReactOS will suddently rewrite their entire OS in C++. C99 is pretty much supported by GCC but not MSVC, so if you are writing portable code you need to rely on replacing the stuff needed to use C99 in MSVC.

Also, just because Microsoft does not demand it, does not mean noone demands it. Microsoft pretty much does it's own stuff for whatever they are willing to spend.

I still think that in the end it's all supply and demand. If the majority of MS's customers demanded C99 they'd get it. Sales mean profit, after all.

Grubber said:

Last time I've heard about it, they were borrowing some code from WebKit to speed things up.

That's an even further Franksteinization of the TraceMonkey codebase, which is already a nightmare.

SpiderMonkey is a clean C implementation of JavaScript. For some reason when they used it as the basis for TraceMonkey, they splashed all the source files with a bunch of messy C++ code and then scrambled it all around to the point it looks like a hurricane hit. These factors prevent me from even considering TraceMonkey as a scripting engine for EE.

Mozilla is taking the wrong approach in their bid to try to outdo Chrome. Google wrote a fast interpreter by starting from the ground up. Mozilla just keeps tacking more and more unrelated strategies onto SpiderMonkey, assuming that if one part is faster, it'll drag the rest along with it. When I hear about a single scripting engine that cannot decide between plain interpretation, tracing, and dynamic recompilation as its primary strategy, I know something is wrong.

Graf Zahl said:

.....
C99, well, let's be honest. No serious project uses C anymore unless it's exceedingly simple, based on old legacy code that cannot be changed or is supposed to be a general purpose library - and most of these wouldn't even consider C99 for various reasons, MS is the least from.
....

What. Since when? I see plenty of projects that are C only to this day. I myself prefer C and if I ever get unlazy enough to program something it will, no doubt, be in C. I just love how clean and simple it feels, as Quasar put in IRC, C++ almost compels you to have to use one of the added features to solve a problem you could probably do otherwise very simply, and it bloats your program. Of course, this is less an issue with C++ and more towards the person but the point still stands that there are a decent amount of people out there that still prefer C.

(Though I do agree with you on the point that not enough are demanding Microsoft to support C99, this may be partially due to Windows ports of GCC though)

MP2E said:

I myself prefer C and if I ever get unlazy enough to program something it will, no doubt, be in C. I just love how clean and simple it feels, as Quasar put in IRC, C++ almost compels you to have to use one of the added features to solve a problem you could probably do otherwise very simply, and it bloats your program.

Ugh, what a pile of bullshit! What else but to solve your problems are these features there for? Why should I use a primitive programming language when I can have a much more powerful one that saves me lots of work? In the 20 years I've been using C++ there hasn't been one moment where I felt that it makes things more complicated. Yes, many C++ programs are extremely complex (and messy) but if most of them were written in C they'd be even more so.

Bloat comes from poor planning, not from the choice of programming language. Someone who writes bloat in C++ will most likely write bloat in C, too.

MP2E said:

Of course, this is less an issue with C++ and more towards the person but the point still stands that there are a decent amount of people out there that still prefer C.

That may be for stuff that can be expressed in a simple procedural way (and even there I'd prefer C++ because it has stricter syntax checks.) But that's not how most applications work. Once you need to handle the concept of objects C degenerates into a mess. Even Doom, simple as it may be is a good example for this. The entire thinker hierarchy in it would have benefitted a great deal, both in readability and robustness if it had been designed for a language that can naturally handle it. What we got instead is quite a mess that's prone to errors and ugly as hell.

Creaphis said:
I've tried to like it, because it has enticing capabilities that other ports lack (well, linked portals anyway) while maintaining a classic aesthetic, but most of its potential is just that, potential, and it remains as potential for all of perpetuity, so it's hard for me to stay excited about it.

Given the name he chose for it, Quasar knew from the onset that it was going to take some time :p

(The same applies to DNF and Doom Millennium, and "Mordeth" implies we will see more of it when we're mostly dead.)

Let's all derail the Eternity thread and turn it into a language war, C is supreme, all other languages suck!!!1111

Anyway, I've looked at Eternity game wise and source code wise. Game wise seems okay as of a year ago since that's when I last played it (portals). Source code wise, I would have to say that the source is better than it was before (complete Boom mess).

GhostlyDeath said:

Source code wise, I would have to say that the source is better than it was before (complete Boom mess).

I'd say that's the case for all code that has been de-Killough-ized... :D

Graf Zahl said:

I'd say that's the case for all code that has been de-Killough-ized...

lol, been there done that.