Planetary Annihilation

  • Status Closed
  • Task Type Bug
  • Category Main Menu
  • Operating System Linux 64-bit
  • Reported Version 61250
Attached to Project: Planetary Annihilation
Opened by SXX (sxx) - Wed Feb 19, 2014 02:25
Last edited by SXX (sxx) - Sat May 31, 2014 00:43

FS#3057 - Crashes or black screen on start with open source drivers

At moment all shaders in game use GLSL 150 (OpenGL 3.2), but game still using default 3.0 context.

Closed by  SXX (sxx)
Sat May 31, 2014 00:43
Reason for closing:  Fixed
Additional comments about closing:  Fixed in 66770
SXX (sxx)

Wed Feb 19, 2014 13:25

Small update #1:
I done some research and it’s looks like current version of game not likely will able to work on FOSS drivers. In current version all shaders require OpenGL 3.2 and this is why you see black screen: menu it’s just flat surface that also handled by shaders.

I guess it’s still possible to workaround something with backport shaders to GLSL 1.30 and disable broken renderer features, but it’s will be massive amount of work and there is high chances it’s won’t work anyway.

Now shortly about crash with context override: MESA_GL_VERSION_OVERRIDE=3.2 MESA_GLSL_VERSION_OVERRIDE=150
Problem here that game still using legacy features that is not available with newer OpenGL core profile, e.g it’s make call of glGetString(GL_EXTENSIONS) that was deprecated in 3.0 and removed in 3.1.

It’s possible to bypass that crash before Coherent initialization. Here is next problem: using same glGetString func so it’s mean it’s most likely won’t work properly with 3.2 context, but actually it’s not cause crashes. Next problem is Coherent host itself, but it’s looks like if it’s run in separate process it’s easier to make it use older GL version.

My current guess for possible workaround: it’s looks like PA executable use two OpenGL contexts: one for libCoherentUI and one for game. libCoherentUI communicate with Coherent host that not looks like app which would work with 3.2 so both of them have to use default 3.0. I think this way because devs somehow make Mac version work properly.

If I’m right and there is some way to force game use 3.2 context, but leave 3.0 for Coherent (host and lib) then it’s might help to make workaround.

Yrrep (yrrep)

Wed Feb 19, 2014 17:56

Not much to add, just wanted to confirm it for Intel HD Graphics 4000 on Arch Linux x86_64.

SXX (sxx)

Thu Feb 20, 2014 12:02

From information I have now Linux version don’t get any OpenGL-related changes yet while Mac version actually request 3.2 core profile. Anyway if somebody with debugging skills want to help this can be pretty useful because my C/C++ debugging/programming skills too low.

There is few interesting facts I find out:

  1. Game detect hardware vendor using GL_VENDOR. So with FOSS it’s not detect Intel (”Intel Open Source Technology Center” vendor), but not detect AMD (”X.Org” as vendor).
  2. I wasn’t able to replay GL trace from Nvidia hardware with APITrace. Game might be using some extensions that not available in FOSS drivers.
  3. In 61250 shaders don’t compiled on startup anymore so I can’t actually tell if they’re fine or not.
  4. In 59607 version game didn’t use “glGetString(GL_EXTENSIONS)” at all so it’s didn’t crash with 3.2 context forced, but libCoherentUI still used it’s didn’t work anyway.
  5. In 59607 it’s was possible get to system editor with 3.2 context and “–software-ui” used, but game only render one triangle instead of planet. So if we even make Coherent work game most likely won’t work anyway.

If you want to play around with it you need to use MESA_DEBUG=verbose and GDB. Still I have no idea how exactly GL context initialization happen so I can’t test my theory.

SXX (sxx)

Thu Feb 20, 2014 12:54

Two more news: good and bad one.

Good news. With 3.2 context forced and “–software-ui” enabled after you bypass first crash by putting valid output for #5 glGetString call game actually working. E.g Coherent render nothing, but it’s “feel” input and you can go though menus if you press proper buttons.

