Appreciation from a longtime lurker

[PunishedDoomGuy]

Hey folks hopefully fpbp, just wanted to show some love for Eternity Engine after I'd decided to pick it as my port-of-choice for tackling my first UV runs of Ultimate Doom+e1m4b.wad+e1m8b.wad+Sigil and Doom 2+nerve.wad after 20+ years of port-hopping since the days of glDoom & Doom Legacy.

This port is so low-key for the polish and what it provides, I came on to it after temporarily settling on PrBoom-plus but looking for alternatives for better performance at 1440p and a bit less jank, for me it's the most consistent Doom software renderer performance-wise after gl_arb_pixelbuffer and d_fastrefresh are enabled (why are these not default?!)

 

Half-way through Plutonia now and I gotta say she's a keeper, only takes a few tweaks of the compatibility options to make it behave exactly as Doom should, got a couple recommendations to provide but I don't wanna throw around too much shade, what I feel this needs is some visibility and testimonials of more real-life end-users, there's a lot of us that don't post and keep silent.  Keep up the good work!

[seed]

7 hours ago, PunishedDoomGuy said:

after gl_arb_pixelbuffer and d_fastrefresh are enabled (why are these not default?!)

 

Now I'm curious, what do these do?

[PunishedDoomGuy]

2 hours ago, seed said:

 

Now I'm curious, what do these do?

If you haven't given this a spin, using the SDL GL2D video backend it'll enable async DMA via PBO, on my system this gave a BIG improvement to average frametime.

[seed]

1 hour ago, PunishedDoomGuy said:

If you haven't given this a spin, using the SDL GL2D video backend it'll enable async DMA via PBO, on my system this gave a BIG improvement to average frametime.

 

d_fastrefresh is already on in the latest devbuild, I think you're using an older version.

 

