Why is Eternity not so popular?

[stewboy]

41 minutes ago, Gez said:

[...] It complicates detailed mapping. The map itself is still a 2D representation, so all the floor and ceiling details of both the lower room and the upper room end up squashed together.

That's the big one for me. You can have bridges, tunnels, and simple room-over-room setups with 3D floors (and I have even done so myself), but if you want to create levels that truly make the most of vertical space, portals are just so much simpler. Don't just think of room-over-room - think room-over-room-over-room-over-room.

[boris]

On 11/25/2020 at 8:44 PM, Ralphis said:

Here comes the sting though. From what I've seen over the past two decades, EE often lead source ports in the proposal of certain ideas being implemented, but was then always behind the curve on delivering compared to ZDoom. Slopes were visually implemented but no physics. Quasar was one of the primary people to push UDMF and ZDoom had it implemented and functional years before EE. EE shows off some sweet in-progress portal tech? Blink your eyes and GZDoom has it shortly thereafter.

 

In my view EE's shortcoming has often been showing its hand too early. The most popular port has stolen its thunder time and again. If EE had finished portals along side a killer map set utilizing it (think Vaporware), I believe that would've driven people in at the time. Same with all the other awesome ideas that have been partially implemented in EE for years.

 

Yes, the issue isn't that other ports add propsoed features very fast (that blink of an eye for line portals in ZDoom was something like 1.5 years long or so), it's that EE is exceptionally slow in adding stuff. Examples: the UDMF 1.0 specs have been finalized in mid-2008. According to the changelog support was added to EE in version 3.42.02 in mid-2017. That's 9 years! Aeon has been "coming soon" for 8 years or so.

 

Don't get me wrong, as pretty much everything in the community EE is a hobby project and nobody is entitled to expect anything. But that EE has been tripping over its own feet for 2 decades isn't really other port author's fault.

[wesleyjohnson]

As there is this thread about EternityEngine, so this is a dump of an EnternityEngine problem.  Just warning you, I am not looking for help, just telling you the latest irritation.

This is where the INSTALL procedure for Linux could use some work.

 

My motherboard failed, so I am rebuilding everything for the new hardware.

I found the latest release for EternityEngine, 4.01, and tried to build it.

 

1. The build instructions for Linux seem to consist of , make build dir, cd to build dir, and run cmake.

I already know this is not adequate, there must be a configure, and a install.

 

2. I cannot find any instructions for how to pass options into the CMake build, or what options are available in Eternity.

From DoomLegacy I know about doomdef.h, and I assume that I could change options in there, but this doomdef.h looks more like a definitions file and not like a user configuration file.

 

3. I would prefer to build binary for my specific processor and not for a generic 486.

I am trying to adapt a slackbuild script to do that, but it appears I will have to reverse engineer the cmake files to accomplish that, and I rarely use cmake, so that is going take some time.

 

4. I know there are data files  in /usr/share/,  but I have no idea how they are going to get installed.

Am I going to have to do that by guess again ?

 

5. There is no list of Requirements for Linux using CMake, so I cannot determine if this will run on my system, or what I would need to get it to run.

There is a Requirements list for Mac, and those are libraries that I do have.

 

6. An attempt to run cmake, just to get something, failed with a fatal error.

I do not have  "adlmidi" and that seems to be fatal.   There is an adlmidi directory in the source, but it is empty, so that is a mystery.

There is no adlmidi slackbuild available, so this is going to take some time to accomplish.

Requirements did not mention needing adlmidi.

 

I already have Timidity and FluidSynth.  Why does this require another midi synth ?   It couldn't use the available Midi support like other ports do ?

 

This is where I stopped for the day.

I already got several fires to put out so this is going to have to wait until I have some time, like maybe January.

I might try version 3.4 again, as I managed to somewhat get that installed on the old system.

So for now I still do not have a working Eternity, and that does hamper its popularity.

 

 

[LexiMax]

15 minutes ago, wesleyjohnson said:

1. The build instructions for Linux seem to consist of , make build dir, cd to build dir, and run cmake.

I already know this is not adequate, there must be a configure, and a install. 

 

Which build instructions are you looking at?  I'm seeing these, and they look pretty complete to me.

[Altazimuth]

30 minutes ago, wesleyjohnson said:

I do not have  "adlmidi" and that seems to be fatal.   There is an adlmidi directory in the source, but it is empty, so that is a mystery. 

There is no adlmidi slackbuild available, so this is going to take some time to accomplish.

Requirements did not mention needing adlmidi. 

 