Bad news. Something new (except sun shader which I disabled already) cause GPU lockup for me (HD6950, R600g from Oibaf PPA). I’ll try to make some tests on my HD3000 laptop, but it’s actually don’t have 3.2 support so this will fail possible.

SXX (sxx)

Thu Feb 20, 2014 16:39

Okay one more update.

I did tried to make same thing on my laptop: Sandy Bridge + 61250 + Software-UI
As result game is crashing after Coherent initialized so it’s looks like Sandy Bridge not only lack of geometry shaders (PA don’t use them), but also some other part of 3.2.

Now I’ll try to re-compile R600g with LLVM shader backend that help me to avoid GPU lockup with sun shader and try to get into system editor to check what it’s can render and see if game itself use any removed features.

Morse (radistmorse)

Thu Feb 20, 2014 18:17

Fedora 20 + mesa 10.1-rc1 + AMD NI

Core profile OGL is 3.3 but the game still obviously uses compat profile with OGL 3.0 / GLSL 1.30. Black screen and all that.

SXX (sxx)

Thu Feb 20, 2014 19:17

Small update on problem. I got GPU lockup with LLVM compiler too, so looks like I have to find malicious shader that cause this.

Morse (radistmorse)

Thu Feb 20, 2014 19:28

Yes, I forgot to mention that: fedora’s mesa now uses LLVM for R600, so in my case it’s on.

SXX (sxx)

Thu Feb 20, 2014 19:59

It’s doesn’t mater what shader compiler you have on startup. I’m got lockup when I get to system manager window, e.g one with sun and background.
To get there you need to force 3.2 context, bypass crash due to glGetString(GL_EXTENSIONS) call with GDB and then click proper buttons blind (though you can run 59607 with transparency to do that).

Here is my current steps in GDB:

set environment MESA_DEBUG=verbose
set environment MESA_LOG_FILE=/tmp/log.txt 
set environment R600_DEBUG=fs,vs,gs,ps,cs
set environment MESA_GLSL=dump
set environment MESA_GL_VERSION_OVERRIDE=3.2
set environment MESA_GLSL_VERSION_OVERRIDE=150
break glGetString

# Here game make glGetString(GL_EXTENSIONS) call that invalid for OpenGL 3.2
# By default it's return 0 that cause PA segfault
set $eax=#CORRECT_VALUE#

# Here Coherent lib make same call, but it's won't crash even with 0 return
set $eax=#CORRECT_VALUE#

You can get correct value though GDB when game running on default 3.0 context.

SXX (sxx)

Thu Feb 20, 2014 20:06

There also little update. I’m run game with MESA_GLSL=dump and find out that game actually still compile/link all shaders on startup in 61250. There is no errors and all IR looks valid.

Still trying to bypass GPU lockup, tried lowest settings and it’s didn’t help.

mcxplode (mcxplode)

Thu Feb 20, 2014 22:09

Interesting tried running the game with “LIBGL_ALWAYS_INDIRECT=1” which forces it to opengl 2.1 compatibility profile and game doensn’t launch that way. Water shaders look new and as far as I know that PA/media/shader files are still the same which code still implements gsl 1.5 aka opengl 3.2 shaders its just linux PA version doesn’t explicitly request version 3.2. As for coherent it uses separate opengl context than PA binary or none at all with software-ui.

Morse (radistmorse)

Fri Feb 21, 2014 12:32

Is there any feedback from the devs? Requesting the deprecated OGL profile for the brand-new still-in-development game is a weird thing to do at the very least, but most probably just a bug. I don’t see any forum thread concerning this, should I start one?

SXX (sxx)

Fri Feb 21, 2014 12:42

PA do not request deprecated profile, it’s using one that set by default and in Mesa it’s 3.0 because this version have compatibility with older profiles. Unfortunately game itself require 3.2 features while using some deprecated stuff as well. On Windows and Linux proprietary drivers GL_ARB_Compatibility is supported so you can do that, but Mesa (as well as OS X graphics stack) doesn’t support that:

