setdialect("ALFHEIM")
stdinclude("root.edf")

// Weapons
include("edf/shotgun.edf")

The actual shotgun.edf file is this:

weapondelta
{
	name Shotgun
	
states =
  @"
  Ready:
     FLSG A 1 A_WeaponReady
     loop
  Deselect:
     FLSG A 1 A_Lower
     loop
  Select:
     FLSG A 1 A_Raise
     loop
  Fire:
     FLSG A 3
     FLSG B 7 A_FireShotgun
	 FLSG A 2
	 FLSG CDEFGHIJKLMNO 2
     FLSG A 3 A_ReFire
     goto Ready
  Flash:
     FLF A 4 Bright A_Light1
     goto LightDone
 "@

This shotgun was working fine when it was just slapped into edfroot, but when I put it in its own file and referenced it with an include, it created an engine error (attached on this post.) I tried changing the dialect to GLITNIR but then EE just complained that the dialect didn't exist. Did I do something wrong?

crash.zip

One part that I have since figured out is that the FOV in the eternity engine seems to be off by about 20 degrees. When I compare screenshots, Eternity engine's FOV-140 is identical to fov 120 in any other source port. Or to put it differently, the default setup for the engine is 100 Fov, which is actually a fov of 80 :(

What I haven't been able to figure out though is why (maybe it's as designed?) the vertical mouse look causes the old school skew-scrolling that you don't get on most of the other OpenGL renderers. I'm pretty sure that's the second component of my motion sickness, cus that stuff is a shortcut to vomit town for me. But disabling mouselook only partially solves that issue ,as you can still see the distortion depending what you're looking at, and from where.

While I'm at it, I'd prefer it doesn't cap my vertical look to whatever 30 degrees or so that it does. Ultimately all of this is because I like to look around at the environment and design when I'm playing rather than just blast through at maximum speed.

EDIT: I'm pretty sure everyone knows the skewing phenomenon I am referring to here but just in case, here's some shots:

Eternity Engine:

GZDoom

• Readme file
• Official Windows builds: x64, x86, x86 for CPUs without SSE2
• Official macOS build
• Source Code: .zip, .tar.gz
• Documentation is available on the wiki (some new features are still in the process are being documented)

Example WADs:  SOON™

Update: I botched initial release. If you downloaded either of the x86 Windows builds please make sure to re-download these files.

• Kill totals that take into account arch-vile revives and monsters spawned from scripts.  Cubic Worlds is an example of an Eternity WAD that does the latter.  I guess scripts mean that traditional kill counts are potentially impossible to calculate in advance, but increasing the monster total once a script spawns enemies could be enough.
• Make the -vanilla parameter persistent.  Currently, the option is reset when the player starts a new game or IDCLEVs.  I believe this is due to -vanilla being primarily designed for demo recording, but it would be nice to have for casual play as well.
• In a similar vein, quick toggles for various compatibility settings.  Obviously, I don't expect Eternity to have full complevel support.  However, an option to quickly switch the various compatibility settings to an equivalent of, say, GZDoom's Boom (strict) would be very nice.
• Search $DOOMWADDIR for WADs to load.  The Eternity wiki claims that Eternity searches $DOOMWADDIR for IWADs, but this does not seem to be the case for PWADs.
• -pistolstart, or an equivalent setting.  This is probably also possible through modding.

Strangely enough, the fade works fine when I set it to windowed mode. I wonder what is happening here? I'm playing on the latest devbuild.

Edit: It seems to only happen when I set the res to 1400 x 1050, 4:3. On Legacy Fullscreen at 1280 x 960, the fade also works correctly. It seems that this is the root of my problem?

The issue with this is obviously that it makes the resources list take forever to scroll through and it's a little cluttered for my liking. Does Eternity have a better system for usage of custom textures? I looked online and in some Eternity TCs but I wasn't really able to find anything conclusive.

I've fallen down the "Doom on Steam Deck" rabbit hole, and got GZdoom and ZDL working pretty seamlessly, but having trouble with some others

