Doomsday Engine

As is my understanding, Dday currently has 4 separate start up issues; AA, shader, Snowberry and mobj list.

I'm currently have an random, but regular occurrences in the latest unstable (1385) where Dday won't start and doesn't even create an out file. In this instance, Dday is getting as far as creating the conflicts.log in order to decide whether any of the loaded add-ons conflict (and it log's that none do).

This should be re-tested with all the recent threading-related fixes.

I'm afraid that with build 1399 I'm personally still finding Dday will very often not start through Snowberry or even create an out file (Snowberry creates a conflict.log file though every time).

One thing I will say is that I regularly change the loaded pwads/mods/game mode (or install the latest versions of pwads I am working on (i.e overwrite) in snowberry before launching.

vermil wrote:

Dday will very often not start through Snowberry

Do you mean the behaviour is still random, so that after it fails to start, it will still launch successfully on a subsequent try, with the exact same configuration/Snowberry settings?

It is still random yes, though a lot more common with 1.15 I believe.

Upon pressing play, I get a loading cursor appear for a few seconds and looking in my task manger, Dday does appear in it for a few seconds before disappearing on it's own.

I nearly always load various pwads/mods for testing or playing and always use Snowberry because I find that makes pwad/mod loading easiest.

I don't know if it matters, but since 1.15 I've noticed Dday will hang for a couple of seconds when quitting a game mode (a black screen when quitting Dday completely or simply hanging on the loading screen after ring zero loading appears to have completed).

vermil wrote:

I don't know if it matters, but since 1.15 I've noticed Dday will hang for a couple of seconds when quitting a game mode (a black screen when quitting Dday completely or simply hanging on the loading screen after ring zero loading appears to have completed).

At least for me on the Mac these hangs were fixed by 2027a13e6b0e7ae, included in build 1402.

skyjake wrote:

vermil wrote:

I don't know if it matters, but since 1.15 I've noticed Dday will hang for a couple of seconds when quitting a game mode (a black screen when quitting Dday completely or simply hanging on the loading screen after ring zero loading appears to have completed).

At least for me on the Mac these hangs were fixed by 2027a13e6b0e7ae, included in build 1402.

Indeed, they do seem fixed in 1402; Dday appears to start (i.e appear on the screen), unload and quit a lot lot faster. Very good job.

Now there is only a fraction of a second pause or black screen when Dday first enters Ring Zero or a game after engine start up.

Touch wood, I've also not yet had any issues with Dday failing to start anymore since upgrading to 1402 from 1399 (from half dozen start's to test).

EDIT: Spoke too soon. I just got one.

Just pushed another fix for a bug that was causing random crashes during startup. Hopefully this was the only one.

I can report that following the last fix, that I no longer get the crash I was talking about when starting Dday (I've waited a while before reporting in, to see if one occurred).

Obviously, the shader bug this issue was originally still about may still occur (it's not a bug I've personally ever experienced, so I can't comment on it)

Although I don't run Doomsday on Windows very often, I've also stopped having crashes at launch.

vermil wrote:

As is my understanding, Dday currently has 4 separate start up issues; AA, shader, Snowberry and mobj list.

The AA problems are being addressed by disabling FSAA by default, and in the longer term using OpenGL 3.3/4 with officially supported render-to-texture-with-AA features. I don't have any further actions for 1.15 on my todo list regarding AA.

I'm guessing by "shader" you mean the originally reported issue, which I have never reproduced on any system. I have no action plan for this.

What are the Snowberry and mobj list issues, though? Perhaps they need separate reports in the tracker?

1. The Snowberry issue was what I called the crash I was getting above (it was a bug in Dday's start up that only seemed to manifest itself for me, when I ran Dday through Snowberry with multiple add-on's loaded), that now appears to be fixed.

2. The shader issue is a crash several users have reported about Dday crashing at startup with "Loading shader definitions from read-only archive entry "renderer.pack/
shaders.dei" [path "/data/net.dengine.client.pack/renderer.pack/", being the last line in the out file.

Sometimes it's been discovered that the OpenGL version of users experiencing this crash wasn't sufficient for running Dday on and co-incidently, the next part of Dday's start up is the OpenGL check (why isn't the OpenGL check both done before shaders are loaded or detailed in the out file in default level verbosity?).

I personally don't experience this crash.

3. The mobj list crash was something DaniJ mentioned to me as both another possible crash and also a possible alternative reason for the crash mentioned in 2.

4. AA, you have detailed above. Thinking about it now, could this also be the cause of 2.

So I suppose there may not actually be 4 separate start up issues, but possibly only 2, one of which appears to have been fixed.

The only remaining issue that I'm seeing from the original report is the delayed minimum OpenGL version check. You are absolutely correct that Doomsday should be testing this long before attempting to compile any shaders.

danij wrote:

The only remaining issue that I'm seeing from the original report is the delayed minimum OpenGL version check. You are absolutely correct that Doomsday should be testing this long before attempting to compile any shaders.

The OpenGL version check is done as the first thing after the window has materialized, i.e., as soon as the OpenGL context is available. The shaders are not compiled at this time, only much later when somebody attempts to draw geometry. Note that the log entry is about reading the shader definitions, not compiling the shaders themselves.

Also, when we upgrade to OpenGL 3.3, the version will be selected explicitly. In this case, OpenGL will fail to initialize if the right version isn't supported, removing the need for a post-initialization check.

I didn't state or assume otherwise. My only intention was to draw attention to a point raised earlier - the apparent compiling of shaders before the OpenGL version check and caps listing in the log.

My perspective on this is - why is Doomsday even processing those definitions when the renderer has not even been set up yet?

I have a feeling the FBO setup improvements done in #1977 will help with this issue as well.