Developers already changed how OpenGL handled on Mac, but didn’t do the same for Linux yet.

New topic on forums is not required because developers know about problem and they obviously made changes on Mac first because without it 100% of Mac players won’t able to play game. In same time on Linux only part of players need that change so it’s all about priorities and limited time.

SXX (sxx)

Fri Feb 21, 2014 12:49

Still it’s will be helpful if everyone who affected by this problem watch this task to participate when it’s will be required.

tylerseacrest (tylerseacrest)

Fri Feb 21, 2014 15:27

I would like to confirm that I am watching this task and will participate in any testing.

Arch Linux 64bit with gnome3
Radeon 5870m with mesa 10.0.4, gallium 0.4
kernel 3.12.9, xorg-server 1.15

I’m having the same problem here.

Morse (radistmorse)

Fri Feb 21, 2014 17:11

Yeah, me too. But only a simple playtest, I don’t have time to dig into gdb and such.

There is not much point in testing it with mesa 10.0, the required OGL functionality is only added in 10.1 for r600 driver.

Also, FTW is 10.0.4? The latest official release is 10.0.3

SXX (sxx)

Fri Feb 21, 2014 17:19

Any chance you have Jabber account and 10-20 minutes to make some testing?
If yes send me message: sxx (at) jabber (dot) at
Or if you have Skype/Gtalk send me your contact details in PM forums.

I just stuck in my research because on 6950 I get GPU lockup and on Intel it’s just crash on both HD3000 and HD4000 (thanks to DeathByDenim for testing).

SXX (sxx)

Fri Feb 21, 2014 17:21

Who ever use official releases of Mesa? There is 10.2.0 in git already. :)

I don’t actually want you to dig in anything. I already have prepared steps and you just need to follow them because possible you won’t get GPU lockup and might get some results. CAYMAN (I have HD69XX) never was supported too well in open source drivers.

Morse (radistmorse)

Fri Feb 21, 2014 17:40

The thing is that I don’t want to setup a development environment on my home machine, and I can’t debug games on my office machine. Also, I don’t see much point. So what if it works with all these workarounds? It’s a bug and it should be fixed. Especially if you’re right in assumption that they already fixed it for mac.

SXX (sxx)

Sat Feb 22, 2014 06:10

All you need for testing is GDB, but my message was addressed to @tylerseacrest anyway.

In general this is problem with open source drivers and not actual bug. Game client for Linux require GL_ARB_Compatibility at moment. Reason for making such workarounds is simple: even if developers update that code soon there might be month before new version of game released.

Also even if devs implement 3.2 core profile support there is really high chances that Intel drivers will crash and R600g will cause GPU lockup even with valid code. I’m seriously doubt that invalid GL calls should be able to lockup my GPU so I want to investigate this and report it to Mesa bugtracker. Proper OpenGL 3.2 support appear in Mesa less than in half year ago and there is only few Linux games that use it so I have no doubt there is bugs.

tylerseacrest (tylerseacrest)

Sat Feb 22, 2014 21:12

I assumed that arch was using the latest mesa as it usually tries to get the latest stuff. I’ve since corrected that oversight and am now using 10.2.0-git
No idea what 10.0.4 is. The package version says 10.0.3-1 but glxinfo calls it 10.0.4.

@SXX sent you a PM on the forums.

SXX (sxx)

Sat Feb 22, 2014 22:54

Thanks for @tylerseacrest he tested my workaround on hist card and get GPU lockup as well.
At moment it’s looks like current shaders cause GPU lockup on R600g and crash on Intel.

If there some user of RadeonSI (AMD HD7XXX and newer) card please contact me so we can test if there same lockup with RadeonSI.

Usling (usling)

Tue Feb 25, 2014 19:34

