Quoting: Shmerl

Quoting: F.UltraTHQ is just the publisher. Airship Syndicate is the studio behind Darksiders Genesis.

And commonly such things are blocked on the publisher level. I.e. since developers already released it for Stadia, they shouldn't lacking Linux expertise.

Normally yes and it would indeed be very interesting to hear THQ:s side of this. Could be that normally THQ is not against the dev studio releasing also on Linux but that Airship is not interested. Could be that the Stadia port is not yet in good shape enough to be distributed as a stand alone version, could be that THQ as a small studio is already busy enough with them releasing it on stadfia+steam+xbox+switch, could be a million things.

View this comment - View article - View full comments

Quoting: Shmerl@Liam: May be writing to them would be a good idea, to clarify what's blocking normal Linux release in this case.

I.e. in case of legacy publishers, such situation would be expected, but from THQ Nordic, I expected something better.

THQ is just the publisher. Airship Syndicate is the studio behind Darksiders Genesis.

View this comment - View article - View full comments

Quoting: Liam Dawe

Quoting: KimyrielleSo essentially people are dissing on Feral for getting permission from a company to port a game to Linux, because the same company also happened to allow them to port their previous games?

That makes sense! *nods*

>>
<<

/sarcasm

Seriously, I think people still mistakenly assume that Feral picks the games they port. From how I understand it, it's more that they have to beg them to let them do it, because nobody in big gaming business gives a flying fish about Linux.
I dislike the lack of AAA games on Linux as much as anyone, but the truth is that other than Square Enix and the Total War devs, nobody seems to be interested in Linux ports, so that's what Feral is porting.

It's like some people think we have a market share of 50% suddenly or something. The fact that Feral still port anything, at all, is frankly amazing and appreciated because:

- Their work is top stuff
- They contribute to the community as well
- They've contributed to Mesa drivers
- And so much more

That and the fact that we have no large company that can give publishers the big PR that Sony or Nintendo can do. I mean port your AAA game to the Switch and you will get tons of free advertising from Nintendo on E3, in stores and various PR extravaganzas.

View this comment - View article - View full comments

Quoting: Patola

Quoting: Sojiro84But would be nice to see how the performance compares later.

This is worrisome, Feral ports are stopping being games and being useful only as a proof of concept and performance gauging. Many people will stop buying from them because of that.

That's exactly the reason why Feral should focus in getting deals to port the AAA games which Linux does not already run, like the anti-cheated multiplayer ones (Destiny 2, PUBG, etc.) -- and they're pretty well acquainted with DRM, so it should not be a problem. Otherwise, they just will not have a market anymore.

There exists no long list of AAA publishers that will allow Feral to port and sell their games to Linux. Either the big publishing houses don't want to sell the rights to the Linux market in case it one day becomes really large or they are asking for a too high price for a small company such as Feral.

View this comment - View article - View full comments

Quoting: x_wing

Quoting: Comandante ÑoñardoI guess there must be a reason for that naming scheme, like some kind of structural legacy from older versions of Windows. .

Indeed, they say that it's for legacy purposes. IMO is because they are lazy and didn't want to fix their PE loader.

It's because every single application + installer script had system32 hardcoded as a path so as to let people just be able to straight up compile 64-bit versions without any other changes they decided to go this idiotic route. And when it detects that you run a 32-bit application the OS redirects everything so these applications still use system32 even though they in reality store files in SySWOW64.

What is a much much worse problem is their "invention" of releasing version specific versions of libc for each and every release of Virtual Studio. Something that they themselves apparently finds idiotic since all of their own applications don't use them, they link instead to the versions provided by Windows itself...

View this comment - View article - View full comments

Quoting: dpanterUh... this thread is derailing into false information territory.

Linux native version of Dying Light runs well with AMD Mesa, even with a Radeon VII. Doesn't need a special build of libGL.so.1. Any recent Mesa version, say 19.x should be fine. The performance last time I tried was actually pretty good, not at all the horror show it has been. Definitely playable with a good experience. DXVK still performs better and the Windows version has additional graphics options.

I played the native version on an AMD card back when the 17.x series just managed to get it working. Since then there's been ups and downs with the Mesa versions but today it should be fine. The black screen bug happens for Nvidia users as well as in Windows too, not Mesa specific.

