Quoting: cprnDo you not run Steam runtime anyway? I see no point in running native libs that might or might not work with a particular title. It's way more effective to just use what's provided and tested.

try to run steam runtime on intel or amd. It does not work. You need steam-native. System libraries should not had been on steam runtime they only make the problem worse.

View this comment - View article - View full comments

I've seen a benchmark on youtube of this game where nvidia performs bad with Vulkan but AMD performs the same as DX12.

View this comment - View article - View full comments

Quoting: Ardje

Quoting: Asugot my first survey on my linux! hooray! Gaben always finds me when I'm on my mac lol...

There is a bug report on github of someone getting it on linux and making steam crash.
I was very inclined to reply it was a hoax ;-).

Actually I had the same thing. I was getting it but steam was crashing. Running with steam-native solved the problem.

View this comment - View article - View full comments

I think I already had it probably from some humble bundle (?). But this prompted me to download it so maybe it will escape the backlog.

View this comment - View article - View full comments

steam, arch, intel HD, works perfectly on me.

But I hate them! I was so proud that I completed the game (and the mirror). Now it is not complete again?? Damn!

Also what is your problem with "short" games. I love short games especially 140 type. Game like this the longer, the worst are for me. I just want to try them, have their difficulty but finish them and go on with my life. I do not want length. 140 had the perfect length.

View this comment - View article - View full comments

Quoting: lucifertdarkTypical! Another addition to the Windows only games list in steam that I'll never play.

From the post, they look pretty derermined to make it. And this is problem but not an unsolvable problem.

View this comment - View article - View full comments

Quoting: DamonLinuxPLGuys, guys... This is old title. Main game is from 2010 and engine GRACE used in Two Worlds II by Reality Pump is even older. It not that easy to make old title compatibile with 64 bit like u think. This engine use and it from DX9 era but they add DX10 as backend so in this time almost no one made 64bit games... Even today, many of new games is only 32-bit not because devs wany to support old OSes but just because they use engines that can not work correctly or they have issues with compiling 64-bit. It not that simple, like we can think. Also look, Reality Pump used new upgrade engine to Vendetta Curse of Raven's Cry - and called it GRACE 2 - and still is only 32-bit.

It not that simple, another thing, look why many developers not switch old games to 64-bit now? Why? Look new OS version and every times Windows 8 - this game broke, another not want launch, Windows 10 comes - again, broken games everywhere. So go to 64-bit... ya, right. If this is that simple why most developers still not take it? Because it is not and can completly broke old game...

I get that doing things the right way is not always easy. My opinions remains the same. That is any "real native linux" game should be 64bit only. Tools like wine as a porting tool (not saying to users "use wine") should also be considered for older games, if they are good oftenly it is a really good option.

View this comment - View article - View full comments

I can not understand why so many developers do that elementary mistake on linux. On linux developers should only support 64bit. No one on linux is using 32 bit, really no one. If someone is using 32 bit, he is wrong and he should use 64 bit and if he really has a reason then he is no way a potential customer for any game. On linux we had the "luck" that gaming has become mainstream only recently when everyone was already 64 bit. So it should be that simple as only supporting 64 bit. Why 32 bit is coming from the land of the dead? why?

View this comment - View article - View full comments

Quoting: edoIt all comes down to a simple situation: the guy that ported dx12 vanished and didn't keep supporting it. If he were still around giving dx12 support the situation would be different. It was nice that this emulator provided support for both APIs

from reading more of their reports it looks more complicated and more in favor of Vulkan! Also supporting d3d12 leaving aside the double effort and more manpower is not good for compiling times as they say.

An other quote from the November report

5.0-1241 - Vulkan Cleanup and XFB Support by stenzek

While it was originally planned to wait for Hybrid XFB to wire up Vulkan to the eXternal FrameBuffer, it turns out that feature is taking quite a bit longer than anticipated. Thus, in his latest block of cleanups, stenzek decided to plug Vulkan into the existing XFB code. It was a relatively simple task, and more or less makes Vulkan feature complete. This means that Vulkan can properly run games that require Virtual or Real XFB, such as Star Wars Rogue Squadron II: Rogue Leader.

In terms of overall quality, the Vulkan backend is shaping up nicely. Unlike D3D12, which is still plagued by a lot of instabilities, Vulkan seems to run well on any of the cards that support it. That said, it's not going to revolutionize Dolphin; its merely a bit faster than the standard D3D11 and OpenGL backends outside of a few rare cases, like The Legend of Zelda: Twilight Princess. While OpenGL remains the most accurate backend, Vulkan brings most of the performance of D3D12 without the instabilities in its current form.

View this comment - View article - View full comments

Unlike the D3D12 backend, the Vulkan backend is actively maintained and does not have the design flaws that made D3D12 harder to work with.

From the dolphin link progress report this sentence looks even more "interesting" than the one you quoted.

View this comment - View article - View full comments