just wanted to confirm this is still not working, and i don’t understand how to try the workaround :)

i use Intel iris pro 5200 with Ubuntu 13.10,

# sudo glxinfo | grep "OpenGL version"
OpenGL version string: 3.0 Mesa 10.2.0-devel (git-7c3138a saucy-oibaf-ppa)
SXX (sxx)

Tue Feb 25, 2014 20:47
and i don’t understand how to try the workaround

There is no working workarounds because with forced GL3.2 on Intel drivers it’s crash and on R600g there just is GPU lockup.
Possible it’s will actually work when Linux version become compatible with 3.2 core profile.

SXX (sxx)

Wed Feb 26, 2014 03:20

@DeathByDenim find something very interesting: LINK

If you run game like that “MESA_GL_VERSION_OVERRIDE=3.0 ./PA” menu load fine and game using GLSL 3.30.
With Intel HD4000 it’s even let you open system editor and add planet.

With R600g I still got GPU lockup.

forgrimm (forgrimm)

Sat Mar 01, 2014 10:32

Any news about this with the new gamma versions? Is it worth to upgrade from mesa 10.0 to mesa git?

SXX (sxx)

Sat Mar 01, 2014 11:32

No news, game still using deprecated stuff.

redpill (defiantredpill)

Fri Mar 07, 2014 06:12

Willing to participate in testing.
Arch Linux x86_64
Intel Ivybridge
kernel 3.13.5
mesa 10.0.3
xorg-server 1.15.0

OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Desktop
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.0.3
OpenGL core profile shading language version string: 3.30
OpenGL version string: 3.0 Mesa 10.0.3
OpenGL shading language version string: 1.30

“MESA_GL_VERSION_OVERRIDE=3.0 ./PA” lets me at least get in to the system editor, that is about it and the mouse pointer is just a bunch of random bits. Still I was very happy to be able to get it to load at all, hoping to be able to play soon!

vel0h (vel0h)

Fri Mar 07, 2014 20:36

Pretty much exact situation as @redpill, would love to actually be able to play the game. All these live streams are taunting me...

mdykstra (mdykstra)

Mon Mar 10, 2014 13:44

What about the fails at the end of my log given in  FS#3246 . It should have to do with the CoherentUI.

Requesting resource read for coui://ui/alpha/_i18n/.... with internal id ... reported FAIL
Requesting resource read for coui://ui/alpha/shared/.... with internal id ... reported FAIL
Requesting resource read for coui://ui/alpha/mods/.... with internal id ... reported FAIL

SXX (sxx)

Mon Mar 10, 2014 14:39

It’s completely unrelated to problem on open source drivers.
All UI surfaces handled by game engine as well and they won’t if shaders not compiled.

Scipio Xaos (scipioxaos)

Fri Mar 14, 2014 19:53

Just wanting to chime in and see if this is the same problem I’m encountering. When I first tried to play it I was getting a black screen, no cursor, but I had music. I added the “–software-ui” tag, and that gave me the cursor, but still black screen. All the other “fixes” I read about involved Ctrl+P or F5 and those failed to work either.

I logged the game terminal output (attached.. just noticed where PA stores its logs.. uploading that one instead of my ‘>’ funneling even though they look identical). The majority of it is failed shader loading and I’m guessing this is the problem. The “0:1(10): error: GLSL 1.50 is not supported. Supported versions are: 1.10, 1.20, and 1.00 ES” report for each shader appears to be the root of the evil.

I just wanted to verify that this is what’s occurring given (I believe) I’m running a FOSS driver. (Not exactly sure how to check that.)

Some System Specs:
* Ubuntu 13.10
* Intel Ironlake Mobile (Graphics)

If you need any more information just ask.. I’m not sure what else to include.

SXX (sxx)

Fri Mar 14, 2014 20:08

Even if developers fix game to work with FOSS drivers it’s not likely will ever work on your integrated graphics.
Ironlake don’t have OpenGL 3 support and on Windows it’s crash due to missing features.