This is not new.

[Redneckerz]

19 hours ago, wesleyjohnson said:

As there is this thread about EternityEngine, so this is a dump of an EnternityEngine problem.  Just warning you, I am not looking for help, just telling you the latest irritation.

This is where the INSTALL procedure for Linux could use some work.

 

My motherboard failed, so I am rebuilding everything for the new hardware.

I found the latest release for EternityEngine, 4.01, and tried to build it.

 

1. The build instructions for Linux seem to consist of , make build dir, cd to build dir, and run cmake.

I already know this is not adequate, there must be a configure, and a install.

And there is one, but are you looking in the right direction or are you venting your frustration as you progress through the various compilation stages

19 hours ago, wesleyjohnson said:

3. I would prefer to build binary for my specific processor and not for a generic 486.

Since when is that ever a thing? You want a specific processor path (and likely optimized)? Then that should be on your behalf.

 

A specific processor build in the literal sense is Improbability Central. Fairly sure you mean something else entirely.

 

Aside that, the fact that you are adapting unknown scripts to accomplish something that seems fairly well documented given by the links sounds

19 hours ago, wesleyjohnson said:

So for now I still do not have a working Eternity, and that does hamper its popularity.

I don't think that just because you take a different, more bumpy road to Rome (and getting stranded as a result) is the reason why Eternity isn't popular. The notes are sound.

 

The primary reason for its lack of popularity has been given already: Too little proper showcases and perhaps OpenGL/3D acceleration.

[ReaperAA]

23 hours ago, wesleyjohnson said:

So for now I still do not have a working Eternity, and that does hamper its popularity.

 

And windows 10 users do not have a properly working version of Doom Legacy, and that does hamper its popularity.

[wesleyjohnson]

This feels like I am just explaining the obvious, but the commentors outlook on the build process seems self-absorbed.

 

I got Eternity 4.01 as a zip file (snapshot probably) because that zip file goes into my database of external program sources.

I do not maintain a GIT for eternity, as I am not contributing nor updating it.

So  I do expect a  "git submodule update" is not going to work.

 

I did get sidetracked trying to figure out how to configure Eternity.

 

The build instructions I found are README.adoc.   I don't know what pointing to the GIT is supposed to mean, but it has the same copy of README.adoc.

Trying to follow those instructions is what led to the mentioned problems.  I find the build notes to be basic, and inadequate for anything beyond. 

I have been building Linux programs, including Doom ports, since the 90's, so I am not new at this either.  Building eternity should not have been this complicated.

Having compiled some 50 programs over the last two months now and reading so many other sets of compile instructions, I find these instructions to be lacking.

 

No compile tuning, nor options.

No program configuration.

No installation.

 

The ADLMIDI is a gotcha, and it is going to keep getting people, so you are going to have to keep answering questions about this ADLMIDI.

I will have to find some other way to get the ADLMIDI.   I am wondering why the snapshot did not copy ADLMIDI too.

 

I build for my processor by passing an ARCH directive to the build process, such as  ARCH=i686.

It is a thing for anyone who wants to actually use the capabilities of their processor.

A generic 486 build runs slow in comparison.

For a program like a Doom port, it should make a significant difference in the speed of the graphics draw primitives if the compile is tuned to your specific processor.

If you are going to use a draw library like SDL, then building that tuned to your specific processor is also important.

 

The slackbuild process has a way to do that for CMAKE projects.  To use it I will have to create a whole slackbuild for eternity.

The Slackware community have the slackbuild site where users can download a slackware build script for most any projects, including many Doom ports.

This is one way we share the cost of figuring out how to get a program to compile on slackware.

Trying to make a slackbuild that works with GIT is going to be an oddity, no other project I know of requires that, so the method is not known to me.

Making the slackbuild is important, because that slackbuild encompasses all the fixes, and setup, for building on Slackware Linux.

That same slackbuild can be used again for the next release of Eternity.

You really think I am going to memorize all the steps needed for the some 50+ programs I have had to build in the last month.  I have much more than just Eternity to compile, and keep track of how to compile successfully.

The next release of Eternity, I am not going to go searching this forum for some posting that explained away some problem.

 

Yes, not being able to compile a program does hamper its popularity.

I tend not to use programs that I cannot compile.

If a compile is difficult, fiddly, or requires strange steps, then I will skip releases, and will avoid updating that

program for as long as possible.

 

A program that I can update easily will be more often up to date, and will be more popular in my choices.

A program that I can configure to my needs and preferences will also be more popular in my choices.

 