I have build a large UDMF map for the Eternity Engine with some portals and a big open area in the middle of the map.

As i stacked the last portal on top of the map i have got some issues with the farthest away places from point zero.

In these places i can not press switches, Walls behave like noclip is on and enemys are not shootable and i can walk through them.

In Ultimate DOOM Builder i had changed the nodebuilders to see if it changes something. But even the "ZDBSP - Compressed Nodes (UDMF) large maps" nodebuilder does not eliminate the problem.

As far as i understand this seems to be a blockmap overflow.

The Map Data can be seen at the attached screenshot.

 Is there anything i can do except make the map smaller or is there an option in Eternity Engine i do not know to fix this? 

Thanks in advance.

Well hi there. I just got done putting the final touches on my multithreaded renderer branch to make it actually usable! While I'd love to just sit on these changes forever and keep my mental state and blood pressure in check, I need people to actually test that I haven't introduced any extreme weirdness or crashes by making all these changes. To that end, it's time for a public beta! You may find the files at the bottom of the post, and the source is on the multithreaded-renderer-fixes branch if you wish to compile it yourself. In the meantime a brief explanation of the new settings and how to mess with them.

• r_numcontexts: Video Options > Page 2 > Renderer Threads. This does what it says on the tin. The higher the number, the more render contexts there are. This number ranges from 1 to however many threads your CPU supports. The optimal number of threads will vary based on your CPU and how complex the scene you're rendering is. Do not assume that the highest number is the best.
  • Note that this number is technically off by one if you're talking about threads. It spawns one fewer than the number of contexts, because one context is actually run on the main thread.
  • Separately implemented from this, if you only have one render thread then the whole system acts as it used to. Everything is executed on the main thread.
• r_sprprojstyle: Video Options > Page 2 > Sprite Projection Style. This has three settings, Default, Fast, and Thorough.
  • Default means Fast for 1 thread, or Thorough for more than 1 thread.
  • Fast is the classic Doom sprite projection style—if a subsector isn't visible in a given render context then it won't be renderered. This may cause sprites to have a cut-off appearance between the boundaries of render context windows. As the setting implies though, it is a fair bit faster than the Thorough setting.
  • Thorough will (generally) eliminate the issues seen in Fast. It works by not just considering sprites that have their centre in the sector being renderered, but anything whose hitbox (yes, it's based on hitbox radius instead of sprite size) is within the rendered sector. Previously-drawn sprites that frame are then cached to avoid redrawing. Though this can cause a reduction in performance in more heavy scenes compared to Fast, in your average vanilla WAD you're not likely to notice much of a difference.

It's not in the menus, but if you want to compare FPS between settings you will want to set `d_drawfps` to `on`. If you have any scenes where the rendering glitches out where it didn't previously then the ideal thing to provide would be your resolution, number of contexts, any savegames that have the exact frame where the glitch is happening, and the WADs you're running it with. Crashes are much the same as above, though obviously you can't provide a save; the crash report application will give you further instruction on how best to report crashes.

BUILDS:

2023-05-01: Windows (x64)

2023-04-30: Windows (x64)

2023-04-29: macOS (x64), macOS (Apple Silicon)

2023-04-28: Windows (x64)

NOTE: There's no load balancing yet because I'm so tired, dude, just so tired. I just wanna show this off now that it seems mostly done. I was worried this was gonna take another year or so of off-and-on work but nope, it's working just fine seemingly.

You can thank GooberMan for this existing at all. Without Rum & Raisin doom I wouldn't ever have managed this.

Since the macOS development builds from DRDTeam macOS fail to be made without any possible explanation (empty log files), I've decided to try my own at providing macOS development builds.

You get them from my DropBox space.

Here's a list of caveats

1. The most recent build is at the bottom! Scroll down and pick the one with the latest date. 
2. The app packages are not signed at all. To be able to start them, you need to right click the app file in Finder and click "Open". Afterwards they'll work from double-clicking too.
3. I'm doing this from my MacBook Pro laptop using a daily Automator job, so it may be just as shabby as you'd expect. You will not get any updates if my Mac is turned off. Hopefully it will work each time it's woken up. I use it frequently enough.

But unless I've missed an option somewhere, there's no way to view the ammo counts of weapons not currently equipped like with the vanilla status bar. For me this ends up impacting gameplay quite a bit, as I'm not great at tracking ammo pickups in the back of my mind.

My suggestion would be to add an option to replace the kills/items/secrets bit of HUD with a similar bit displaying bullets/shells/rockets/cells, or better yet, make it configurable which HUD element appears in which corner like with the 'distributed' HUD.

Apologies if this isn't the place to make suggestions, and I know what I'm asking for isn't an immediate fix, but I really do love the modern HUD and would like to use it more often, so I hope you consider adding this option at some point down the road. Thank you to the devs for all the work you're already doing, EE has become my favorite SP over the last couple years :)