SXX (sxx)

Fri Mar 14, 2014 20:29

Also situation with OpenGL context didn’t changed in 62857 so it’s still crash with FOSS drivers.

vel0h (vel0h)

Sat Mar 15, 2014 20:30

Have there been any developer comments on this issue?

SXX (sxx)

Sun Mar 16, 2014 00:51

I don’t think there was any “official” answers related to open source drivers support, but there was number of comments on problem on forums and in streams. They obviously know about the problem and I guess they perfectly understand that recent changes they made for OS X break compatibility FOSS drivers and they need to change platform-specific code to make it work again.

Just want to clarify that’s not some game “bug” or unexpected fault, but big part of platform-specific code developers have to done from scratch and it’s will take way more than few hours. I’m trying to stay in touch with devs, but they are pretty busy since Gamma released and it’s hard to get any updates even on Windows-specific problems. I suppose engineers who able to do that is too busy with other tasks so we won’t get any real updates on that until code is ready/tested/etc.

SXX (sxx)

Sun Mar 16, 2014 00:57

Also I guess it’s possible to bypass this problem by some dirty hacks related to GL call’s or rendering options, but unfortunately I got GPU lockup on my desktop graphics card and I don’t actually see reason to spend lot of time doing that for laptop because my Intel HD3000 is too slow on Linux to handle PA.

