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

Quoting: eldersnakeArch Linux has libGLEW2.0 as opposed to libGLEW1.13, so I too encountered that problem (of libGLEW1.13 being missing).

I'm sure someone will say this isn't quite the proper way to do things, but I got the game running by symlinking libGLEW.2.0 to libGLEW1.13

sudo ln -s /usr/lib32/libGLEW.so.2.0 /usr/lib32/libGLEW.so.1.13

write these kind of solutions on Archwiki! :)

View this comment - View article - View full comments

Quoting: neowiz73when steam hit the active users of 125mil mark it had 8.9mil concurrent users. In January 2017 Steam had 14mil, considering how the amount of Linux user sort of dropped % wise. it would be because of a surge of new players.

considering the average of concurrent users when up an average of 62%. which would put steam roughly 202mil active users. Linux users are roughly 1.25mil in February 2015. and are now approximately 1.6mil in 2017 so far.

Yes, steam has expanded really fast, and is expanding faster in Asia. So if Asia has relatively lower linux percentage, even if linux is expanding everywhere including Asia, then its percentage on steam will fall. I think this is really what is happening. The expansion of steam in Asia makes linux percentage drop (or at least not rise)

It would be really interesting if we could see percentages per country

View this comment - View article - View full comments

My opinion is that Valve should do something like a combination of Steam Direct and Greenlight.

To be more exact I am thinking that Valve could collaborate with a completelly open platform (itch.io maybe). The idea would be that Steam Direct could have more cost as a flat $100 can not work well in all cases, but developers/games with good reputation on the other platform could have a free pass on steam. That I think would benefit everyone. It would benefit Valve as Steam would have better quality control, it would benefit a platform like itch.io as it would have more attention, it would benefit indie developers as they would have more choice.

View this comment - View article - View full comments

Quoting: Andrei B.Wow, 7nm.. Impressive.
Ten years ago we thought that 23nm was the physical limit.

I don't remember that. I for many years now remember the physical limit be considered around 5 nm (and it is getting there now as it seems). Moore's Law also considered to be halted in 2010s. 7nm is really impressive but not too unrealistic. Intel had stopped at 14nm for a some time now and either intel wanted Amd to catch up or already is getting proportionally way more difficult. Of course now I believe we Moore's Law is near the end and will not be continued in 2020s as already have happened for many years now with frequencies. In any case 1nm is very near the atomic scale.

View this comment - View article - View full comments

I have already a huge backlog so it is nearly imposible to get really excited anymore... BUT

1) All the games do support Linux!
2) All the games are DRM-free!
3) I do not have any of the games and they all look interesting

This hasn't happened for years...

View this comment - View article - View full comments

Quoting: GuestYou are right in that the ABI unstable nature of Linux makes it difficult to support well.

The Linux as a kernel has never break ABI. The problem is always other dependencies. It is not Linux fault. So the solution is not to "fix" Linux but to "fix" development for Linux as a platform so the developers would do the right thing by default without even thinking about it.

View this comment - View article - View full comments