I turned on the other one and it seems to have made a bit of a difference (or it's just placebo).

[PunishedDoomGuy]

2 hours ago, seed said:

 

d_fastrefresh is already on in the latest devbuild, I think you're using an older version.

 

I turned on the other one and it seems to have made a bit of a difference (or it's just placebo).

I started off on an 4.0.0 and never ditched the config, if it's on by default now then that settles it, gl_arb_pixelbuffer should be made default.  

 

Now to my understanding the two compliment each other as per below:

 

* gl_arb_pixelbuffer (0 or 1)
Set to 1 (in addition to the above) to turn on the ARB pixel buffer object extension, which can accelerate updates 1.5-2x (but only if supported - EE will acknowledge at startup whether the extension was successfully initialized or not).

 

* d_fastrefresh (0 or 1)
Be sure this is set to 1 if you are going to use GL. GL does not like or need the main loop to be calling I_Sleep constantly; the vsync and ARB pixelbuffer asynchronous DMA transfers allow EE to run in parallel to the screen update process, so waiting is counter-intuitive.

[Altazimuth]

gl_arb_pixelbuffer is a weird one. I found one my system that when on it murdered performance. I forget exactly why. I had tried to remedy it, but was unable to.

[PunishedDoomGuy]

5 hours ago, Altazimuth said:

gl_arb_pixelbuffer is a weird one. I found one my system that when on it murdered performance. I forget exactly why. I had tried to remedy it, but was unable to.

Hmmmmm... what GPU you running, AMD?  On my GTX1080Ti it practically doubled my framerate to 200fps at 1440p, one thing though you gotta disable Threaded Optimisation otherwise wacky stuff happens if you're using midiproc.exe as the nVidia driver creates another thread on that process as well as eternity.exe.

[Altazimuth]

GTX 1070. I was not aware about the thing w/ midiproc.exe. I'll test that out; I wonder if there's a way to make sure end-users don't have to disable the threaded optimisation there.

 

Thanks for the tip.

[PunishedDoomGuy]

17 minutes ago, Altazimuth said:

GTX 1070. I was not aware about the thing w/ midiproc.exe. I'll test that out; I wonder if there's a way to make sure end-users don't have to disable the threaded optimisation there.

 

Thanks for the tip.

No worries, here's a PDF from nVidia with some example code that disables it via NVAPI:

 

http://developer.download.nvidia.com/tools/docs/PG-5116-001_v02_public.pdf

[Altazimuth]

Just to check, do you disable the threaded optimisations for just midiproc.exe, or both EE and midiproc? Based on docs (if I code this which is a big if since libraries AAAAAAAAAAA) I'd wanna set OGL_THREAD_CONTROL_DISABLE from EValues_OGL_THREAD_CONTROL. OGL_THREAD_CONTROL_STRING is the string for it.

Edited December 30, 2019 by Altazimuth

[PunishedDoomGuy]

28 minutes ago, Altazimuth said:

Just to check, do you disable the threaded optimisations for just midiproc.exe, or both EE and midiproc? Based on docs (if I code this which is a big if since libraries AAAAAAAAAAA) I'd wanna set OGL_THREAD_CONTROL_DISABLE from EValues_OGL_THREAD_CONTROL. OGL_THREAD_CONTROL_STRING is the string for it.

Only need to do it for eternity.exe as it's what's using OpenGL, as long as it's disabled for that then the nVidia driver won't create any other unnecessary threads at all for any other processes eternity.exe invokes.

[JBerg]

Eternity is my favourite of the available ports. The look and feel make it seem like an augmented Vanilla port rather than a re-implementation of the game like gzdoom

Edited January 27, 2020 by JBerg

[The Civ]

Eternity would definitely be my favorite too if it weren't for the bizarre V-Sync caused stuttering issue that plagues PrBoom+ too.
Love both ports, but both suffer the same issue. Enable it, and you'll notice that the video hitches ever so slightly if you slowly move your mouse left or right.

Even more noticeable if you use binded keys to slowly turn left or right. It's such a shame because I can't stand the screen tearing if V-Sync is disabled.

[PunishedDoomGuy]

4 hours ago, The Civ said:

Eternity would definitely be my favorite too if it weren't for the bizarre V-Sync caused stuttering issue that plagues PrBoom+ too.
Love both ports, but both suffer the same issue. Enable it, and you'll notice that the video hitches ever so slightly if you slowly move your mouse left or right.

Even more noticeable if you use binded keys to slowly turn left or right. It's such a shame because I can't stand the screen tearing if V-Sync is disabled.

This is The Civ?  G'day mate! 

 

You've got smooth_turning=1 in eternity.cfg also yeah?  In addition to the other steps in this thread you can try disabling 'Full Screen Optimizations' for eternity.exe AFTER making sure CSM is enabled in BIOS.

 

Otherwise you can try the latest binary release of PrBoom+/UMAPINFO v 2.5.1.7 here - it appears to have better frame-pacing for me albeit at lower FPS than Eternity or PrBoom+ 2.5.1.4, this build was compiled last year well before forced Borderless Fullscreen was added into the latest git commits which I'm not overly happy about (I'm running a G-Sync monitor.)

 

Only real issues I've got with last year's binary of Graf's fork (that have been later resolved in source) is the settings menu has an invisible cursor if you're running a WAD with custom fonts like Eviternity and crashing when changing graphics modes whilst full-screen.

[Redneckerz]

4 hours ago, PunishedDoomGuy said:

Only real issues I've got with last year's binary of Graf's fork (that have been later resolved in source) is the settings menu has an invisible cursor if you're running a WAD with custom fonts like Eviternity and crashing when changing graphics modes whilst full-screen.

Funny enough @fabian also submitted a patch for this in PrBoom+, so will it be double patched then?

 

The issue is also present in Woof, the WinMBF fork by him. When the new version comes out, it will likely be patched aswell.

[fabian]

The patches in PrBoom+:

https://github.com/coelckers/prboom-plus/commit/f2c2e495cadca13358d256522890b17b90c7a1a9

https://github.com/coelckers/prboom-plus/commit/f28580d14fa7c7a8b2354bf9ed15dd19af2805d6

 

And the patch in Woof!:

https://github.com/fabiangreffrath/woof/commit/2250d95b7f8b760fa8ebfea82b8638d36891f43b

 

Crashes in fullscreen mode should not happen anymore in Prboom+, as this now uses SDL2's fullscreen-desktop mode, which doesn't even change the screen's actual resolution anymore (at least in software rendering mode).

https://github.com/coelckers/prboom-plus/commit/0728a25e3b12735636f2a37449a46d28755995a2

[PunishedSnake]

16 hours ago, fabian said:

The patches in PrBoom+:

https://github.com/coelckers/prboom-plus/commit/f2c2e495cadca13358d256522890b17b90c7a1a9

https://github.com/coelckers/prboom-plus/commit/f28580d14fa7c7a8b2354bf9ed15dd19af2805d6

 

And the patch in Woof!:

https://github.com/fabiangreffrath/woof/commit/2250d95b7f8b760fa8ebfea82b8638d36891f43b

 

Crashes in fullscreen mode should not happen anymore in Prboom+, as this now uses SDL2's fullscreen-desktop mode, which doesn't even change the screen's actual resolution anymore (at least in software rendering mode).

https://github.com/coelckers/prboom-plus/commit/0728a25e3b12735636f2a37449a46d28755995a2

@fabian my concern here is the mandatory enforcement of fullscreen-desktop mode, I believe Exclusive Fullscreen should be left as an option for folks like myself with Varable Refresh Rate displays, nVidia G-Sync and AMD Freesync don't play ball well with fullscreen-desktop mode as its essentially borderless windowed to my understanding.

[Loud Silence]

On 1/28/2020 at 4:59 AM, The Civ said:

Eternity would definitely be my favorite too if it weren't for the bizarre V-Sync caused stuttering issue that plagues PrBoom+ too.
Love both ports, but both suffer the same issue. Enable it, and you'll notice that the video hitches ever so slightly if you slowly move your mouse left or right.

Even more noticeable if you use binded keys to slowly turn left or right. It's such a shame because I can't stand the screen tearing if V-Sync is disabled.

Are you using stable version? I had V-Sync performance issues in stable version, but no problems in latest devbuilds. https://devbuilds.drdteam.org/eternity/ My GPU is integrated ATI Radeon Xpress 200M (from around 2005). Interesting thing is that i never get screen tearing even without V-Sync.

[The Civ]

9 hours ago, Loud Silence said:

Are you using stable version? I had V-Sync performance issues in stable version, but no problems in latest devbuilds. https://devbuilds.drdteam.org/eternity/ My GPU is integrated ATI Radeon Xpress 200M (from around 2005). Interesting thing is that i never get screen tearing even without V-Sync.

I am, and it's even more befuddling because I'm using an RTX 2080. For Eternity, I've actually found a workaround though, that involves turning off V-Sync and enabling fullscreen windowed mode. Seems to eliminate screen tearing without needing the V-Sync that's causing the issues in the first place.

Could be a worthwhile feature for a future release of PrBoom+ if it's managed to fix the same problem here.

 

[Loud Silence]

@The Civ I recommend to check latest devbuild. I use devbuilds for very long time now, they are better than stable version from my experience. And i'm curious how V-Sync in devbuild will work for you.

[Altazimuth]

Will look into this, thanks! I'm working on something in the background that if it can be released might make the work not so applicable, but we'll see.

EDIT: Would anybody be willing to help test any fix I might have? I'm not bad at spotting vsync choppiness.

Edited January 29, 2020 by Altazimuth

[PunishedDoomGuy]

8 hours ago, Altazimuth said:

Will look into this, thanks! I'm working on something in the background that if it can be released might make the work not so applicable, but we'll see.

EDIT: Would anybody be willing to help test any fix I might have? I'm not bad at spotting vsync choppiness.

I'm down, PM me.

[seed]

16 hours ago, Altazimuth said:

Would anybody be willing to help test any fix I might have? I'm not bad at spotting vsync choppiness.

 

More like input lag ;) .

 

With uncapped framerate the input lag is noticeable in the daily builds as well, very similar to PrBoom.

[The Civ]

On 1/29/2020 at 12:27 PM, Loud Silence said:

@The Civ I recommend to check latest devbuild. I use devbuilds for very long time now, they are better than stable version from my experience. And i'm curious how V-Sync in devbuild will work for you.

Tested out the devbuild, and same result. Seems to be consistent across all versions of PrBoom and Eternity.

No other ports have carried this problem though, which is interesting to me. Must be something exclusive to how they handle V-Sync, and possibly how it reacts with certain NVidia drivers?
I've actually found a fork of PrBoom+ that allows for windowed fullscreen, which is a good temporary fix for me, but here's to hoping this workaround makes it into the main builds some day.