If there was some other guy with debugging or C++ coding skills then we might try to make some workaround because I’m have pretty low skills in this area and all those “run, lockup, reboot” kill me. :-(

As we know game can actually compile GLSL 1.50 shaders somehow even when it’s using 3.0 context, but it’s still doing tons of invalid GL calls. Might be there not so much invalid calls so it’s might be possible to proxy/redirect them, but as I said I have completely no idea how to do that.

brodul (brodul)

Sun Mar 23, 2014 21:34

Same here using Intel HD 4000

Mesa 10.0.4
xf86-video-intel 2.99.911

That should have OpenGL 3.3 support, right? I still get a black screen. Passing MESA_GL_VERSION_OVERRIDE=3.0 fixes the problem, but for example mouse cursor texture is missing.

SXX (sxx)

Sun Mar 23, 2014 23:25
That should have OpenGL 3.3 support, right?

Yes you have OpenGL 3.3, but unfortunately it’s not fix the problem and game won’t work anyway.
I didn’t tested 63234 with open source drivers yet, but I doubt there was any related changes.

pozi (theinternn)

Sun Mar 30, 2014 19:43

Hello, I’m running an ati HD6950, on archlinux.

Doing daily checks on the mesa git repo, but figured I should add vote / subscribe here for updates too.

[alex@colby ~]$ uname -a
Linux colby 3.13.7-1-ARCH #1 SMP PREEMPT Mon Mar 24 20:06:08 CET 2014 x86_64 GNU/Linux
[alex@colby ~]$ glxinfo | grep OpenGL
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD CAYMAN
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.2.0-devel (git-3b421da)
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 10.2.0-devel (git-3b421da)
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:

Let me know if anything needs to be tested; I’m down for anything except selling my soul to catalyst.

SXX (sxx)

Sun Mar 30, 2014 20:33

This problem won’t be fixed with Mesa updates so there is no reason to check them.

Though you can help a bit. I have HD 6950 too and I have GPU lockup so it’s will be useful if you run game as “MESA_GL_VERSION_OVERRIDE=3.0 ./PA” and then post here about results.

sPOiDar (spoidar)

Wed Apr 02, 2014 11:57

On HD4000 with mesa 10.0.0 and Steam, `MESA_GL_VERSION_OVERRIDE=3.0 MESA_GLSL_VERSION_OVERRIDE=150 ./PA` and the start.js debug hack gets me the menu UI and cursor successfully, but still consistently crashes (as of 63180) after planet generation with:

[22:50:55.796] ERROR /pa/terrain/lava/textures/lava_wall_diffuse_normal.papa: open failed
[22:50:55.819] ERROR /pa/terrain/lava/textures/lava_pit_01_diffuse.papa: open failed
[22:50:55.819] ERROR /pa/terrain/lava/textures/desert_pit_01_normal.papa: open failed
[22:50:55.823] ERROR /pa/terrain/lava/textures/lava_pit_02_diffuse.papa: open failed
[22:50:55.823] ERROR /pa/terrain/lava/textures/lava_pit_02_normal.papa: open failed
[22:50:55.876] ERROR /pa/terrain/lava/textures/base/lava_lava_material.papa: getResource() failed
[22:50:55.876] ERROR could not load necessary resource
[22:50:55.879] ERROR /pa/terrain/lava/textures/base/lava_lava_material.papa: getResource() failed
[22:50:55.879] ERROR could not load necessary resource

...or similar.

I realize this is probably to be expected, just cataloguing results for anyone who’s searching.

brodul (brodul)

Wed Apr 02, 2014 14:12

This basically means the game is unplayable on Linux with Intel drivers. Shouldn’t this make it a blocker?

SXX (sxx)

Wed Apr 02, 2014 18:13

Trust me It’s not crashes because of those lines in log. It’s crashes due to future GL incompatibility, e.g game using GL functionality that no longer available in 3.2 core profile.

It’s can be bypassed too, but then I got GPU lockup on R600. Soon I’ll have new motherboard with i7 4771 so I’ll have access to Intel HD4600 and I’ll able to continue debugging.

I can’t speak for developers, but they have priorities and open source drivers support isn’t first in this list. This is sad, but here is lot of other features/bugs need to be implemented and one day they’ll have this work done.

TuxCompanion (mic006)

Thu Apr 03, 2014 18:49

A blocker shall be handled as a blocker.
I am a Linux-only user and I have not been able to play yet (I have bought one month ago).
I was glad to buy and support the team as it is too rare to see a development team supporting Linux. I am now sad that the Linux support is only an advertisement, a promise, and the last item in the TODO list.
Aren’t there a Linux dedicated developper in the team to handle this kind of thing ?

SXX (sxx)

Thu Apr 03, 2014 20:03


I am now sad that the Linux support is only an advertisement, a promise, and the last item in the TODO list.

Game worked fine on Linux include open source drivers (with some fixes for driver bugs with icons) since Alpha till this issue created. I suppose Uber didn’t know core-profile-only specific of open source drivers when then initially implement Linux support.

Mesa missing some GL features and this is sad. :-(

Aren’t there a Linux dedicated developper in the team to handle this kind of thing ?

There no dedicated developers on Linux or Mac. As I understand there is only one developer who able to make those changes and he is pretty busy guy.

SXX (sxx)

Thu Apr 03, 2014 20:56

I made a bit of testing with my new Intel HD4600, 3.14 kernel and latest Mesa. So if I run game with “MESA_GL_VERSION_OVERRIDE=3.0” editor partially working, but if I join game it’s crash.

I find that crash happen inside particle systm so I disabled all effects replacing contents with it:


Actually all effects files in “/media/pa/effects/specs/” have to be replaced. No effects - no crash, easy. Now lobby won’t crash and planet will be generated fine, but as long as as I press “Start Annihilattion” there is complete iGPU lockup again so no luck here.

DeathByDenim (deathbydenim)

Mon Apr 14, 2014 05:58

So, I did some further testing. It turns out you only need to disable pole_north.pfx and pole_south.pfx with the method SXX described. That is enough to make the lobby not crash. I don’t get a complete iGPU lockup, so I got a bit further than SXX. Joining however, does result in a crash.

If I disable all of the effect files in /media/pa/effects/specs, I am able to join. I don’t see the green circle for choosing the starting position of course, but I can see the planet and rotate it. When I randomly click on the planet long enough to actually hit a valid starting position for my commander, the “START ANNIHILATION” button appears. Clicking that however results in a crash again. So close...

If I disable all of the pfx files. Even the ones in the various /media/pa/units directories I still get the crash after I click “START ANNIHILATION”. It may be the rendering of the Commander model that causes the crash or maybe the fog of war.

I don’t think it’s related, but I do get a lot of these errors in the log:

ERROR Unable to allocate transform buffer for static batched rendering. Most likely cause: out of video memory.

They appear before I make the “START ANNIHILATION” button appear though, so they don’t actually cause the crash.

Finally, some further info: This is the last that appears in my log (with all of the pfx disabled):

[01:40:51.525] INFO sendLandingLocationSelected
[01:40:51.813] INFO handleLaunchSuccess
[01:40:51.813] INFO processUICommand
[01:40:51.823] INFO setMusic /Music/Music_Launch_Commander
[01:40:51.831] INFO handleLaunchSuccess
[01:40:51.831] INFO processUICommand
[01:40:51.831] INFO handleAllLandingsSelected
[01:40:51.962] INFO Dump written to /tmp/09aedf0c-990f-04a6-77a8b701-5efb15a6.dmp
SXX (sxx)

Mon Apr 14, 2014 16:44

Basically any effect will crash game.

I don’t think it’s related, but I do get a lot of these errors in the log:

Those errors appear because of invalid GL calls, at least code related to instancing (features on planet surface) use them.

PS: Also I won’t do any additional research on this issue anymore at least till next update.

keyxmakerx (keyxmakerx)

Sat Apr 19, 2014 02:32

I too have this issue. On sys76 gaz pro 7 Intel i7 38** laptop. Ubuntu 14.04, no luck on working so far. Hope the issue is resolved soon. At least acknowledgement would be appreciated.

SXX (sxx)

Tue Apr 22, 2014 21:24

If somebody interested nothing have changed in 64498. :-(

keyxmakerx (keyxmakerx)

Fri May 16, 2014 14:48

Intel Just updated the ubuntu 14.04 open source drivers. Any luck in seeing if there is a fix?

SXX (sxx)

Fri May 16, 2014 17:24

Developers let me know they’re working on open source drivers support at moment, but please keep in mind nothing is guaranteed and it’s possible won’t be fixed within next updates. Uber also hired new developer who experienced with Linux and he’ll start to eliminate Linux-related issues soon.

*****powered (roscoedog)

Fri May 23, 2014 20:33

Hey, that’s great. As a side-note,

My laptop has an nvidia mobile processor. Becuase of blah-blah-blah, and incompatible-incompatibilities, I can’t use the NVidia linux driver. It won’t even install from the website. I’ve tried bumble-bee, primus, optirun, etc. I’ve spent 3+ hours several times trying to get it to work.

If you can come up with how to make a working config, that would be awesome, but the sad state of 3d drivers may mean laptop users are stuck with the open source drivers.

Game looks awesome - have wanted to play it for some time.

☀ lspci
00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06)
01:00.0 3D controller: NVIDIA Corporation GK107M [GeForce GT 745M] (rev ff)

☀ inxi -SGx
System: Host: mc-desktop Kernel: 3.11.0-12-generic x86_64 (64 bit, gcc: 4.8.1) Desktop: Gnome Distro: Linux Mint 16 Petra
Graphics: Card: Intel 4th Gen Core Processor Integrated Graphics Controller bus-ID: 00:02.0

         X.Org: 1.14.5 drivers: intel (unloaded: fbdev,vesa) Resolution: 1920x1080@60.0hz 
         GLX Renderer: Mesa DRI Intel Haswell Mobile GLX Version: 3.0 Mesa 9.2.1 Direct Rendering: Yes
noiq (noiq)

Mon May 26, 2014 12:39

Although the posts in the forums and on steam mentioning the error

ERROR Planetary Annihilation: SDL_GL_CreateContext failed: Could not create GL context

point to this task, a don’t see anything about it in this comments. Is this first part (at least entering any kind of menu) already solved?

I’m using ubuntu 14.04 and intel HD4600 (i7-4770) with PA version 66567.

SXX (sxx)

Tue May 27, 2014 13:33
point to this task, a don’t see anything about it in this comments. Is this first part (at least entering any kind of menu) already solved?

No it’s not. Game still using lot of GL only available in compatibility profile and only difference it’s fact that now it’s request exactly 3.2 compatibility profile. Obviously context creation failed on open source drivers because those don’t support GL_ARB_Compatibility.

hobarrera (hobarrera)

Wed May 28, 2014 21:12

I’m somewhat confused by few things:

(1) This issue states “Open source drivers”, but Intel cards don’t have another driver; the offical one is the open source one. Does that make the game 100% unplayable until the issue is fixed? (since there is no other driver to switch to)
(2) How can a not-yet-released product have issues because it uses deprecated dependencies/tecnologies/APIs? You should not be using deprecated stuff on a new product, especially considering it’ll just add more breakage over time (libudev and libcurl have the same issue: the game requires really old versions to be compiled for it to run).

Also, I can confirm that this regression also affects an HD 5000 which was working fine before (on ArchLinux-amd64).

SXX (sxx)

Wed May 28, 2014 21:42
Does that make the game 100% unplayable until the issue is fixed?

Correct, you can’t play it on Intel.

How can a not-yet-released product have issues because it uses deprecated dependencies/tecnologies/APIs?

I suppose none of developers at Uber actually shipped any Linux game before PA. So when they originally wrote Linux-specific OpenGL code they didn’t expect it’s won’t work. And later when this become serious issue nobody had time to find out and fix it possible because they don’t want to fix code that would be removed soon. Mac version don’t have fullscreen for same reason: it’s waiting before SDL2 will be done and tested on Linux and only then developers start to port Mac/Windows version to SDL.

Still Uber release Linux version early and even if there was issues it’s usually worked even better than Windows builds due to low Coherent stability on Windows. So it’s just how devs decide to do things.

SXX (sxx)

Thu May 29, 2014 02:07

So new PTE build 66705 is working on Intel HD4600 with open source drivers:

SXX (sxx)

Thu May 29, 2014 15:42

So I still have issue with GPU lockup on R600 so I created new task on Mesa bugtracker:
If there any other R600 user getting lockups too please comment on this task with information about your GPU.

SXX (sxx)

Sat Jun 14, 2014 13:27

Players who have problem with Sandy Bridge and other drivers without OpenGL 3.2 support please join  FS#3608 .

AbrarSyed (abrarsyed)

Wed Jul 09, 2014 18:40

I used to be getting the error in  FS#3608 , but since the latest update I am still getting a black screen on startup.

I am running Arch Linux with the following OS video drivers and mesa related libs
local/xf86-video-ati 1:7.4.0-2
local/xf86-video-fbdev 0.4.4-2
local/xf86-video-intel 2.99.912-1
local/xf86-video-modesetting 0.9.0-1
local/ati-dri 10.2.3-1
local/glu 9.0.0-3
local/intel-dri 10.2.3-1
local/lib32-ati-dri 10.2.3-1
local/lib32-glu 9.0.0-2
local/lib32-intel-dri 10.2.3-1
local/lib32-libtxc_dxtn 1.0.1-5
local/lib32-mesa 10.2.3-1
local/lib32-mesa-libgl 10.2.3-1
local/libtxc_dxtn 1.0.1-5
local/mesa 10.2.3-1
local/mesa-demos 8.2.0-1
local/mesa-libgl 10.2.3-1

I have Intel Hybrid graphics with an AMD Radeon HD 6490M. This is a laptop.
I am reasonably sure that the intel integrated graphics are bieng used to run the game instead of the RadeonHD, but thats likely my fault somehow.

Requesting that this issue be reopenned.