The granary bug is also not related to Mesa. Unfortunately The Following has only 3 quests from which you can start again, it's basically start, middle and end.

I strongly recommend backing up saves for any game where you really care about the progress. Even if the game itself behaves, Steam cloud can bork saves now and again. Not specific to Dying Light.

I thought that the needed fixes for EXT_direct_state_access was to be in v20.x and not v19?! Without it and if your version of mesa is compiled with glvnd the game sefaults (that is the fix in the special build of libGl that it removes glvnd).

And yes I know that the granary is not due to mesa, it's not even Linux-specific since there are reports from PS4 players crashing there.

For any one interested in why DL segfaulted here on mesa:

First, some background. The game uses __GLEW_EXT_direct_state_access to detect whether the EXT_direct_state_access OpenGL extension is available. In experimental mode (glewExperimental=GL_TRUE), GLEW implements those macros by calling glXGetProcAddress() for every function that an extension is supposed to provide. If the driver returns non-NULL for every function in that set, then the macro evaluates to true. And if the macro evaluates to true, then the game will use EXT_direct_state_access functions such as glMapNamedBufferRangeEXT.

Mesa does not implement EXT_direct_state_access, and returns NULL when its functions are queried with GetProcAddress(). GLVND, however, provides stubs for all OpenGL functions, and returns the stub in glXGetProcAddress(). The stub will eventually end up calling out to the vendor's (Mesa's) implementation of the function when a context is created and the vendor becomes known. The upshot of this is that glvnd will return a stub for every function in EXT_direct_state_access, leading the GLEW macro to return true, and the game will attempt to use those extension functions.

The trouble begins when the game tries to use glMapNamedBufferRangeEXT(). This function is supposed to return a pointer to a memory area that maps to an OpenGL buffer. Since Mesa does not implement EXT_direct_state_access, the GLVND stub for glMapNamedBufferRangeEXT remains a no-op, and the return value is undefined. The game tries to write to the pointer that is returned (which of course is not valid as the function was a no-op), and it segfaults.

View this comment - View article - View full comments

Quoting: AsciiWolfDoes Dying Light work on AMD GPUs with Mesa?

Quoting: marcus

Quoting: AsciiWolfDoes Dying Light work on AMD GPUs with Mesa?

It did not the last time I tried about 3-4 Months ago (Radeon VII). Just launched to a black screen. Played the Proton version afterwards, which works perfectly.

It does but it requires a special build of libGL.so.1 that is compiled without what it now was that Techland uses wrongly in OpenGL. See this post: https://www.gamingonlinux.com/forum/topic/2766/post_id=18057

Don't know if they fixed that problem with the latest update or not but the fix from that post above fixed it for me and many others.

View this comment - View article - View full comments

Quoting: fabertawe

Quoting: F.UltraOboy, here:s to hoping that they have fixed the game breaking bug for me where the game always crashed a few minutes after I reach the grainary in one of the last chapters of The Following. I had a solid 116 hours solo gameplay until that one struck.

Same happens for me. Never had a single problem with the game up until this. I read somewhere someone suggesting restarting from a previous point, which I did. Now of course I have to redo all those previous missions again, which is a bit tedious. Luckily the game is a lot of fun!

Yeah that is the dreaded solution, problem with "restarting from a previous point" is that as far as I can see in the menu for The Following that is basically to restart from the very beginning.

View this comment - View article - View full comments

Quoting: GuestSupporting Lutris/WINE means they have no plans for supporting or releasing for Linux.

Not to rain in the anti-epic parade (I still believe that they belong in the dog-house) but Valve supports WINE/DXVK and they do support releasing for Linux so I would say that the one is completely disconnected from the other.

Most likely this is $25k taken from their PR budget but it still have no bearing on whatever plans they have or not have for Linux in the future.

View this comment - View article - View full comments

Oboy, here:s to hoping that they have fixed the game breaking bug for me where the game always crashed a few minutes after I reach the grainary in one of the last chapters of The Following. I had a solid 116 hours solo gameplay until that one struck.

View this comment - View article - View full comments