Summary
After install Dear Esther, selecting the game from the menu has no effect.
Steps to reproduce
1) Create /opt/games if it doesn't exist and grant permissions to current user.
2) Execute dearesther-linux-06082013-bin.
3) Set install location to /opt/games/dearesther.
4) After install completes, launch the game from the application menu.
Expected result
Game launches
Actual result
No action.
System details:
System: Lenovo Thinkpad x220
Memory: 16GB DDR3 RAM
Storage: 512GB Crucial M4 SSD
OS: Linux Mint 15 64-bit (3.8.0 kernel) with Cinnamon
Others notes
Running /opt/games/dearesther/Dear_Esther (the actual command used by the launcher in the applications menu) from the terminal outputs:
Dear Esther: Installed in '/opt/games/dearesther'.
There is no other output, and no application is launched.
When launching /opt/games/dearesther/dearesther_linux from the terminal, the following is output:
SDL video target is 'x11'
SDL video target is 'x11'
SDL video target is 'x11'
X Error of failed request: GLXBadFBConfig
Major opcode of failed request: 153 (GLX)
Minor opcode of failed request: 34 ()
Serial number of failed request: 176
Current serial number in output stream: 175
Exactly the same here.
Ubuntu 13.04 64-bit
Intel i5 3570 Ivybridge HD2500 Graphics
All of the 64-bit OpenGL libs with their 32-bit counterparts installed.
System do not have any SDL2 libs installed.
I get this on my Intel/Mesa machine (a Thinkpad X1 Carbon running Kubuntu 12.10 with xorg-edgers enabled and Mesa 9.20), but my nVidia (GeFore 9600GT/313.30) machine works fine.
Note that Mesa doesn't support GL>=3.1 compatibility profiles, only core profiles. Not sure that's it, though: patching SDL to always make SDL_GL_CONTEXT_PROFILE_MASK=SDL_GL_CONTEXT_PROFILE_CORE didn't fix it.
Logs and things below.
-- David
stdout/stderr:
$ LD_LIBRARY_PATH=./bin ./dearesther_linux -game dearesther
SDL video target is 'x11'
SDL video target is 'x11'
SDL video target is 'x11'
X Error of failed request: GLXBadFBConfig
Major opcode of failed request: 153 (GLX)
Minor opcode of failed request: 34 ()
Serial number of failed request: 176
Current serial number in output stream: 175
Relevant bits of xtrace:
001:<:00af: 24: GLX-Request(153,3): glXCreateContext context=0x04e0000c visual_id=33 screen=0x00000000 share_list=0x00000000 is_direct=1
001:<:00b0: 52: GLX-Request(153,34): glXCreateContextAttribsARB opcode=0x99 opcode2=0x22 unparsed-data=0x0d,0x00,0xe0,0x04,0x83,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x03,0x00,0x00,0x00,0x91,0x20,0x00,0x00,0x03,0x00,0x00,0x00,0x92,0x20,0x00,0x00,0x02,0x00,0x00,0x00,0x26,0x91,0x00,0x00,0x02,0x00,0x00,0x00;
001:>:00b0:Error 178=GLXBadFBConfig: major=153, minor=34, bad=81788939
SDL_GL_SetAttribute calls:
SDL_GL_SetAttribute (attr=SDL_GL_CONTEXT_MAJOR_VERSION, value=3) at ../src/video/SDL_video.c:2442
SDL_GL_SetAttribute (attr=SDL_GL_CONTEXT_MINOR_VERSION, value=2) at ../src/video/SDL_video.c:2442
SDL_GL_SetAttribute (attr=SDL_GL_CONTEXT_PROFILE_MASK, value=2) at ../src/video/SDL_video.c:2442
SDL_GL_SetAttribute (attr=SDL_GL_RED_SIZE, value=8) at ../src/video/SDL_video.c:2442
SDL_GL_SetAttribute (attr=SDL_GL_GREEN_SIZE, value=8) at ../src/video/SDL_video.c:2442
SDL_GL_SetAttribute (attr=SDL_GL_BLUE_SIZE, value=8) at ../src/video/SDL_video.c:2442
SDL_GL_SetAttribute (attr=SDL_GL_ALPHA_SIZE, value=8) at ../src/video/SDL_video.c:2442
SDL_GL_SetAttribute (attr=SDL_GL_DOUBLEBUFFER, value=1) at ../src/video/SDL_video.c:2442
SDL_GL_SetAttribute (attr=SDL_GL_DEPTH_SIZE, value=24) at ../src/video/SDL_video.c:2442
SDL_GL_SetAttribute (attr=SDL_GL_STENCIL_SIZE, value=8) at ../src/video/SDL_video.c:2442
SDL_GL_SetAttribute (attr=SDL_GL_ACCELERATED_VISUAL, value=1) at ../src/video/SDL_video.c:2442
SDL_GL_SetAttribute (attr=SDL_GL_RED_SIZE, value=0) at ../src/video/SDL_video.c:2442
SDL_GL_SetAttribute (attr=SDL_GL_RED_SIZE, value=0) at ../src/video/SDL_video.c:2442
SDL_GL_SetAttribute (attr=SDL_GL_RED_SIZE, value=0) at ../src/video/SDL_video.c:2442
SDL_GL_SetAttribute (attr=SDL_GL_RED_SIZE, value=0) at ../src/video/SDL_video.c:2442
SDL_GL_SetAttribute (attr=SDL_GL_RED_SIZE, value=0) at ../src/video/SDL_video.c:2442
SDL_GL_SetAttribute (attr=SDL_GL_RED_SIZE, value=0) at ../src/video/SDL_video.c:2442
SDL_GL_SetAttribute (attr=SDL_GL_RED_SIZE, value=0) at ../src/video/SDL_video.c:2442
SDL_GL_SetAttribute (attr=SDL_GL_RED_SIZE, value=0) at ../src/video/SDL_video.c:2442
Same error message here, on
System: Generic Intel Core2Duo Medion box
Memory: 8GB DDR3 RAM
Graphics: NVIDIA GeForce 8500GT
Storage: 1.5TB hard drives
OS: Linux Mint 15 64-bit (3.8.0 kernel) with MATE
I am using the Nouveau drivers (1:1.0.7-0ubuntu1) rather than the NVIDIA ones.
I do have the 32-bit OpenGL libraries
dpkg -l libgl1-mesa-glx:i386
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============-============-============-=================================
ii libgl1-mesa-gl 9.1.1-0ubunt i386 free implementation of the OpenGL
Same here on Fedora-19 Beta + SandyBridge (Intel HD2000):
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile
OpenGL core profile version string: 3.1 (Core Profile) Mesa 9.2.0
OpenGL core profile shading language version string: 1.40
mesa-libGL-9.2-0.7.20130528.fc19.x86_64
mesa-libGL-9.2-0.7.20130528.fc19.i686
[ce@localhost dearesther]$ ./Dear_Esther
Dear Esther: Installed in '/home/ce/Programme/dearesther'.
libGL error: failed to load driver: i965
libGL error: Try again with LIBGL_DEBUG=verbose for more details.
libGL error: failed to load driver: swrast
libGL error: Try again with LIBGL_DEBUG=verbose for more details.
SDL video target is 'x11'
SDL video target is 'x11'
SDL video target is 'x11'
X Error of failed request: GLXBadFBConfig
Major opcode of failed request: 152 (GLX)
Minor opcode of failed request: 34 ()
Serial number of failed request: 188
Current serial number in output stream: 187
(In reply to comment #6)
The Windows/Crossover version installed, but needed some packages installed first:
sudo dpkg -i ia32-dearesther_1.6-1_amd64_1369763765.deb
Selecting previously unselected package ia32-dearesther.
(Reading database ... 219971 files and directories currently installed.)
Unpacking ia32-dearesther (from ia32-dearesther_1.6-1_amd64_1369763765.deb) ...
dpkg: dependency problems prevent configuration of ia32-dearesther:
ia32-dearesther depends on libc6-i386; however:
Package libc6-i386 is not installed.
ia32-dearesther depends on lib32gcc1; however:
Package lib32gcc1 is not installed.
ia32-dearesther depends on lib32nss-mdns; however:
Package lib32nss-mdns is not installed.
ia32-dearesther depends on lib32z1; however:
Package lib32z1 is not installed.
ia32-dearesther depends on lib32asound2; however:
Package lib32asound2 is not installed.
dpkg: error processing ia32-dearesther (--install):
dependency problems - leaving unconfigured
Errors were encountered while processing:
ia32-dearesther
After doing that, it ran :) once :( and is now giving an Engine Error message after the logo animations:
"failed to lock vertex buffer in CMeshDX8::LockVertexBuffer"
(In reply to comment #9)
> After doing that, it ran :) once :( and is now giving an Engine Error
> message after the logo animations:
>
> "failed to lock vertex buffer in CMeshDX8::LockVertexBuffer"
Ah, if I delete .dearesther/dearesther/drive_c/Program\ Files/Dear\ Esther/dearesther/cfg/video.txt it will run (in the initial lower resolution) and let me put it back to 1920x1080.
So the hardware will run it... will having added those packages enable the native version to run?
Looks like a duplicate bug: https://bugzilla.icculus.org/show_bug.cgi?id=5967
Also having the "GLXBadFBConfig" issue on two computers. On both I installed Dear Esther to:
~/opt/dearesther (~ is /home/MYUSER/)
I used this version of native Linux Dear Esther:
dearesther-linux-06082013-bin.bin
==============================
Model: custom desktop pc
CPU: AMD Phenom(tm) II X4 955 Processor (4 cores, 3.2 Ghz)
RAM: 12 GB
GPU: Advanced Micro Devices [AMD] nee ATI RS880 [Radeon HD 4200]
OS: openSUSE 12.3
Kernel: 3.7.10-1.11-desktop (openSUSE 12.3 standard)
GPU driver: open source "radeon"
All software like openSUSE 12.3, except:
Mesa: 9.1.3-242.3
from http://download.opensuse.org/repositories/X11:/XOrg/openSUSE_12.3/
Those games run fine (native): Half-Life 1, Counter-Strike, SuperTuxKart, World of Goo
Those games run with little performance issues (native): Counter-Strike Source, Half-Life 2
Some glxinfo output line:
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD RS880
OpenGL core profile version string: 3.1 (Core Profile) Mesa 9.1.3
OpenGL core profile shading language version string: 1.40
OpenGL version string: 3.0 Mesa 9.1.3
game output:
------------------------------
# cd ~/opt/dearesther; LIBGL_DEBUG=verbose LD_LIBRARY_PATH=/lib:/usr/lib:~/opt/dearesther/bin force_s3tc_enable=true SDL_AUDIODRIVER=pulseaudio ~/opt/dearesther/dearesther_linux -game dearesther
libGL: OpenDriver: trying /usr/lib/dri/updates/tls/r600_dri.so
libGL: OpenDriver: trying /usr/lib/dri/updates/r600_dri.so
libGL error: dlopen /usr/lib/dri/updates/r600_dri.so failed (/usr/lib/dri/updates/r600_dri.so: cannot open shared object file: No such file or directory)
libGL: OpenDriver: trying /usr/lib/dri/tls/r600_dri.so
libGL: OpenDriver: trying /usr/lib/dri/r600_dri.so
libGL: Can't open configuration file /home/moritz/.drirc: No such file or directory.
libGL: Can't open configuration file /home/moritz/.drirc: No such file or directory.
libGL: Can't open configuration file /home/moritz/.drirc: No such file or directory.
libGL: Can't open configuration file /home/moritz/.drirc: No such file or directory.
SDL video target is 'x11'
SDL video target is 'x11'
SDL video target is 'x11'
libGL: Can't open configuration file /home/moritz/.drirc: No such file or directory.
X Error of failed request: GLXBadFBConfig
Major opcode of failed request: 154 (GLX)
Minor opcode of failed request: 34 ()
Serial number of failed request: 188
Current serial number in output stream: 187
==============================
==============================
Model: Lenovo ThinkPad X220
CPU: Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz (2 physical cores, 4 HyperThreading cores)
RAM: 8 GB
GPU: i7 integrated HD Graphics 3000
OS: openSUSE 12.3
Kernel: 3.9.5-1.g08531e3-desktop ( http://download.opensuse.org/repositories/Kernel:/stable/standard/ )
GPU driver: open source "radeon"
Those games run fine (native): Half-Life 1, Counter-Strike, SuperTuxKart, World of Goo, Counter-Strike Source, Half-Life 2
Some glxinfo output line:
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile
OpenGL version string: 3.0 Mesa 9.0.2
OpenGL shading language version string: 1.30
game output:
------------------------------
libGL: OpenDriver: trying /usr/lib/dri/updates/tls/i965_dri.so
libGL: OpenDriver: trying /usr/lib/dri/updates/i965_dri.so
libGL error: dlopen /usr/lib/dri/updates/i965_dri.so failed (/usr/lib/dri/updates/i965_dri.so: cannot open shared object file: No such file or directory)
libGL: OpenDriver: trying /usr/lib/dri/tls/i965_dri.so
libGL: OpenDriver: trying /usr/lib/dri/i965_dri.so
ATTENTION: default value of option force_s3tc_enable overridden by environment.
libGL: Can't open configuration file /home/moritz/.drirc: No such file or directory.
libGL: Can't open configuration file /home/moritz/.drirc: No such file or directory.
libGL: Can't open configuration file /home/moritz/.drirc: No such file or directory.
libGL: Can't open configuration file /home/moritz/.drirc: No such file or directory.
SDL video target is 'x11'
SDL video target is 'x11'
libGL: Can't open configuration file /home/moritz/.drirc: No such file or directory.
X Error of failed request: GLXBadFBConfig
Major opcode of failed request: 154 (GLX)
Minor opcode of failed request: 34 ()
Serial number of failed request: 175
Current serial number in output stream: 174
SDL video target is 'x11'
==============================
It doesn't work for me either with the latest r600g driver on Ubuntu 13.04 + Xorg Edgers:
$ ./dearesther_linux
SDL video target is 'x11'
SDL video target is 'x11'
SDL video target is 'x11'
X Error of failed request: GLXBadFBConfig
Major opcode of failed request: 154 (GLX)
Minor opcode of failed request: 34 ()
Serial number of failed request: 175
Current serial number in output stream: 174
$ glxinfo
(...)
OpenGL renderer string: Gallium 0.4 on AMD REDWOOD
OpenGL version string: 3.0 Mesa 9.2.0-devel
(...)
Whereas the Steam version of Portal works flawlessly. I also tried to replace libsdl2.so by a nightly build but same error.
Same error here with dearesther-linux-06082013-bin
I have Intel HD 3000 (on kernel 3.9.9):
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Desktop
OpenGL core profile version string: 3.1 (Core Profile) Mesa 9.1.4
OpenGL core profile shading language version string: 1.40
Same here:
SDL video target is 'x11'
SDL video target is 'x11'
SDL video target is 'x11'
X Error of failed request: GLXBadFBConfig
Major opcode of failed request: 154 (GLX)
Minor opcode of failed request: 34 ()
Serial number of failed request: 166
Current serial number in output stream: 165
Mesa:
OpenGL renderer string: Gallium 0.4 on AMD RV670
OpenGL core profile version string: 3.1 (Core Profile) Mesa 9.1.6
OpenGL core profile shading language version string: 1.40
uname:
Linux archmain.soldiner.lan 3.11.0-1-00027-ge4ef108-dirty #1 SMP PREEMPT Wed Aug 7 00:23:38 CEST 2013 x86_64 GNU/Linux
I got the same error on my notebook with a CPU internal Intel video card (Intel Core i3 / Sandybridge) and an NVIDIA Optimus card (NVIDIA GeForce GT 630M) on the ~amd64 tree of Gentoo with "multilib" in my USE flags.
So I thought I had every 32 bit dependencies installed. Nevertheless I got the GLXBadFBConfig error.
After checking the dependencies again it turned out that I hadn't had installed the 32 bit version of virtualgl since this isn't installed by the "multilib" USE flag but with ABI_X86="64 32" resp. the USE flag "abi_x86_32".
Since I reinstalled virtualgl with this USE flag the error disappeared and the game runs perfectly.
To cut a long story short, Dear Esther is a 32 bit software that needs 3D rendering. So people, who get this error, should check if they really have installed every dependency in a multilib resp. 32 bit version.
This includes not only OpenGL, but also the video card driver.
Most people here, who report this bug, seem to have a notebook, too. So if you have two video cards, at least an Intel and an NVIDIA Optimus card, make sure that you have installed bumblebee together with virtualgl and bbswitch (both should be installed as a dependency of bumblebee), that you have installed the 32 bit/multilib versions of opengl, the nvidia driver and of virtualgl.
Then start the game with the command `optirun dear-esther`, so that it gets rendered by the secondary NVIDIA card and not the primary Intel card. Optirun is part of bumblebee.
Btw., bumblebee works slightly better with the nvidia driver than with nouveau, and the nvidia driver gives much better performance in 3D rendering. I tried both.
(In reply to comment #6)
> Same error message here, on
>
> System: Generic Intel Core2Duo Medion box
> Memory: 8GB DDR3 RAM
> Graphics: NVIDIA GeForce 8500GT
> Storage: 1.5TB hard drives
> OS: Linux Mint 15 64-bit (3.8.0 kernel) with MATE
>
> I am using the Nouveau drivers (1:1.0.7-0ubuntu1) rather than the NVIDIA
> ones.
.. and, having chosen to install the 32-bit system on a new PC to increase my chances of actually being able to play this, I get exactly the same error.
System: Zoostorm AMD A8 5500 3.2GHz APU
Memory: 8GB DDR3 RAM
Graphics: AMD Radeon HD7560D onboard
Storage: 3.5TB hard drives
OS: Linux Mint 15 32-bit (3.8.0 kernel) with MATE
So, different graphics hardware, different CPU, different all 32-bit build of the OS.
Argh.
I will try the Codeweavers version on this PC, but argh the combination of a very different system having the same error *and* the total lack of any visible movement on these issues is all very, very disappointing.
(In reply to comment #20)
> > I am using the Nouveau drivers (1:1.0.7-0ubuntu1) rather than the NVIDIA
> > ones.
>
> .. and, having chosen to install the 32-bit system on a new PC to increase
> my chances of actually being able to play this, I get exactly the same error.
>
> System: Zoostorm AMD A8 5500 3.2GHz APU
> Memory: 8GB DDR3 RAM
> Graphics: AMD Radeon HD7560D onboard
> Storage: 3.5TB hard drives
> OS: Linux Mint 15 32-bit (3.8.0 kernel) with MATE
1. AMD Radeon doesn't work with the nouveau driver. You need either the radeon driver or the proprietary fglrx. But you won't have better luck with the radeon driver, particularly with this video card. So try fglrx.
2. If you really have an additional NVIDIA card you may have more luck with the proprietary nvidia driver than with nouveau.
3. If you have an NVIDIA Optimus card, you need bumblebee and virtualgl, too.
Apologies for the confusion - this is a new PC with very different hardware and I know that the nouveau driver won't do Radeon.
This is with the xserver-xorg-video-ati 1:7.0.0ubuntu2
If I use the fglrx 2:9.010-0unbuntu3 driver, it doesn't even get that far:
$ ./dearesther_linux
SDL video target is 'x11'
SDL video target is 'x11'
SDL video target is 'x11'
This system supports the OpenGL extension GL_EXT_framebuffer_object.
This system supports the OpenGL extension GL_EXT_framebuffer_blit.
This system supports the OpenGL extension GL_EXT_framebuffer_multisample.
This system DOES NOT support the OpenGL extension GL_APPLE_fence.
This system DOES NOT support the OpenGL extension GL_NV_fence.
This system supports the OpenGL extension GL_ARB_sync.
This system supports the OpenGL extension GL_EXT_draw_buffers2.
This system supports the OpenGL extension GL_EXT_bindable_uniform.
This system DOES NOT support the OpenGL extension
GL_APPLE_flush_buffer_range.
This system supports the OpenGL extension GL_ARB_map_buffer_range.
This system supports the OpenGL extension GL_ARB_vertex_buffer_object.
This system supports the OpenGL extension GL_ARB_occlusion_query.
This system DOES NOT support the OpenGL extension GL_APPLE_texture_range.
This system DOES NOT support the OpenGL extension GL_APPLE_client_storage.
This system DOES NOT support the OpenGL extension GL_ARB_uniform_buffer.
This system supports the OpenGL extension GL_ARB_vertex_array_bgra.
This system supports the OpenGL extension GL_EXT_vertex_array_bgra.
This system supports the OpenGL extension GL_ARB_framebuffer_object.
This system DOES NOT support the OpenGL extension GL_GREMEDY_string_marker.
This system DOES NOT support the OpenGL extension GL_ARB_debug_output.
This system supports the OpenGL extension GL_EXT_direct_state_access.
This system DOES NOT support the OpenGL extension GL_NV_bindless_texture.
This system supports the OpenGL extension GL_AMD_pinned_memory.
This system DOES NOT support the OpenGL extension
GL_EXT_framebuffer_multisample_blit_scaled.
This system supports the OpenGL extension GL_EXT_texture_sRGB_decode.
Setup file 'GameInfo.txt' doesn't exist in subdirectory 'hl2'.
Check your -game parameter or VCONFIG setting.
Setup file 'GameInfo.txt' doesn't exist in subdirectory 'hl2'.
Check your -game parameter or VCONFIG setting.
I've also tried the fglrx-updates 2:9.012-0unbuntu1 driver - same as standard fglrx.
Same result (long doesn't support x,y or z message) when using the fglrx graphics driver from fglrx_12.104-0ubuntu1_i386.deb generated from the latest non-beta drivers from the AMD website.
Unless anyone swears they work, I am not going to bother to try the beta drivers.
(In reply to comment #20)
> I will try the Codeweavers version on this PC,
It runs, but with the same issue as before - I have to delete the config file that sets the video resolution before it will run again.
Searching the web, I cannot find anyone who has got this working on Nvidia or AMD/ATI on any distribution using the free drivers. The AMD/ATI binary blob drivers don't work for me as the lack capacity (see above) so was this just tested with the Nvidia binary blob drivers?
I had similar problems (basically all mentioned here, in sequence ;-) ). It was always some missing shared library. Sorry, I already forgot which library fixed which problem, I installed too many of them at the end :-).
Try running ldd on all files in the game bin folder (e.g. "ldd bin/*.so", you may want to update LD_LIBRARY_PATH as is done in the startup script, to avoid unresolved libraries from the bin folder itself), you should get much better idea what is missing.
If not, post the output here, maybe it will help with troubleshooting.
The complete lack of any feedback is just depressing. The game has been released almost a year ago and there is absolutly no feedback from the developers at all.
It seems it was a quick port to boost humble bundle sales - and now nobody cares.
If so, why not close the bug reports as "WONTFIX" so at least people can finally give up hope.
While I understand the frustration from the silence, and I would also expect at least SOME support and feedback for paid software, I got the native port running quite fine, after satisfying all the missing dependencies. The only problem I found so far is that the brightness control does not work, and I can easily live with that.
Thomas: Glad that it works on your machine, however the bug report here is *not* about missing dependencies - that manifests in a different error and not a bad glx config message.
This bug report is about the fact, that the native dear esther port only seems to run fine with the proprietary nvidia drivers (and probably amd catalyst although some issues seem to exist judging from reports here), but not with anything free.
Which is bad news if you've got only an intel GPU which would run the windows version without problems....
(In reply to linuxhippy from comment #28)
> This bug report is about the fact, that the native dear esther port only
> seems to run fine with the proprietary nvidia drivers (and probably amd
> catalyst although some issues seem to exist judging from reports here), but
> not with anything free.
> Which is bad news if you've got only an intel GPU which would run the
> windows version without problems....
No, this bug is rather about missing (32 bit) dependencies.
The free drivers (radeon, nouveau and intel) don't support 3D acceleration or, if they do, only very basically, or only on old graphic cards, which haven't the best 3D performance. The Intel onboard or integrated GPUs aren't 3D capable from the hardware, at least they have very poor 3D performance. That's why almost every notebook which has an Intel GPU integrated in the CPU also has an NVIDIA Optimus chip for the 3D acceleration.
So I bet that no up-to-date 3D software will run on your computer.
> No, this bug is rather about missing (32 bit) dependencies.
Heiko, please re-read the first ten (or so) comments. All of those users try to run dear esther with free mesa drivers. So I guess this more or less defines what this bug report is all about.
> The free drivers (radeon, nouveau and intel) don't support 3D acceleration or ...
Take a look at phoronix.
1. The open source intel drivers are almost on-par with their closed-source windows counterparts.
2. Statements like intel GPUs don't support 3D are clearly out-of-date. Please take some time and read a few phoronix articles.
Actually the wine version of dear esther runs fine on my notebook, so it is not the hardware being too weak nore the driver subsystem which is unuseable according to your claims.
Actually the reason why I am disappointed is that I've waited with playing dear esther until the native version would be in a useable state, instead of switching to the wine version. If there would be a clear comment on the state of the native port (aka non-supported) I could end waiting, forget about the few bucks I spent at the humble bundle and play the wine version.
(In reply to linuxhippy from comment #30)
> > No, this bug is rather about missing (32 bit) dependencies.
>
> Heiko, please re-read the first ten (or so) comments.
I already read them, I already posted a comment earlier.
> All of those users try
> to run dear esther with free mesa drivers. So I guess this more or less
> defines what this bug report is all about.
I guess you don't mean mesa but the graphics drivers. As I already mentioned, the free graphics drivers don't support 3D acceleration, at least not for newer graphics cards. I don't know about the Intel drivers, but I know that Intel cards don't have the best 3D performance, and that that's the reason why on at least most notebooks with Intel GPUs there's also an additional NVIDIA Optimus chip for 3D graphics.
> Take a look at phoronix.
From what I read about phoronix, it shall not be the most reliable source. But I can be wrong. Nevertheless I know my experiences with all those drivers.
> 1. The open source intel drivers are almost on-par with their closed-source
> windows counterparts.
I wouldn't bet on this.
> 2. Statements like intel GPUs don't support 3D are clearly out-of-date.
> Please take some time and read a few phoronix articles.
See above. And all I heard or read about Intel cards went into the same direction.
> Actually the wine version of dear esther runs fine on my notebook, so it is
> not the hardware being too weak nore the driver subsystem which is unuseable
> according to your claims.
If the wine version runs find on your notebook, then you're most likely missing some (32 bit) dependencies.
> I wouldn't bet on this.
> And all I heard or read about Intel cards went into the same direction.
Probably you're not up-to-date ;)
http://www.anandtech.com/show/6993/intel-iris-pro-5200-graphics-review-core-i74950hq-tested/11
Intel IGP playing Crysis3 at medium quality (1600x900) at ~30fps.
As dear esther is way less demanding, you most likely don't need their highest end IGP.
> If the wine version runs find on your notebook,
> then you're most likely missing some (32 bit) dependencies.
As wine isn't able to magically run 32-bit windows code within a 64-bit linux process you would need exactly the same shared library as are required with the native 32-bit version, right?
(In reply to linuxhippy from comment #32)
> As wine isn't able to magically run 32-bit windows code within a 64-bit
> linux process you would need exactly the same shared library as are required
> with the native 32-bit version, right?
I don't know much about wine, because I have no need for it.
But if you're running a 64-bit Linux system and you get the error, about which this bug report is, with the native Linux version of Dear Esther then you're most likely missing some 32 bit dependencies. See my older comment.
> But if you're running a 64-bit Linux system and you get the error,
> about which this bug report is
The message is about a missing GLX extension which can have it's root also in missing 32-bit dependencies.
However with mesa-based drivers, the issue is that some extension is required which is not supported by the driver (and most likely not even needed, because the windows version works fine without it) and the application does not even cope properly with this failure...
@Heiko
I don't know what you're trying to do, but a lot of what you're writing doesn't makes sense or is just wrong. Please take some time to carefully read the former messages. For example in my message
https://bugzilla.icculus.org/show_bug.cgi?id=5955#c12
I told, that comparable games like Half-Life 2 (same engine/Source Engine) run fine under Linux (without Wine) on my computer with a Radeon HD 4200 (open source drivers) and also on my notebook with a Intel i7 integrated HD Graphics 3000 (also open source drivers). So please stop discussing about that.
Also this doesn't has anything to do with 32 Bit dependencies. As said, please read the previous messages!
So let's get back to the point!!!
What happened to the developers and why is nobody of them answering?
I also think, that this isn't OK for a commercial game. At least there should be a "We're still here and some day we'll fix that bug." or a "Won't fix, because...".
Probably they just need to get a SourceEngine update from Valve.
https://en.wikipedia.org/wiki/Source_Engine
(In reply to colAflash from comment #35)
> @Heiko
> I don't know what you're trying to do, but a lot of what you're writing
> doesn't makes sense or is just wrong. Please take some time to carefully
> read the former messages. For example in my message
>
> https://bugzilla.icculus.org/show_bug.cgi?id=5955#c12
>
> I told, that comparable games like Half-Life 2 (same engine/Source Engine)
> run fine under Linux (without Wine) on my computer with a Radeon HD 4200
> (open source drivers) and also on my notebook with a Intel i7 integrated HD
> Graphics 3000 (also open source drivers). So please stop discussing about
> that.
You really want to tell me, what I have to do or not? You're kidding!
Btw., if you think, that "a lot of what" I'm "writing doesn't make sense", I guess you should try to learn a bit more about that stuff, and try all those cards and drivers yourself, before writing such a nonsense.
> Also this doesn't has anything to do with 32 Bit dependencies. As said,
> please read the previous messages!
Please read my previous message. I had the same issue, but I solved it by finding the missing 32-bit dependencies and installing them.
@colAflash
@Heiko
Since Heiko seems to mistake a bugtracker for a newbie forum, let me confirm that the game does not start on my machine either, yet I have all dependencies installed and most Steam games that support Linux work perfectly fine (I have tested and played about a hundred on my box).
(In reply to J from comment #38)
> @colAflash
> @Heiko
>
> Since Heiko seems to mistake a bugtracker for a newbie forum, let me confirm
> that the game does not start on my machine either, yet I have all
> dependencies installed and most Steam games that support Linux work
> perfectly fine (I have tested and played about a hundred on my box).
Before you waste your time with insulting other people, you should use this time to investigate if you really have installed all necessary dependencies with their 32-bit (also called multilib) versions.
If you have installed the dependencies for Steam, this doesn't mean, that you have installed the dependencies for Dear Esther.
Fellows, this is a bug report. Please stop using it as a forum for debate and bear in mind that every single message you post is being sent to the entire CC list.
Reply to comment # 32:
> http://www.anandtech.com/show/6993/intel-iris-pro-5200-graphics-review-core-i74950hq-tested/11
>
> Intel IGP playing Crysis3 at medium quality (1600x900) at ~30fps.
> As dear esther is way less demanding, you most likely don't need their highest end IGP.
IF you really have such high end Intel GPU, and IF you have the latest intel drivers (means Mesa 10.0, which you need to compile yourself, because AFAIK no distribution ships it yet) then you may have some success in running 3D games on intel card.
I have Intel HD 4000 integrated, which is pretty crappy for 3D, but should somehow be able to run this. But I also have intel driver and Mesa libs which came with my distribution, which means Mesa 9.2.2 with OpenGL 3.0/GLSL 1.3 (compared to 4.3/4.3 with discrete NVidia card). Also, the list of possible framebuffer formats is quite limited (44, compared to 359 with NVidia via optimus).
So my guess is that while it might be possible to get DearEsther running on intel card, it's probably not worth it until the drivers get into much better shape (in a year or two maybe?).
Just for reference, if I try running the native port without optirun (or primusrun), I get GLXBadFBConfig as well. It works with optirun/primusrun. So you are right saying that on intel card, it's (most probably) not a matter of dependencies.
> As wine isn't able to magically run 32-bit windows code within a 64-bit linux process you would need exactly the same shared library as are required with the native 32-bit version, right?
Wrong. Wine is implementing Windows OS APIs, thus application depends on 32-bit windows dlls. You need 32-bit Linux dependencies for wine only, and that's completely different list. I have experimentally confirmed this, as I had the wine version running (stuttering, with crappy sound, but running), but the native one was still missing a lot of dependencies.
> it's probably not worth it until the drivers get
> into much better shape (in a year or two maybe?).
Well, mesa 9.2 was released 9 months ago ... current one is 10.1, whereas fedora 19 ships mesa 10.0. With 10,1 at least the wine version works fine here.
> Wrong. Wine is implementing Windows OS APIs,
> thus application depends on 32-bit windows dlls.
> You need 32-bit Linux dependencies for wine only,
> and that's completely different list.
Ok in this case I was a little unprecise, I was looking at it more from the functionality point-of-view.
If the windows version is using the same hardware-features through directx as the native linux port, wine would have to translate it and call into a linux shared library and the issue would pop up too.
@Heiko
I guess on your notebook happened the following:
The game was running on your Intel graphics card, so it crashed with that error.
After installing 32 Bit virtualgl/bumblebee the game became able to run, using the NVidia-Card which doesn't has the specified problem.
So yes, installing 32 Bit libraries gave you the ability to run the game. But that didn't solved the problem itself! It just enabled the game to run on your NVidia graphics card which doesn't has that problem.
Thom Brown (bug reporter) and I both use a Lenovo ThinkPad X220 notebook, which doesn't has another graphics card then the Intel card.
If there's another graphics card (NVidia or Radeon) you can use that one (which might requires additional 32 Bit packages), but that's not the scenario Thom Brown was reporting.
"Dear Esther" should be absolutely able to run on the Intel opensource drivers. As said, other comparable games do so!
(and "Dear Esther" also runs in Wine, which can't increase any ability of the underlying Linux system).
This is, what this bug report is about!
This isn't about any Wine scenarios or non-Intel-card related.
At least, maybe a new version of the Intel drivers or Mesa3D (maybe version 10.x) could also solve that problem "from the other side".
But as said: I'd like to hear something from the "Dear Esther" developers about this.
Please, stop guessing.
I already commented that I had the same error message, and the reason was missing 32-bit library. And yes, I am pretty sure I know on which GPU I was starting the game.
Obviously, this error can be triggered by multiple reasons, one is missing dependencies, another is GPU not capable of what the game asks for. So everyone should first make sure there are no unresolved dependencies (e.g. with ldd on the executable and also on all libraries in the bin folder), and only then you can be sure your problem is GPU and not dependencies.
Please, stop with your theories, this is a bug report, not a discussion forum, as was already pointed out.
Missing dependencies on the main binary would cause the main binary to fail to start. Missing dependencies on the libraries in the bin folder will or will not cause the binary to fail to start, as some of them are loaded dynamically, and the failure is handled by the code. Again, verified when I was troubleshooting the game on my machine. E.g. when libMiles.so fails to load due to missing dependencies, the game runs, but without any MP3 sounds.
I really don't have time for this, so once more, for the last time. Clearly, slowly, on real world example:
dearesther_linux, the main executable is started. It loads static dependencies, and also some dynamic dependencies. One of the dynamic dependencies is bin/libMiles.so. libMiles.so depends statically on libopenal.so.1. This library is not preset, so dynamic loading of libMiles.so fails. Main executable handles the error, the game runs without MP3 sounds (voice etc.).
Running ldd on bin/libMiles.so shows the missing dependency. Installing the dependency resolves the problem.
Using ldd helped me a lot finding missing dependencies, and installing missing dependencies got me running with almost no issues. It might help others, that's why I have posted it here.
Everyone here already knows that it apparently does not help you. So can we stop beating dead horse now?
This is my last post here, I have much better things to do than this discussion, sorry, and bye.
(In reply to colAflash from comment #44)
> @Heiko
> I guess on your notebook happened the following:
> The game was running on your Intel graphics card, so it crashed with that
> error.
You really shouldn't try guessing. The game was running on the NVIDIA chip. You know bumblebee and the command optirun?
> After installing 32 Bit virtualgl/bumblebee the game became able to run,
> using the NVidia-Card which doesn't has the specified problem.
After installing the 32 bit virtualgl I had the last missing 32 bit dependency installed, so Dear Esther could run. That is, I was missing dependencies. That was the only reason for the error message.
> So yes, installing 32 Bit libraries gave you the ability to run the game.
> But that didn't solved the problem itself! It just enabled the game to run
> on your NVidia graphics card which doesn't has that problem.
And now think about what you have written. This has solved the problem itself! Because there have been dependencies missing.
> "Dear Esther" should be absolutely able to run on the Intel opensource
> drivers. As said, other comparable games do so!
Other games are probably not as 3D intense as Dear Esther. That's why they run on Intel graphics cards.
And no! OpenSource drivers have very poor 3D performance. They only get the best out of older cards which haven't the best 3D performance hardware-sided.
> But as said: I'd like to hear something from the "Dear Esther" developers
> about this.
Then read the whole bug report from the beginning. The developers already asked if there are dependencies missing.
> > "Dear Esther" should be absolutely able to run on the Intel opensource
> > drivers. As said, other comparable games do so!
>
> Other games are probably not as 3D intense as Dear Esther. That's why they
> run on Intel graphics cards.
>
> And no! OpenSource drivers have very poor 3D performance. They only get the
> best out of older cards which haven't the best 3D performance hardware-sided.
>
> > But as said: I'd like to hear something from the "Dear Esther" developers
> > about this.
>
> Then read the whole bug report from the beginning. The developers already
> asked if there are dependencies missing.
Would you please stop spamming the bugreport and writing so much bullshit? The Intel opensource drivers are fine and run games that are way more demanding than Dear Esther. As re-iterated again and again, there are no missing static dependencies (since the dynamic linker would fail and as can be checked with ldd on the executable and all .so files). I even checked with gdb (breakpoints on dlopen) that no dynamic dependencies are missing.
The error is probably down the game trying to get a GL context that's not available. Since the developer seems to have abandoned the port, there's no knowing for sure, though.
Heiko:
We can argue forever whether missing dependencies are the issue or not and won't come to a conclusion, as for some reporters obvously missing dependencies were an issue while for others the issue is Dear Esther won't run with free drivers (while many more modern/demanding titles actually do).
Your issue with dependencies is solved, which is a great thing.
The issue with dear esther not running with open-source drivers is still open and the people suffering from this are waiting for feedback from the devs.
> Other games are probably not as 3D intense as Dear Esther.
> That's why they run on Intel graphics cards.
> And no! OpenSource drivers have very poor 3D performance.
One more time: Crysis3 on windows runs on Intel IGPs. The wine version of Dear Esther runs fine on my HD3000 with mesa-10.1, and - at least in my case - the issue is not with missing dependencies.
I debugged Dear Esther's calls to SDL a bit. It calls (as David Gow has posted earlier):
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 3);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 2);
...
SDL_GL_CreateContext(...);
Then SDL, and then Dear Esther, fail since the context can't be created. This is correct, since I'm on Sandy Bridge atm, which only supports OpenGL 3.1. Since everyone who reported the bug (and who didn't have dependency issues) is on Sandy Bridge (HD 2000 or HD 3000), too, this seems to be the cause of the bug.
The real issue is therefore that the listed requirements on the Humble page are wrong: it states HD 3000, which doesn't support OpenGL 3.2, although the Linux port as is requires it. The minimum Intel generation is Ivy Bridge (HD 2500, HD 4000 and upwards).
If everyone agrees, I suggest that someone reaches out to the people responsible for listing the requirements and closing this bug report as WONTFIX.
I think it is sadly screamingly obvious that this is a WONTFIX, to the point that they won't even say that it's a WONTFIX :(
There should not be a dependency issue: for those of us using a Debian-based system, the .deb package should list exactly what it needs.
It is clear that for many of us, the hardware is perfectly capable of running the game. On two different PCs, one with a not very recent Nvidia card, one with a reasonably recent AMD Radeon APU, both the WINE-wrapped Windows version of Dear Esther and assorted native versions of other Source-engine games run perfectly well.
But neither will do the native Dear Esther, and the error messages for that are not quite what they should be to easily sort out why.
What I suspect has happened is that the person who was paid to port this to a native Linux version got it running on their system, that got released, and it hasn't been touched since.
Somewhere, possibly somewhere on the island, there is a bowl of water and a drying towel, because they've washed their hands of it.
Tried with Mesa 10.1 from this repo (I'm running openSUSE 13.1).
http://download.opensuse.org/repositories/X11:/XOrg/openSUSE_13.1/
Mesa-32bit-10.1.0-353.1.x86_64.rpm
09-Apr-2014 15:03
I replaced all installed packages with those from that repo.
Unfortunately that didn't solved the problem.
(In reply to colAflash from comment #57)
> Tried with Mesa 10.1 from this repo (I'm running openSUSE 13.1).
>
> http://download.opensuse.org/repositories/X11:/XOrg/openSUSE_13.1/
>
> Mesa-32bit-10.1.0-353.1.x86_64.rpm
> 09-Apr-2014 15:03
>
> I replaced all installed packages with those from that repo.
>
> Unfortunately that didn't solved the problem.
The code requires an OpenGL 3.2 compatibility profile to run. OpenGL 3.2 is available only since Mesa 10 for open drivers, but not for all, and it will never be available for Sandybridge hardware since it doesn't support it.
Unfortunately, "but not for all" currently means "only on Intel chips". Therefore, neither your desktop (Radeon RS880) nor your laptop (HD 3000) is able to run the code with open Mesa drivers.
Also a compatibility profile isn't available in any Mesa driver. If Mesa fails in this case (which would be sensible), then it's currently impossible to run Dear Esther with open drivers at all.
You can check the supported OpenGL version with glxgears. For me it says:
...
OpenGL core profile version string: 3.1 (Core Profile) Mesa 10.1.0
...
To get a slightly better error message, you can remove the shipped SDL2 version and install a newer one. For me it then prints "Could not create GL context".
You are justifiably angry about Ryan Gordon not bothering to comment on this, and you are right that it's weird that the Windows version doesn't need an OpenGL 3.2-class GPU, but there's nothing that we can do about the Linux code requiring it.
It's possible that the Linux code, apart from the initialization, doesn't require OpenGL 3.2 (why would the Linux version need geometry shaders when the Windows version doesn't?). Then the problem could be solved by letting SDL2 always create a 3.1 core profile.
I don't get that 'core profile version' string via glxgears:
$ glxgears -info
GL_RENDERER = AMD Radeon HD 7560D
GL_VERSION = 4.2.12337 Compatibility Profile Context 13.101
(..)
But glxinfo gives it, and sadly for that theory, from what I can see I do have a higher version than 3.1 and do have geometry shaders:
$ glxinfo
(..)
OpenGL vendor string: Advanced Micro Devices, Inc.
OpenGL renderer string: AMD Radeon HD 7560D
OpenGL core profile version string: 4.2.12337 Core Profile Context 13.101
OpenGL core profile shading language version string: 4.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
(..)
GL_ARB_geometry_shader4, GL_ARB_get_program_binary, GL_ARB_gpu_shader5,
(..)
GL_EXT_geometry_shader4, GL_EXT_gpu_program_parameters,
(..)
OpenGL version string: 4.2.12337 Compatibility Profile Context 13.101
OpenGL shading language version string: 4.30
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile
OpenGL extensions:
(..)
GL_EXT_geometry_shader4, GL_EXT_gpu_program_parameters,
(..)
And, as above, it still won't run the native version.
> To get a slightly better error message, you can remove the shipped SDL2
> version and install a newer one. For me it then prints "Could not create GL
> context".
For me too.
Removed "libSDL2-2.0.so.0" from the bin folder and used libSDL2 provided by my distro (openSUSE 13.1 => libSDL2-2_0-0-32bit version 2.0.0-2.1.1) instead.
==========
SDL video target is 'x11'
SDL video target is 'x11'
SDL video target is 'x11'
Failed to create GL context: Could not create GL context
==========
Anyone has a possibility to wake up Ryan Gordon or any other developer? I wrote a mail to icculus@icculus.org and via this website.
http://thechineseroom.co.uk/contact/
(In reply to Ian from comment #59)
> I don't get that 'core profile version' string via glxgears:
>
> $ glxgears -info
> GL_RENDERER = AMD Radeon HD 7560D
> GL_VERSION = 4.2.12337 Compatibility Profile Context 13.101
> (..)
>
> But glxinfo gives it, and sadly for that theory, from what I can see I do
> have a higher version than 3.1 and do have geometry shaders:
>
> $ glxinfo
> (..)
> OpenGL vendor string: Advanced Micro Devices, Inc.
> OpenGL renderer string: AMD Radeon HD 7560D
> OpenGL core profile version string: 4.2.12337 Core Profile Context 13.101
> OpenGL core profile shading language version string: 4.30
> OpenGL core profile context flags: (none)
> OpenGL core profile profile mask: core profile
> OpenGL core profile extensions:
> (..)
> GL_ARB_geometry_shader4, GL_ARB_get_program_binary, GL_ARB_gpu_shader5,
> (..)
> GL_EXT_geometry_shader4, GL_EXT_gpu_program_parameters,
> (..)
> OpenGL version string: 4.2.12337 Compatibility Profile Context 13.101
> OpenGL shading language version string: 4.30
> OpenGL context flags: (none)
> OpenGL profile mask: compatibility profile
> OpenGL extensions:
> (..)
> GL_EXT_geometry_shader4, GL_EXT_gpu_program_parameters,
> (..)
>
> And, as above, it still won't run the native version.
Then we have three separate issues:
1) People with dual GPUs and missing dependencies, either for their non-open driver or for a library that triages requests (for 3.2 contexts) to the non-open driver. This is a guess since those who reported the solution never detailed which libraries they're talking about.
2) People on Intel GPUs that don't support OpenGL 3.2 (like me). I verified it by stepping through the code with gdb that this is the cause of the program failing for me. It's unclear if Dear Esther really needs a 3.2 context, and if so, why it does in the Linux version and not in the Windows version.
3) People like Ian who have a non-open driver on a non-Intel GPU that supports the 3.2 compatibility profile.
I'll find out what the glxinfo says about the other PC (someone else has it now) but it had an Intel Core2 Duo CPU, and was using the closed Nvidia drivers.
A possible reason, why the developers don't answer anymore:
http://www.littlelostpoly.co.uk/dear-esther-and-unity/> Dear Esther running in Unity
Looks like they port Dear Esther from the Source-Engine to the Unity-Engine. The Unity-Engine is also available for Windows, Linux and MacOSX.
So that's probably the reason why they don't care anymore about Source-Engine related bugs.
On the mesa mailing list I learned about version overrides:
export MESA_GL_VERSION_OVERRIDE=3.2
export MESA_GLSL_VERSION_OVERRIDE=150
... which seem to help quite a few games to pass version tests.
However at least with mesa-9.2 these checks didn't help for dear esther.
(In reply to J from comment #51)
> Would you please stop spamming the bugreport and writing so much bullshit?
> The Intel opensource drivers are fine and run games that are way more
> demanding than Dear Esther. As re-iterated again and again, there are no
> missing static dependencies (since the dynamic linker would fail and as can
> be checked with ldd on the executable and all .so files). I even checked
> with gdb (breakpoints on dlopen) that no dynamic dependencies are missing.
>
> The error is probably down the game trying to get a GL context that's not
> available. Since the developer seems to have abandoned the port, there's no
> knowing for sure, though.
Ok, if you think you know it all, then stay with the bug instead of digging into missing dependencies on your system and/or buying a 3D resp. gaming capable graphics card.
I got Dear Esther running with searching for and installing the missing dependencies. If you think you have everything installed and you know everything better, then it's just that. It's your problem, not mine.
(In reply to colAflash from comment #64)
> A possible reason, why the developers don't answer anymore:
>
> http://www.littlelostpoly.co.uk/dear-esther-and-unity/
"Unfortunately, the native (Linux) port has never left beta, having lost touch with the original developer shortly afterward."
Yes, that sounds about right.
I'm sure we all await the Unity-based version with interest. Shall we stop moaning that the Source beta version doesn't work for us now? (Hint :) )
(In reply to linuxhippy from comment #52)
> Heiko:
>
> We can argue forever whether missing dependencies are the issue or not and
> won't come to a conclusion, as for some reporters obvously missing
> dependencies were an issue while for others the issue is Dear Esther won't
> run with free drivers (while many more modern/demanding titles actually do).
When do you understand that free video drivers are NOT capable of 3D accelartion with a performance necessary for this game?
And if you think your driver is capable of running this game then you ARE missing at least one dependency.
> One more time: Crysis3 on windows runs on Intel IGPs.
Windows is NOT Linux and the video drivers are NOT the same. Windows drivers are developed by the hardware manufacturers and support everything of even the newest video cards of this manufacturer. Linux OpenSource drivers are NOT necessarily developed by the hardware manufacturers and do NOT support every feature of the newest video cards.
The reason for this could be company secrets, so that other hardware manufacturers don't get too many details about the chips. Just think about this.
> The wine version of
> Dear Esther runs fine on my HD3000 with mesa-10.1, and - at least in my case
> - the issue is not with missing dependencies.
Wine is NOT native Linux.
And, btw., Crysis3 is NOT Dear Esther. They both can have very different system requirements and dependencies.
But also to you: If you think you know it better, and you don't need to search for and install missing dependencies, and/or buy a graphics card which is suitable for gaming, then stay with this bug. It's your problem, not mine. I got Dear Esther running, and I had the same error messages as the original reporter.
I thoroughly stepped through the code with gdb and objdump.
Changing launcher.so to neither require OpenGL 3.2 nor a compatibility profile doesn't help. The code DOES need the compatibility profile: It uses legacy and very outdated functionality from OpenGL that was deprecated in OpenGL 3.0 and removed in OpenGL 3.1 (e.g. EXT_framebuffer_object or the old fence system).
Since Mesa will never support the compatibility profile (cf. http://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt), this version will never support open drivers. The fact that they, or anyone claims compatibility with Intel hardware (drivers, that is) is outrageous.
I did also try to change the code to request an OpenGL 3.0 context, which helps insofar as I get a screen, but the game crashes almost instantly. It's too time-consuming to try to fix anything serious with only the disassembled code, so: We'll have to wait for their port to Unity.
I'm off now, since this is WONTFIX and CANTFIX and -- excuse my language -- Heiko won't fuck off with his spamming and his stupidity.
J: Thanks for your effort analyzing what is going wrong. Seems this native version is a dead-end, however the news of ongoing work on a unity based version even better than what I had hoped for.
Seems the waiting will finally pay off :)
(In reply to Ian from comment #56)
> There should not be a dependency issue: for those of us using a Debian-based
> system, the .deb package should list exactly what it needs.
I forgot earlier. .dep packages should list exactly what it needs. The operative word is should.
.dep packages are built by humans, and humans can make mistakes and can forget something. And it's possible that the .deb package builder thought that the 32 bit version of a dependency is already packaged into the .deb package of this dependency while it is in fact not, and so forth.
(In reply to J from comment #69)
> I'm off now, since this is WONTFIX and CANTFIX and -- excuse my language --
> Heiko won't fuck off with his spamming and his stupidity.
Again, before you start insulting other people you should put your own house in order first.
I could have told you before, that your tinkering with launcher.so wouldn't help.
(In reply to J from comment #69)
> [...]
> It's too time-consuming to try to fix anything serious with only the
> disassembled code, so: We'll have to wait for their port to Unity.
Probably. Nevertheless thanks for your gdb-efforts!!!
I just wonder, how the Dear Esther developers got into this trouble. Other Source Engine games like Half-Life 2 or Oil Rush run so well on the open source Intel drivers... :-(
Maybe "Dear Esther" just uses a very outdated version of the Source Engine (I think I remember the first reports about the Source Engine being ported to Linux featured a lot of tests on NVidia hardware).
Indeed the game uses an older version of the source engine (btw OilRush is powered by the unigine engine).
When I asked the developers about future plans for better linux support half a year ago, this was their response:
> Try the wine version - there are some deeper issues with Source and Linux
> which are unlikely to get fixed without us migrating the entire game to the
> newest Source version, which is quite a complicated task, so right now, we
> can't promise anything... Sorry - we did our best, and maybe one day...!
The "maybe one day..." was actually way more meaningful than I thought back then ;)
./dearesther_linux
SDL video target is 'x11'
SDL video target is 'x11'
SDL video target is 'x11'
X Error of failed request: GLXBadFBConfig
Major opcode of failed request: 155 (GLX)
Minor opcode of failed request: 34 ()
Serial number of failed request: 184
Current serial number in output stream: 183
As a sanity check: do you have the right 32-bit OpenGL drivers installed? ("glxinfo" will show you the 64-bit drivers.) --ryan.Additional hardware info: 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller]) Subsystem: Lenovo Device 21da Flags: bus master, fast devsel, latency 0, IRQ 49 Memory at f0000000 (64-bit, non-prefetchable) [size=4M] Memory at e0000000 (64-bit, prefetchable) [size=256M] I/O ports at 5000 [size=64] Expansion ROM at <unassigned> [disabled] Capabilities: <access denied> Kernel driver in use: i915> But if you're running a 64-bit Linux system and you get the error, > about which this bug report is The message is about a missing GLX extension which can have it's root also in missing 32-bit dependencies. However with mesa-based drivers, the issue is that some extension is required which is not supported by the driver (and most likely not even needed, because the windows version works fine without it) and the application does not even cope properly with this failure...> as some of them are loaded dynamically So, was it you or me proposing to use ldd to find missing dependencies. Relax ;)> > "Dear Esther" should be absolutely able to run on the Intel opensource > > drivers. As said, other comparable games do so! > > Other games are probably not as 3D intense as Dear Esther. That's why they > run on Intel graphics cards. > > And no! OpenSource drivers have very poor 3D performance. They only get the > best out of older cards which haven't the best 3D performance hardware-sided. > > > But as said: I'd like to hear something from the "Dear Esther" developers > > about this. > > Then read the whole bug report from the beginning. The developers already > asked if there are dependencies missing. Would you please stop spamming the bugreport and writing so much bullshit? The Intel opensource drivers are fine and run games that are way more demanding than Dear Esther. As re-iterated again and again, there are no missing static dependencies (since the dynamic linker would fail and as can be checked with ldd on the executable and all .so files). I even checked with gdb (breakpoints on dlopen) that no dynamic dependencies are missing. The error is probably down the game trying to get a GL context that's not available. Since the developer seems to have abandoned the port, there's no knowing for sure, though.Heiko: We can argue forever whether missing dependencies are the issue or not and won't come to a conclusion, as for some reporters obvously missing dependencies were an issue while for others the issue is Dear Esther won't run with free drivers (while many more modern/demanding titles actually do). Your issue with dependencies is solved, which is a great thing. The issue with dear esther not running with open-source drivers is still open and the people suffering from this are waiting for feedback from the devs. > Other games are probably not as 3D intense as Dear Esther. > That's why they run on Intel graphics cards. > And no! OpenSource drivers have very poor 3D performance. One more time: Crysis3 on windows runs on Intel IGPs. The wine version of Dear Esther runs fine on my HD3000 with mesa-10.1, and - at least in my case - the issue is not with missing dependencies.I don't get that 'core profile version' string via glxgears: $ glxgears -info GL_RENDERER = AMD Radeon HD 7560D GL_VERSION = 4.2.12337 Compatibility Profile Context 13.101 (..) But glxinfo gives it, and sadly for that theory, from what I can see I do have a higher version than 3.1 and do have geometry shaders: $ glxinfo (..) OpenGL vendor string: Advanced Micro Devices, Inc. OpenGL renderer string: AMD Radeon HD 7560D OpenGL core profile version string: 4.2.12337 Core Profile Context 13.101 OpenGL core profile shading language version string: 4.30 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: (..) GL_ARB_geometry_shader4, GL_ARB_get_program_binary, GL_ARB_gpu_shader5, (..) GL_EXT_geometry_shader4, GL_EXT_gpu_program_parameters, (..) OpenGL version string: 4.2.12337 Compatibility Profile Context 13.101 OpenGL shading language version string: 4.30 OpenGL context flags: (none) OpenGL profile mask: compatibility profile OpenGL extensions: (..) GL_EXT_geometry_shader4, GL_EXT_gpu_program_parameters, (..) And, as above, it still won't run the native version.Indeed the game uses an older version of the source engine (btw OilRush is powered by the unigine engine). When I asked the developers about future plans for better linux support half a year ago, this was their response: > Try the wine version - there are some deeper issues with Source and Linux > which are unlikely to get fixed without us migrating the entire game to the > newest Source version, which is quite a complicated task, so right now, we > can't promise anything... Sorry - we did our best, and maybe one day...! The "maybe one day..." was actually way more meaningful than I thought back then ;)