I actually first encountered this bug a while ago when a map I was working on was reliably blowing up AutoDoom, but I only just got around to investigating the cause and narrowed it down to one particular staircase. EV_BuildStairs() handles such cases implicitly by aborting if the next sector is already engaged in an action (including the stairbuilding action itself), but as far as I can tell the bot doesn't check for this at all when routing the map and just goes into an infinite loop.

Example map:

stairbug.wad.zip (Doom 2 MAP01)

I've shared it here as part of my MimicHUD mod.

Now I'm planning to publish it on GitHub.

Since it uses lumps taken from here:

https://github.com/team-eternity/eternity/tree/master/base/doom/res/graphics/newhud

I'm here to ask for permission and for details about the licensing I should use.

GitHub shows that your project uses GPL3 and a custom license.

Which one covers the assets I've used?

Thank you!

I know about linedef 242 for Eternity (Doom) which follows SMMU rules which means the colormap only applies there.

Is there a control, or a booleen in UDMF that is like linedef 242?

Maybe a fix that forces Eternity into OpenGL ( not really preferable )

Thanks for any help

Doomguy will not stop shooting once he starts.

I have fire bound to RT and the only way I could stop was to open the menu, but even then it starts again once I shoot.

Affects all weapons

It also stops rarely for a second and then starts up again if I press RT down hard apparently.

Finally got around playing through Ancient Aliens. Chose Eternity to get those sweet ACS sound effects and I'm having a blast so far.

One problem tho: I get a random glitch where audio seemingly "desyncs" and the game just starts gutting the MIDIs. It sounds as if the sound engine is tripping on itself and racing to catch back up. This is not consistent and I cannot easily reproduce it. It will only work normally again after a system restart.

There is also another issue: ENDOOM does not show up sometimes - instead, I get a black screen. I don't think these issues are related, since I can have one without the other (although all instances of the audio issue have being accompanied by the ENDOOM issue as well).

Any ideas on what might be happening here? Any help is appreciated.

Additional info below:

• Using Windows 10.
• I'm on the August 12 DRD build for 64-bit systems (Eternity-x64-4.03.00-pre-818-ga917fc13).
• Running Eternity through Doom Launcher.
• Issues are not Ancient Aliens related. Been able to reproduce them in Ultimate Doom as well.
• I use Virtual MIDI Synth with the Griefus SC-55 soundfount.

Cheers

However, both of them fail to run, with the error message implying it's actually a x64 app.

Bothered to check the actual Renderer Resolution, its about 420x640ish. Also I tried to mess up with the Renderer Resolution, and the result is:

My system is Linux Mint 21.0 and I cloned the repo and built EE from source. Created a package with cpack just to see where it likes to be installed, and it's happy with /usr/local for the system and ~/.config/eternity for user data. Like this, it works fine.

However, my gaming files are highly organised and normally an engine's ~/.config/whatever is a symlink to somewhere else where my game management scripts keep everything organised. If I do this, so ~/.config/eternity is a symlink to another directory in my user space, it can't read anything of mine and sets the user dir to the install dir. Copy of the log file below.

