Doomsday Engine

The most likely reason for this crash is that the way we do antialiasing in 1.14 is not compatible with the Intel GPU you have. I recommend trying to launch with the "-nofsaa" option. When using the frontend, you can add this option in Settings > Developer > Custom options.

Hm, probably I just have to wait until I buy a decent desktop; the doomsday.out is almost the same except the additional command.

Application path: D:\rest\Games\Doom\Doomsday\Bin\Doomsday.exe
Created a new 32.0 MB memory volume.
Executable: Doomsday Engine 1.14.5 (Stable 32-bit #1265) Jun 19 2014 13:11:35
Command line options:
0: ..\Bin\Doomsday.exe
1: -basedir
2: D:\rest\Games\Doom\Doomsday/
3: -sfxchan
4: 16
5: -notexcomp
6: -game
7: doom1-ultimate
8: -iwad
9: D:\DOOM.WAD
10: -nofsaa
11: -userdir
12: C:\Users\Incantator\Documents\Doomsday Frontend\runtime/
RenderSystem: Loading shader definitions from read-only archive entry "data/renderer.pack/
shaders.dei" [path "/data/doomsday.pk3/data/renderer.pack/shaders.dei"]
from archive in read-only "(basedir)\data\doomsday.pk3"

And it still crashes.

Did you try the unstable 1.15.0? We've fixed some potential causes for a startup crash.

I've just tried it, yet with the same result:

Application path: D:\rest\Games\Doom\Doomsday1\Bin\Doomsday.exe
Created a new 32.0 MB memory volume.
Executable: Doomsday Engine 1.15.0 [#1503] (Unstable 32-bit) Feb 12 2015 14:46:56
Command line options:
0: ..\Bin\Doomsday.exe
1: -basedir
2: D:\rest\Games\Doom\Doomsday1/
3: -sfxchan
4: 16
5: -notexcomp
6: -game
7: doom1-ultimate
8: -iwad
9: D:\rest\Games\Doom\Doomsday1\bin\DOOM.WAD
10: -userdir
11: C:\Users\Incantator\Documents\Doomsday Frontend\runtime/
RenderSystem: Loading shader definitions from read-only archive entry "renderer.pack/
shaders.dei" [path "/data/net.dengine.client.pack/renderer.pack/
shaders.dei"] from archive in read-only "(basedir)\data\
net.dengine.client.pack"
^ : Loading shader definitions from read-only archive entry "renderer.pack/
lensflares.pack/shaders.dei" [path "/data/net.dengine.client.pack/renderer.pack/
lensflares.pack/shaders.dei"] from archive in read-only "(basedir)\data\
net.dengine.client.pack"

This is slightly different from previous, though. Same with the -nofsaa option.

Ok, what if you also add the "-vvv" option in 1.15.0? This will produce a lot more log output that may contain some hints for us. Please use http://pastebin.com/ (or similar) or attach the log here as a file.

Incantator wrote:

I've just tried it, yet with the same result:

Application path: D:\rest\Games\Doom\Doomsday1\Bin\Doomsday.exe
Created a new 32.0 MB memory volume.
Executable: Doomsday Engine 1.15.0 [#1503] (Unstable 32-bit) Feb 12 2015 14:46:56
Command line options:
0: ..\Bin\Doomsday.exe
1: -basedir
2: D:\rest\Games\Doom\Doomsday1/
3: -sfxchan
4: 16
5: -notexcomp
6: -game
7: doom1-ultimate
8: -iwad
9: D:\rest\Games\Doom\Doomsday1\bin\DOOM.WAD
10: -userdir
11: C:\Users\Incantator\Documents\Doomsday Frontend\runtime/
RenderSystem: Loading shader definitions from read-only archive entry "renderer.pack/
shaders.dei" [path "/data/net.dengine.client.pack/renderer.pack/
shaders.dei"] from archive in read-only "(basedir)\data\
net.dengine.client.pack"
^ : Loading shader definitions from read-only archive entry "renderer.pack/
lensflares.pack/shaders.dei" [path "/data/net.dengine.client.pack/renderer.pack/
lensflares.pack/shaders.dei"] from archive in read-only "(basedir)\data\
net.dengine.client.pack"

This is slightly different from previous, though. Same with the -nofsaa option.

Incantator wrote:

Sure, here is the log file.

Thanks! From the looks of it, the next thing that should be happening is that the main window appears and OpenGL drawing begins. I wonder if an older stable release like 1.12.2 works on your computer, since there the OpenGL rendering was still done in a simpler manner.

By the way, I've noticed that as I install it, Avira detects a file as an adware. It seems to be related with C++ 2013 redistributable, but I don't know what it is exactly and why it is detected as a virus.

The Visual C++ redistributable contains a couple of supporting libraries by Microsoft. Could be a false positive from Avira?

skyjake wrote:

Incantator wrote:

Sure, here is the log file.

Thanks! From the looks of it, the next thing that should be happening is that the main window appears and OpenGL drawing begins. I wonder if an older stable release like 1.12.2 works on your computer, since there the OpenGL rendering was still done in a simpler manner.

Thanks. I think I just have to get a desktop next time. Hoped it to be helpful to developers but I think we just ended up the same conclusion as before haha. Thanks for taking time with this problem.

By the way, I've noticed that as I install it, Avira detects a file as an adware. It seems to be related with C++ 2013 redistributable, but I don't know what it is exactly and why it is detected as a virus.

The Visual C++ redistributable contains a couple of supporting libraries by Microsoft. Could be a false positive from Avira?

I think so. I was just wondering if it has something to do with this problem.

I have the same graphics card (Mobile Intel 4 Series Express Chipset Family) and exactly the same issue. I have figured out that the newest version of Doomsday which works is 1.10.4. It seems that the problem is that the OpenGL driver returns that the version 2.1 is supported while in fact only the version 1.1 is supported. Hopefully my info will help you to fix that issue.

Thanks for the info. It might also help to see dxdiag info for your driver and chipset if you can, see here: https://na.wargaming.net/support/Knowledgebase/Article/View/26/18/what-is-a-dxdiag-file--how-do-i-send-one

That is the message which I get when I try to run Doomsday 2 build 1709 (Sep 6, 2015):

Application path: C:\Program Files (x86)\Doomsday 2.0.0\bin\Doomsday.exe
Created a new 32.0 MB memory volume.
Config::read: /packs/net.dengine.stdlib/modules/Config.de is newer than modules/Config,
rerunning the script
^ : Detected new build: 1459 => 1709
Executable: Doomsday Engine 2.0.0 [#1709] (Unstable 32-bit) Sep 6 2015 03:49:36
Command line options:
0: C:\Program Files (x86)\Doomsday 2.0.0\bin\Doomsday.exe
RenderSystem: Loading shader definitions from read-only archive entry "renderer.pack/
shaders.dei" [path "/data/net.dengine.client.pack/renderer.pack/
shaders.dei"] from archive in read-only "(basedir)\data\
net.dengine.client.pack"
^ : Loading shader definitions from read-only archive entry "renderer.pack/
lensflares.pack/shaders.dei" [path "/data/net.dengine.client.pack/renderer.pack/
lensflares.pack/shaders.dei"] from archive in read-only "(basedir)\data\
net.dengine.client.pack"
(getAllOpenGLEntryPoints) Required OpenGL function missing: glBindFramebuffer
Application terminated due to exception:
(getAllOpenGLEntryPoints) Required OpenGL function missing: glBindFramebuffer

Restoring original display mode due to shutdown

According to this website: https://www.opengl.org/sdk/docs/man/html/glBindFramebuffer.xhtml the function glBindFramebuffer is supported from version 3.0 of OpenGL. It would be great if you manage to replace that function by something supported by OpenGL 2.0 (or 2.1).

Yeah, those functions should be accessed via the extensions (e.g., EXT_framebuffer_object).

Support for FBOs is required, though, either via normal or extension functions.

Ok. The build 1710 gives the following error:

Application path: C:\Program Files (x86)\Doomsday 2.0.0\bin\Doomsday.exe
Created a new 32.0 MB memory volume.
Config::read: /packs/net.dengine.stdlib/modules/Config.de is newer than modules/Config,
rerunning the script
^ : Detected new build: 1459 => 1710
Executable: Doomsday Engine 2.0.0 [#1710] (Unstable 32-bit) Sep 7 2015 03:48:05
Command line options:
0: C:\Program Files (x86)\Doomsday 2.0.0\bin\Doomsday.exe
RenderSystem: Loading shader definitions from read-only archive entry "renderer.pack/
shaders.dei" [path "/data/net.dengine.client.pack/renderer.pack/
shaders.dei"] from archive in read-only "(basedir)\data\
net.dengine.client.pack"
^ : Loading shader definitions from read-only archive entry "renderer.pack/
lensflares.pack/shaders.dei" [path "/data/net.dengine.client.pack/renderer.pack/
lensflares.pack/shaders.dei"] from archive in read-only "(basedir)\data\
net.dengine.client.pack"
GLFramebuffer: Required GL_ARB_framebuffer_object is missing!
^ : Texture-based framebuffer failed: [ConfigError] (GLTarget::validate) Incomplete
attachments
Trying fallback without depth/stencil texture
(GLTarget::validate) Incomplete attachments
Application terminated due to exception:
(GLTarget::validate) Incomplete attachments

Restoring original display mode due to shutdown

It seems that GL_ARB_framebuffer_object is supported from version 3.0 of OpenGL. If you look at the report generated by OpenGL Extensions Viewer 4.3.8 (which I attached some time ago in the file files.zip) then you will see that what is supported by my card is GL_EXT_framebuffer_object. I found on the internet ( https://www.opengl.org/discussion_boards/showthread.php/177252-Regarding-GL_EXT_framebuffer_object ) that GL_ARB_framebuffer_object and GL_EXT_framebuffer_object are quite similar. Will it be possible to use GL_EXT_framebuffer_object instead of GL_ARB_framebuffer_object in the doomsday project? It would be really great.

BTW. Do you know that project: https://www.opengl.org/sdk/tools/GLIntercept/ ? It seems it allows to "emulate" old versions of OpenGL for debugging purposes.

I do not know if it helps but let me share it with you. I edited deng_gui.dll and changed ARB to EXT at offset 0x25dd27 (ie I changed GL_ARB_framebuffer_object to GL_EXT_framebuffer_object). It did not fix the problem (of course) but now the error message is slightly different:

Application path: C:\Program Files (x86)\Doomsday 2.0.0\bin\Doomsday.exe
Created a new 32.0 MB memory volume.
Config::read: /packs/net.dengine.stdlib/modules/Config.de is newer than modules/Config,
rerunning the script
^ : Detected new build: 1459 => 1710
Executable: Doomsday Engine 2.0.0 [#1710] (Unstable 32-bit) Sep 7 2015 03:48:05
Command line options:
0: C:\Program Files (x86)\Doomsday 2.0.0\bin\Doomsday.exe
RenderSystem: Loading shader definitions from read-only archive entry "renderer.pack/
shaders.dei" [path "/data/net.dengine.client.pack/renderer.pack/
shaders.dei"] from archive in read-only "(basedir)\data\
net.dengine.client.pack"
^ : Loading shader definitions from read-only archive entry "renderer.pack/
lensflares.pack/shaders.dei" [path "/data/net.dengine.client.pack/renderer.pack/
lensflares.pack/shaders.dei"] from archive in read-only "(basedir)\data\
net.dengine.client.pack"
GLFramebuffer: Texture-based framebuffer failed: [ConfigError] (GLTarget::validate)
Incomplete attachments
Trying fallback without depth/stencil texture
(GLTarget::validate) Incomplete attachments
Application terminated due to exception:
(GLTarget::validate) Incomplete attachments

Restoring original display mode due to shutdown

Thanks for the details. Indeed it should be checking for the EXT_framebuffer_object extension rather than ARB. I'll change that and see if there are other alternatives for configuring the framebuffer to get around that attachments error.

@Drako: Could you post an updated log with -vvv, please? It would help to see more detail about what is happening after "GLFramebuffer: Texture-based framebuffer failed".

Seeing as all of the fallback configurations failed, it leads me to suspect that your GPU and/or OpenGL drivers actually are not capable of supporting the way Doomsday does its rendering in version 1.11 onwards.

Furthermore, we are soon planning to require OpenGL 3.3 in the unstable builds. I was hoping to find a workaround that could be applied in the 1.15 branch for this issue, where the requirement is OpenGL 2.1, however this doesn't look very good.

If the OpenGL Extensions Viewer app shows these for you, could you check what is supported in the Pixel Formats tab under Color Buffer Modes, Depth Buffer Modes, and Stencil Buffer Modes?

Hmm, I can't see the information I was looking for in those. However, I've added a couple of further fallbacks to the FBO setup. Let's see if they allow the engine to launch. If so, we can then look into working around the visual artifacts caused by the potentially missing FBO capabilities.

This is the 2.0 branch, which means resource packs aren't fully supported at the moment (short answer: you currently need to load them manually using command line options). For more information, see the blog post: http://dengine.net/forums/viewtopic.php?f=24&t=2019

I think it's better that we apply these OpenGL changes to the 1.15 branch where you can use the Doomsday Frontend (Snowberry) to load resource packs like before. Also as I mentioned, the 2.0 branch will require OpenGL 3.3 soon.

Ok. Thanks. I am looking forward new build of 1.15.4.