When I switched to using Linux full time in the spring of 2007, my first recourse for gaming was either emulation or playing many of my old ported favourites from id Software. It did not take me long to start looking further afield in search of other quality Linux native titles, but in a time when digital distribution was in its infancy, and the Indie revolution that it would bring had not quite started yet, new games were few and far between.
At the same time, a small startup in Sweden was hard at work trying to expand their original Penumbra tech demo into a series of full fledged episodic horror games. The Penumbra Collection would be the ultimate result of that effort, with Linux support being provided by Edward Rudd. It would even go on to have its first instalment included as part of the original Humble Indie Bundle. The game soon caught my eye due to its strong graphics and advanced physics engine.
I have never been one to be frightened by video games, but thanks to its skilful environmental storytelling, strong writing, and accomplished vocal talent, the Penumbra Collection got its hooks into me all the same. Frictional Games would go on to even greater acclaim with the release of Amnesia: The Dark Descent only a few months after I first played, but it is the Penumbra Collection that is always going to hold a special place in my heart.
It pains me to say then, in spite of the still excellent support that Frictional Games gives to our platform, that the state of the Penumbra Collection for a number of Linux users has become such a mess. Ten years on I found myself with little option other than running my old copy of the Penumbra Collection from the now defunct Desura service; the closure of the company’s own storefront leaving no other recourse for those wishing to avoid the use of Steam.
Regardless, the version of the game that I have (1.1.1 released on December 4, 2014) appears even now to be the most recent release of the Penumbra Collection. This includes a number of much appreciated quality of life improvements over earlier versions such as offering support for more modern display resolutions, better audio handling through the use of an improved OALWrapper, and everything being reworked to run on top of SDL2.
At first blush the game installed and ran great, right up until I tried to leave the fishing boat at the start of the first episode in the series Penumbra: Overture. Upon attempting to load the next level the game would immediately crash to the desktop; a similar problem occurred upon using the vice at the start of the second episode Penumbra: Black Plague. It did not take long for me to discover that the solution was to build a custom Mesa package yet again.
For whatever reason, the Penumbra Collection will crash when Mesa is built with compiler optimizations applied. This can be mitigated by Arch Linux users through the use of the Arch Build System, or by generating your own Mesa build manually. Either option is far from ideal of course, and while officially the game does only support proprietary vendor drivers, almost all users of both AMD and Intel graphics hardware on Linux will now run into this issue.
Also alarming is that while trying to diagnose the problem I uncovered a separate bug that causes the game to crash when using modern versions of the libvorbis library. My copy of the Penumbra Collection came bundled with an older "libvorbis.so.0" file included in the the game's various "lib" directories, so I was able to sidestep this issue, but it is always a bad sign when a game refuses to run off the libraries that come supplied with your Linux distribution.
Ten years on the Penumbra Collection plays as strong as ever, even if my appreciation for Overture has increased as my over familiarity with Black Plague has lessened its impact. More than any other game, I wish I could go back to 2010 and play these titles with a fresh pair of eyes, especially since solving puzzles in the wrong order can on occasion confuse the narrative. What need do I have for the severed hand of Dr. Eminiss when I already have one in my bag?
Frictional Games are hard at work on their next Amnesia title, and while I know that keeping old games updated can be an aggravating support burden, I do still hope that the developers can come back to the Penumbra Collection, fix up these issues that will continue to plague a growing number of Linux users, and then spread the game to even more stores. To be left with creaking binaries from a shuttered distribution service is disheartening for a game that remains so dear to me.
Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
These are my favorite horror games. I've been recently replaying them with my friend who got sucked into frictional games with SOMA. They hold up.
0 Likes
These kind of issues with older games on new systems is exactly why we need Linux-runtime containers that Valve are working on in Steam. Otherwise we will lose a lot of great games to bit-rot in no time.
For me personally Penumbras more down to earth "this could happen to you too" setting resonated with me much more than Amnesias more fantasy oriented "it's basically magic" approach. Penumbra: Black Plague is one of my all time favourite games.
For me personally Penumbras more down to earth "this could happen to you too" setting resonated with me much more than Amnesias more fantasy oriented "it's basically magic" approach. Penumbra: Black Plague is one of my all time favourite games.
1 Likes, Who?
https://github.com/FrictionalGames/HPL1Engine
I don't suppose that's the engine and be compiled to work with the game assets? Because maybe the core Mesa issue could be fixed from within the engine itself. If that's the case, I can try peek into the problem on the weekend.
It should be, they release the source to the game back in the day due to the HumbleBundle (if I'm not mistaken releasing the source was one of the requirements for one of their bundles).
There is some external dev activity on their forum: https://www.frictionalgames.com/forum/forum-28.html
And according to the first post there:
There is a LOT of code here. 2 libraries and one game. So don't be afraid to discuss and ask questions on pieces of the code. Lets all collaborate and build some documentation for the HPL1 Engine as well as the OALWrapper library. Ideally I would like to see clean documentation appear on the github wiki pages so there is a good reference this codebase.
So the source should not only be for the engine but also for the first game.
Overture have it's own forum for source here: https://www.frictionalgames.com/forum/forum-29.html and it uses the same engine so I think the code is similar and the only difference between the games are scripts but I have not looked into it so I don't really know.
1 Likes, Who?
I just tested Overture on my Ubuntu 18.04 and I experienced no crashes when leaving the fishing boat, this was using the Steam version so this is most likely due to the game using the Steam runtime.
0 Likes
I just tested Overture on my Ubuntu 18.04 and I experienced no crashes when leaving the fishing boat, this was using the Steam version so this is most likely due to the game using the Steam runtime.
Or the issue is with radeon driver. As Hamish has to compile without optimizations, it would be great that he also keep the debug symbols and then generate and core dump with the crash. That way we would know if the crash comes from the heart of Mesa or somewhere else.
0 Likes
The 1.1.1 ver is available at the storefront if you've previously got it there back in the day.
Gave it a quick go, and was greeted with a black screen, grabbed input, and a hung process to be kill 9'ed... A 20 yo port of UT99 behaves better for me right off the bat literally without any post-install intervention.
Providing an up to date sdl2 helped and the game seems to run fine after that, no crash on leaving the boat.. or after falling down the rabbit hole either.
Ubuntu 20.04, stock kernel/mesa, radeonsi (maybe the crash occurs with amdgpu?)
PS if Hamish's pc info is up to date he must be also using radeonsi, so it could be down to how Arch builds its mesa by default
Last edited by mos on 22 May 2020 at 3:22 pm UTC
Gave it a quick go, and was greeted with a black screen, grabbed input, and a hung process to be kill 9'ed... A 20 yo port of UT99 behaves better for me right off the bat literally without any post-install intervention.
Providing an up to date sdl2 helped and the game seems to run fine after that, no crash on leaving the boat.. or after falling down the rabbit hole either.
Ubuntu 20.04, stock kernel/mesa, radeonsi (maybe the crash occurs with amdgpu?)
PS if Hamish's pc info is up to date he must be also using radeonsi, so it could be down to how Arch builds its mesa by default
Last edited by mos on 22 May 2020 at 3:22 pm UTC
0 Likes
PS if Hamish's pc info is up to date he must be also using radeonsi, so it could be down to how Arch builds its mesa by default
Amish list a HD6870, which uses radeon driver. But now that you mention Arch builds, you made me recall of this issue:
https://gitlab.freedesktop.org/mesa/mesa/-/issues/2973
So the issue is not with gcc optimization level but with link-time optimizations:
https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/mesa&id=3deacbde16a2a03b5a5e4c69052f4f95b8922a4f
EDIT: Worht mention that this is an issue with gcc 10, with gcc 9 Mesa can be compiled with lto without any problem.
Last edited by x_wing on 22 May 2020 at 3:35 pm UTC
1 Likes, Who?
list a HD6870yep, that's where I've got my assumption from.
as for the crash.. well anything can break anything in computing, especially in a highly-volatile world of complex programmable frame-buffer devices)
whether in this case the blame lies on mesa/Arch/penumbra/driver or spread across multiple parties is open for discussion I guess.
0 Likes
So this is interesting. When going back to try and provide the core dump that x_wing requested I discovered that Overture no longer crashes when you leave the fishing boat, even when using the stock lib32-mesa package supplied by Arch Linux.
Downgrading the package reveals that the fix was introduced with lib32-mesa-20.0.7-2 built on May 15th. A couple of days after I first started drafting this article.
Black Plague still crashes when attempting to flatten the coin in the vice, however. Here is the backtrace:
My Radeon HD 6870 still uses the older r600g drivers by the way. I do in fact have a Radeon RX 460 on order so that I can upgrade to amdgpu and gain Vulkan support among other things, but it has not arrived yet.
Last edited by Hamish on 22 May 2020 at 11:17 pm UTC
Downgrading the package reveals that the fix was introduced with lib32-mesa-20.0.7-2 built on May 15th. A couple of days after I first started drafting this article.
Black Plague still crashes when attempting to flatten the coin in the vice, however. Here is the backtrace:
#0 0xf537355b in ?? () from /usr/lib32/dri/r600_dri.so
#1 0xf4e90e77 in ?? () from /usr/lib32/dri/r600_dri.so
#2 0xf4e927ca in ?? () from /usr/lib32/dri/r600_dri.so
#3 0xf502629c in ?? () from /usr/lib32/dri/r600_dri.so
#4 0xf50280fa in ?? () from /usr/lib32/dri/r600_dri.so
#5 0x083f42a1 in hpl::cSDLTexture::CreateFromBitmapToHandle(hpl::iBitmap2D*, int) ()
#6 0x083f5609 in hpl::cSDLTexture::CreateFromBitmap(hpl::iBitmap2D*) ()
#7 0x08381716 in hpl::cTextureManager::CreateFlatTexture(std::string const&, bool, bool, hpl::eTextureType, hpl::eTextureTarget, unsigned int) ()
#8 0x083794ec in hpl::cMaterialManager::LoadFromFile(std::string const&, std::string const&) ()
#9 0x08379c8a in hpl::cMaterialManager::CreateMaterial(std::string const&) ()
#10 0x082f8790 in hpl::cParticleEmitterData3D_UserData::LoadFromElement(TiXmlElement*) ()
#11 0x082f11fd in hpl::cParticleSystemData3D::LoadFromFile(std::string const&) ()
#12 0x08395cab in hpl::cParticleManager::CreatePS3D(std::string const&, std::string const&, hpl::cVector3<float>, hpl::cMatrix<float> const&) ()
#13 0x0835584a in hpl::cWorld3D::CreateParticleSystem(std::string const&, std::string const&, hpl::cVector3<float> const&, hpl::cMatrix<float> const&) ()
#14 0x08324561 in ?? ()
#15 0x0857d482 in CallSTDCallFunction(unsigned long const*, int, unsigned int) ()
#16 0x0857da17 in CallSystemFunction(int, asCContext*, void*) ()
#17 0x085a0e4d in asCContext::ExecuteNext() ()
#18 0x085a38ce in asCContext::Execute() ()
#19 0x085632ce in asCScriptEngine::ExecuteString(char const*, char const*, asIScriptContext**, unsigned long) ()
#20 0x0841da38 in hpl::cSqScript::Run(std::string const&) ()
#21 0x081a5879 in cInit::RunScriptCommand(std::string const&) ()
#22 0x0827bf65 in cGameWheel::RunCallback(eGameWheelState, eGameWheelAction) ()
#23 0x0827c2ab in cGameWheel::Update(float) ()
#24 0x082a7764 in iGameEntity::OnUpdate(float) ()
#25 0x082076ef in cMapHandler::Update(float) ()
#26 0x08322a97 in hpl::cUpdater::Update(float) ()
#27 0x0831f0f3 in hpl::cGame::Run() ()
#28 0x08246628 in hplMain(std::string const&) ()
#29 0x083e7cab in main ()My Radeon HD 6870 still uses the older r600g drivers by the way. I do in fact have a Radeon RX 460 on order so that I can upgrade to amdgpu and gain Vulkan support among other things, but it has not arrived yet.
Last edited by Hamish on 22 May 2020 at 11:17 pm UTC
1 Likes, Who?
So this is interesting. When going back to try and provide the core dump that x_wing requested I discovered that Overture no longer crashes when you leave the fishing boat, even when using the stock lib32-mesa package supplied by Arch Linux.
Downgrading the package reveals that the fix was introduced with lib32-mesa-20.0.7-2 built on May 15th. A couple of days after I first started drafting this article.
Black Plague still crashes when attempting to flatten the coin in the vice, however. Here is the backtrace:
#0 0xf537355b in ?? () from /usr/lib32/dri/r600_dri.so
#1 0xf4e90e77 in ?? () from /usr/lib32/dri/r600_dri.so
#2 0xf4e927ca in ?? () from /usr/lib32/dri/r600_dri.so
#3 0xf502629c in ?? () from /usr/lib32/dri/r600_dri.so
#4 0xf50280fa in ?? () from /usr/lib32/dri/r600_dri.so
#5 0x083f42a1 in hpl::cSDLTexture::CreateFromBitmapToHandle(hpl::iBitmap2D*, int) ()
#6 0x083f5609 in hpl::cSDLTexture::CreateFromBitmap(hpl::iBitmap2D*) ()
#7 0x08381716 in hpl::cTextureManager::CreateFlatTexture(std::string const&, bool, bool, hpl::eTextureType, hpl::eTextureTarget, unsigned int) ()
#8 0x083794ec in hpl::cMaterialManager::LoadFromFile(std::string const&, std::string const&) ()
#9 0x08379c8a in hpl::cMaterialManager::CreateMaterial(std::string const&) ()
#10 0x082f8790 in hpl::cParticleEmitterData3D_UserData::LoadFromElement(TiXmlElement*) ()
#11 0x082f11fd in hpl::cParticleSystemData3D::LoadFromFile(std::string const&) ()
#12 0x08395cab in hpl::cParticleManager::CreatePS3D(std::string const&, std::string const&, hpl::cVector3<float>, hpl::cMatrix<float> const&) ()
#13 0x0835584a in hpl::cWorld3D::CreateParticleSystem(std::string const&, std::string const&, hpl::cVector3<float> const&, hpl::cMatrix<float> const&) ()
#14 0x08324561 in ?? ()
#15 0x0857d482 in CallSTDCallFunction(unsigned long const*, int, unsigned int) ()
#16 0x0857da17 in CallSystemFunction(int, asCContext*, void*) ()
#17 0x085a0e4d in asCContext::ExecuteNext() ()
#18 0x085a38ce in asCContext::Execute() ()
#19 0x085632ce in asCScriptEngine::ExecuteString(char const*, char const*, asIScriptContext**, unsigned long) ()
#20 0x0841da38 in hpl::cSqScript::Run(std::string const&) ()
#21 0x081a5879 in cInit::RunScriptCommand(std::string const&) ()
#22 0x0827bf65 in cGameWheel::RunCallback(eGameWheelState, eGameWheelAction) ()
#23 0x0827c2ab in cGameWheel::Update(float) ()
#24 0x082a7764 in iGameEntity::OnUpdate(float) ()
#25 0x082076ef in cMapHandler::Update(float) ()
#26 0x08322a97 in hpl::cUpdater::Update(float) ()
#27 0x0831f0f3 in hpl::cGame::Run() ()
#28 0x08246628 in hplMain(std::string const&) ()
#29 0x083e7cab in main ()
My Radeon HD 6870 still uses the older r600g drivers by the way. I do in fact have a Radeon RX 460 on order so that I can upgrade to amdgpu and gain Vulkan support among other things, but it has not arrived yet.
Indeed, that build is related to the removal of the linker optimizations with gcc 10. I'm not sure if the issue is related with gcc or mesa (seems that it is the former as the opened ticket on mesa gitlab are closed now) but I think this is a good example of why Debian or other distros prefer a slower path regarding package upgrades :P
BTW: the game ships debug symbols?? Weird that they didn't strip the binary on release
Last edited by x_wing on 22 May 2020 at 11:51 pm UTC
1 Likes, Who?
Still sad to see that GOG have not the Linux versions of the Penumbra games... I send an email about it this month and still no answer.
0 Likes
PublicNuisance May 24, 2020
Still sad to see that GOG have not the Linux versions of the Penumbra games... I send an email about it this month and still no answer.
This is just my theory but I think issues like these are why it is not on GOG. To be more specific from what I have gathered GOG is very strict about providing the same support to all potential customers. For instance on the CRPG Beautiful Isolation the Linux version was late being on GOG but the developer mentioned that this was because on Steam they could simply choose to not support those that used AMD CPUs and GPUs on Linux as they had a bug on those setups at the moment. GOG would not allow them to do this and had they released the Linux version on GOG they would have to support all customers not just certain ones. Now luckily that bug got fixed and the Linux version for Beautiful Desolation is now on GOG but it makes me wonder how many Linux games that are not on GOG are due to not being able to blacklist customers like Steam allows them to. Again, just a theory.
0 Likes
Still sad to see that GOG have not the Linux versions of the Penumbra games... I send an email about it this month and still no answer.
This is just my theory but I think issues like these are why it is not on GOG. To be more specific from what I have gathered GOG is very strict about providing the same support to all potential customers. For instance on the CRPG Beautiful Isolation the Linux version was late being on GOG but the developer mentioned that this was because on Steam they could simply choose to not support those that used AMD CPUs and GPUs on Linux as they had a bug on those setups at the moment. GOG would not allow them to do this and had they released the Linux version on GOG they would have to support all customers not just certain ones. Now luckily that bug got fixed and the Linux version for Beautiful Desolation is now on GOG but it makes me wonder how many Linux games that are not on GOG are due to not being able to blacklist customers like Steam allows them to. Again, just a theory.
I doubt that it works that way. Beautiful Desolation still has a bug that makes the game unplayable on Linux with Mesa drivers (unless you want to cheat). Whatever restriction or problem they have with GoG is probably completely unrelated with the current state of the game on Mesa.
Last edited by x_wing on 24 May 2020 at 9:22 pm UTC
0 Likes
The Linux version of Metro: Last Light Redux was bounced by GOG.com quality control:
Also seems to be true with Postal 2 as well:
Which is why when I played Postal 2 again earlier this year I had to use my old outdated Desura copy like I did with the Penumbra Collection.
Last edited by Hamish on 24 May 2020 at 9:26 pm UTC
In this case that responsibility was on us ... We encountered a number of technical issues while preparing our DRM-free Linux and Mac OS X versions and made the call to hold back the releases until we can be confident in the quality of our product. While we are trying to fix the problems, we cannot make any promises if and when the DRM-free versions will be ready."Source: https://news.softpedia.com/news/Deep-Silver-Refuses-to-Provide-Linux-DRM-free-Builds-to-GOG-com-for-Metro-Last-Light-Redux-481335.shtml
Also seems to be true with Postal 2 as well:
We had planned on having Mac and Linux ports done for this release, but we ran into some really bizarre problems in trying to get them to run, that we haven't sorted out yet. So we had to push those plans back for a while. Unfortunately, I can't give you an ETA on when we might get them done. :(Source: https://www.gog.com/forum/postal_series/linux_version_of_postal_2_and_paradise_lost/post2
Which is why when I played Postal 2 again earlier this year I had to use my old outdated Desura copy like I did with the Penumbra Collection.
Last edited by Hamish on 24 May 2020 at 9:26 pm UTC
1 Likes, Who?
I vaguely recall Frictional saying they planned to open source the other two Penumbra games along with Amnesia:TDD at some point.
1 Likes, Who?
PublicNuisance May 25, 2020
Still sad to see that GOG have not the Linux versions of the Penumbra games... I send an email about it this month and still no answer.
This is just my theory but I think issues like these are why it is not on GOG. To be more specific from what I have gathered GOG is very strict about providing the same support to all potential customers. For instance on the CRPG Beautiful Isolation the Linux version was late being on GOG but the developer mentioned that this was because on Steam they could simply choose to not support those that used AMD CPUs and GPUs on Linux as they had a bug on those setups at the moment. GOG would not allow them to do this and had they released the Linux version on GOG they would have to support all customers not just certain ones. Now luckily that bug got fixed and the Linux version for Beautiful Desolation is now on GOG but it makes me wonder how many Linux games that are not on GOG are due to not being able to blacklist customers like Steam allows them to. Again, just a theory.
I doubt that it works that way. Beautiful Desolation still has a bug that makes the game unplayable on Linux with Mesa drivers (unless you want to cheat). Whatever restriction or problem they have with GoG is probably completely unrelated with the current state of the game on Mesa.
From the GOG forum for the game coming from an employee of Brotherhood:
"GOG is a lot more strict about release. They are not going to let me isolate an entire processor manufacturer (AMD) for a platform"
https://www.gog.com/forum/beautiful_desolation/linux_version/page1
On Steam they were literally allowed to put in the system requirements that the game wouldn't work on AMD CPUs or GPUs on Linux and weren't going to be officially supported. Then behind the scenes they fixed the bug; got it released on GOG; and removed that language from Steam.
From the Steam forums when asked if a Linux version was coming to GOG after the fix:
"Yip, it is at GOG for review now. They take some time to make sure everything is ok (they actually play the game). I think we should have it up by next week. Ill update this thread once it is there."
https://steamcommunity.com/app/912570/discussions/0/1749024519676236016/?ctp=10
People can say what they will about GOG but they do excel in certain areas over Steam such as in QA on what games are allowed on their store and trying to make sure they work.
0 Likes
People can say what they will about GOG but they do excel in certain areas over Steam such as in QA on what games are allowed on their store and trying to make sure they work.
I can't talk of how they test the game but I can tell you: the game is not yet playable with AMD GPUs. I have the game and I reported an issue with the codex (basically you can't see the contents) and that makes the game unplayable as it's a vital component for the story and game riddles.
Whatever tests GOG did, it wasn't with an AMDGPUs or they didn't try to play the game properly.
Last edited by x_wing on 25 May 2020 at 4:10 pm UTC
0 Likes
Sorry to break it to you but you are all wrong about the cause. It has nothing to do with OpenGL binding wrong textures. The reason why the game breaks on Linux with the most recent Mesa drivers is because the game uses AngelScript which can cause stack misalignments. When loading some functions from within AngelScript (for example, load an OGG file or a 2D texture) the stack gets misaligned and loses the 16-byte boundary, and since both Mesa (the video driver) and libogg use SSE instructions, stack misalignment causes CPU exceptions.
I had these issues myself when playing the game, and my solution was to compile the game on my own and set AngelScript to preserve stack alignment. For more details, see https://www.frictionalgames.com/forum/thread-56758.html
That said, yes, to fix the issue you need to build Mesa so that it does not use optimized SSE instruction (one of the effects of the -O0 flag btw). This is, imho, not a clean solution. The problem is, on the forum people complained about stack misalignment and devs did not integrate the AngelScript modification (literally just define a simple macro) into the newest Linux builds. Penumbra is still a sold game, it is unaccepta
I had these issues myself when playing the game, and my solution was to compile the game on my own and set AngelScript to preserve stack alignment. For more details, see https://www.frictionalgames.com/forum/thread-56758.html
That said, yes, to fix the issue you need to build Mesa so that it does not use optimized SSE instruction (one of the effects of the -O0 flag btw). This is, imho, not a clean solution. The problem is, on the forum people complained about stack misalignment and devs did not integrate the AngelScript modification (literally just define a simple macro) into the newest Linux builds. Penumbra is still a sold game, it is unaccepta
3 Likes, Who?
That said, yes, to fix the issue you need to build Mesa so that it does not use optimized SSE instruction (one of the effects of the -O0 flag btw). This is, imho, not a clean solution.I am sure it is like swatting a mosquito with a sledge hammer, but it worked for me.
I do wonder if a complete Penumbra source port could be constructed from the Overture code.
0 Likes
> I am sure it is like swatting a mosquito with a sledge hammer, but it worked for me.
Yeah yeah, I mainly meant "unacceptable to the end user", as the end user should not meddle with system drivers. If needs must, one can still keep the unoptimized library in a separate folder and source them with the LIBGL_DRIVERS_PATH environment variable.
I guess that having stack alignment issues
To add pain to the injury, trying to run Penumbra with Proton results to a dark screen during the game, probably nvidia-cg does not like wine.
> I do wonder if a complete Penumbra source port could be constructed from the Overture code.
Overture and Black Plague are very alike, at least this is what I can tell judging from the function signature (they did not get stripped from the linux binary, wow). I think that at this stage not opensourcing Black Plague is not very wise.
But frankly, I do not see much interest in the developers to maintain the old Penumbra saga. The forum looks dead, and there are some pending PRs in the engine/openal wrapper that have completely been ignored for the last few years. It is quite understandable as the developers moved on to other spicier projects like Amnesia, then SOMA. See https://github.com/FrictionalGames/HPL1Engine/issues/15 (mine)
Yeah yeah, I mainly meant "unacceptable to the end user", as the end user should not meddle with system drivers. If needs must, one can still keep the unoptimized library in a separate folder and source them with the LIBGL_DRIVERS_PATH environment variable.
I guess that having stack alignment issues
To add pain to the injury, trying to run Penumbra with Proton results to a dark screen during the game, probably nvidia-cg does not like wine.
> I do wonder if a complete Penumbra source port could be constructed from the Overture code.
Overture and Black Plague are very alike, at least this is what I can tell judging from the function signature (they did not get stripped from the linux binary, wow). I think that at this stage not opensourcing Black Plague is not very wise.
But frankly, I do not see much interest in the developers to maintain the old Penumbra saga. The forum looks dead, and there are some pending PRs in the engine/openal wrapper that have completely been ignored for the last few years. It is quite understandable as the developers moved on to other spicier projects like Amnesia, then SOMA. See https://github.com/FrictionalGames/HPL1Engine/issues/15 (mine)
1 Likes, Who?
Patreon
PayPal
See more from me