[Edward850]

@wesleyjohnson Here's how you build with Linux, as outlined in the git page you were previously linked to. It's two straightforward steps:

Quote

Compiling

There are four ways available for building Eternity: CMake, Visual Studio, Xcode files, and Homebrew, for Unix, Windows, and both Mac OS X respectively.

Git submodule

The project contains the ADLMIDI submodule. You need to load it after you’ve just cloned Eternity, by using this command:

git submodule update --init

Building with CMake

CMake should be capable of generating build files for all platforms, but it is most commonly used only for Unix OSes and not thoroughly tested outside of it.

If you haven’t already, extract the source *.zip file or clone the Git repository, in the top-level directory you should see a CMakeLists.txt file. You should be in this directory.

Create a new empty directory and change to it, eg: mkdir build followed by cd build. You cannot do an in-tree build.

Run CMake. Usually you will want to run cmake .., but you might want to change the generator with a special command, for example:

cmake .. -G "Unix Makefiles" cmake .. -DCMAKE_BUILD_TYPE=Debug -DCMAKE_PREFIX_PATH=C:\sdk\x64 -G "NMake Makefiles" cmake .. -DCMAKE_BUILD_TYPE=MinSizRel -G "Visual Studio 15 2017 Win64"

Run your build tool. On Unix, you probably want to just run make.

As an optional final step, you can create a binary installation package with CPack. For Windows, it will collect all the needed runtime libraries and bundle it with the Eternity engine. Some examples:

cpack -G ZIP cpack -G DEB cpack -G RPM cpack -G STGZ

From my own testing, and confirmation of others, these instructions are absolutely 100% complete for compiling on Linux. 

 

This is coming from the person who has considerable trouble with the Steam Linux chroot for compiling commercial products. Even I can follow this, I'm not sure how this could possibly be made any easier than git clone --recursive, cmake, make. 

Edited December 15, 2020 by Edward850

[boris]

11 hours ago, wesleyjohnson said:

Yes, not being able to compile a program does hamper its popularity.

 

If you think that you're completely delusional. In the big picture the number of people who want to compile it themselves is completely irrelevant.

[fabian]

And then there is the number of people who try to compile the sources - and succeed!

[LexiMax]

18 hours ago, wesleyjohnson said:

This feels like I am just explaining the obvious, but the commentors outlook on the build process seems self-absorbed

 

Okay that's enough.

 

The problems you are running into are indicative of either not the reading the provided instructions carefully enough, not being generally competent in the tools you're expected to know as a developer, or having weird myopia of the kinds of things that are "necessary" for a build.  In addition, you seem unable to succinctly sum up the issues you are running into, leading people to tease through a wall of text to see if there are any relevant morsels to pull out and additionally determine if there's an actual issue at play or not.

 

18 hours ago, wesleyjohnson said:

A program that I can update easily will be more often up to date, and will be more popular in my choices. 

A program that I can configure to my needs and preferences will also be more popular in my choices.

 

I don't think any of the Eternity Engine developers are going to lose a wink of sleep over what ports you specifically choose.  You are a demographic of one.  In fact i'm willing to bet that another Slackware user would be able to figure it out no sweat.

[VoanHead]

Don't get me wrong, the Eternity Engine is a fucking amazing source port, I use it to play Boom or MBF compatible wads. Especially when I'm thinking about giving skillsaw's stuff a replay. The only problem I have with it is the fact that the kill count is just kinda broken when an Archvile is thrown into a map and resurrects enemies. Instead of going +1 in the total enemies alive, it just stays the same and only goes +1 enemies killed when you kill said resurrected demon (ex: 101/100)

[Edward850]

5 minutes ago, VoanHead said:

Don't get me wrong, the Eternity Engine is a fucking amazing source port, I use it to play Boom or MBF compatible wads. Especially when I'm thinking about giving skillsaw's stuff a replay. The only problem I have with it is the fact that the kill count is just kinda broken when an Archvile is thrown into a map and resurrects enemies. Instead of going +1 in the total enemies alive, it just stays the same and only goes +1 enemies killed when you kill said resurrected demon (ex: 101/100)

This isn't an Eternity issue, but behaviour direct from Doom itself. Enemies resurrected by the archvile, -respawn flag or spawned by the IOS still have their COUNTKILL flag, but don't change the actual kill count, meaning that killing them (again) will keep adding to the kill telly past the initially counted number of enemies. Fixing this presents logistical challenges as well as produces potential for demo desynchronization as how long an intermission screen takes is affected directly by the telly counters.