I'm not (yet) familiar with the source code enough to know where to start looking, but it looks as if EE is trying to physically create the directory ~/.config/eternity even if it exists and fails if it can't, because there's a regular file of the same name there; now on Linux, that file could be (and in my case is) a symbolic link and EE is supposed to follow the link to the target directory.

Clearly it isn't doing this, so can anything be done?

Log file if ~/.config/eternity is a directory (this works):

The Eternity Engine
Copyright 2022 James Haley, Stephen McGranahan, et al.
http://www.doomworld.com/eternity

This program is free software distributed under the terms of
the GNU General Public License. See the file "COPYING" for
full details. Commercial sale or distribution of this product
without its license, source code, and copyright notices is an
infringement of US and international copyright laws.

Z_Init: Init zone memory allocation daemon.
Base path set to install directory.
User path set to home directory.
M_LoadSysConfig: Loading system.cfg
Warning: Cannot read /home/martin/.config/eternity/user/system.cfg -- using built-in defaults
D_DoIWADMenu: Init IWAD choice subsystem.
IWAD found: /usr/share/doom/doom.wad
Ultimate DOOM version

Built on Aug 14 2022 at 21:44:51
M_LoadDefaults: Load system defaults.
Warning: Cannot read /home/martin/.config/eternity/user/doom/eternity.cfg -- using built-in defaults
W_Init: Init WADfiles.
 adding /usr/local/share/eternity/base/doom/eternity.pke
 adding /usr/share/doom/doom.wad

E_ProcessEDF: Loading root file /usr/local/share/eternity/base/root.edf
V_InitMisc: Init miscellaneous video patches.
C_Init: Init console.
I_Init: Setting up machine state.
I_InitSound: Configured audio device with 2048 samples/slice.
I_InitMusic: Using SDL_mixer.
D_SetGraphicsMode: Set graphics mode
 (using video driver 'SDL GL2D')

Log file if ~/.config/eternity is a symlink to a directory (this doesn't):

The Eternity Engine
Copyright 2022 James Haley, Stephen McGranahan, et al.
http://www.doomworld.com/eternity

This program is free software distributed under the terms of
the GNU General Public License. See the file "COPYING" for
full details. Commercial sale or distribution of this product
without its license, source code, and copyright notices is an
infringement of US and international copyright laws.

Z_Init: Init zone memory allocation daemon.
Base path set to install directory.
User path set to base directory (warning: writes may fail!).
M_LoadSysConfig: Loading system.cfg
Warning: Cannot read /usr/local/share/eternity/base/system.cfg -- using built-in defaults
D_DoIWADMenu: Init IWAD choice subsystem.
IWAD found: /usr/share/doom/doom.wad
Ultimate DOOM version

Built on Aug 14 2022 at 21:44:51
M_LoadDefaults: Load system defaults.
Warning: Cannot read /usr/local/share/eternity/base/doom/eternity.cfg -- using built-in defaults
W_Init: Init WADfiles.
 adding /usr/local/share/eternity/base/doom/eternity.pke
 adding /usr/share/doom/doom.wad

E_ProcessEDF: Loading root file /usr/local/share/eternity/base/root.edf
V_InitMisc: Init miscellaneous video patches.
C_Init: Init console.
I_Init: Setting up machine state.
I_InitSound: Configured audio device with 2048 samples/slice.
I_InitMusic: Using SDL_mixer.
D_SetGraphicsMode: Set graphics mode
 (using video driver 'SDL GL2D')
Warning: could not write defaults to /usr/local/share/eternity/base/tmpetern.cfg: Permission denied
/usr/local/share/eternity/base/doom/eternity.cfg left unchanged
Warning: could not write defaults to /usr/local/share/eternity/base/tmpetern.cfg: Permission denied
/usr/local/share/eternity/base/system.cfg left unchanged