Quoting: EhvisDon't believe everything you read on the internet. Business decisions are not based on the behaviour of screaming children.

Indeed!

Alas, they did get a good share of flak when they announce that it'd use iON. In the end it didn't matter.

View this comment - View article - View full comments

That is correct, and while Proton has been beneficial in terms of enabling us to run games that would not be possible otherwise, it has hurt new developments in a big and bad way. I have a food share of mixed feelings. On the one hand it is amazing feat what Proton has done, on the other, while the performance impact is variable and in some cases negligible, there a performance hit. Plus the lack of features that would native Windows gamers have experienced (like RT, despite it being a moot point in most cases), but also quite beneficial DSSL and similar tecniques, which do enhance the gaming experience, which (AFAIK) are not supported under either DXVK or VKD3D.

I am steadily feeling like Proton has been the nail on the native ports of commercial games for Linux coffin.

I still remeber the community rage when CDPR said thet The Witcher 3 on Linux would use a similar translation layer as TW2, and the uproar resulted in no port, and how wild we got to see the game running under DXVK and Proton. Bottom line, "Linux needs no native support, the games will be made to run using translation layers, anyway".

Chicken and egg situation, who are to blame, us users or developers? I lean towards no one, since the simplest would be toonly ensure good wine compatibility (and sane API selection) in order to freely reach a wider audience.

I guess the figures of the amount of users gaming on Linux with Windows only games, metrics that Valve supposedly report back to vendors and developers, are not as good as we would like to beleive.

View this comment - View article - View full comments

Quoting: Creak

Quoting: Purple Library GuyHave there been decades of 3D graphics?

I'm pretty sure we can find something in the 80's quite easily 😉

Remember Pixar and Luxo Jr. Saw the light in 1986

View this comment - View article - View full comments

I thought part of this stems from Vendors such as AMD no longer providing OpenGL drivers for Windows. Alas I am uncertain as 1, I do not have Windows and 2, nor an AMD graphics card. But I did read somewhere AMD was stopping Open GL drivers on Windows (do not quote me on that, I'm sure I read about it, just do not remember where, so...)

Now why go the DX12 route rather than Vulkan route (which, I'd assume could provide higher version OpenGL compliance, since hw compliance for VK is roughly the same as for GL 4.5), I'd assume is because it would be expected better DX12 support rather than Vulkan support from IHVs, especially hardware found in Microsoft devices. So I guess this is twofold: For better support for Surface devices, as well as having a broader catalog of (older) games for the Xbox. Sure CAD applications and medical could also benefit.

View this comment - View article - View full comments

On the topic at hand, good. It only makes sense for both Deep Silver and 4A Games to have the hole saga on Linux. Great news, indeed.

I have had mixed feelings about both Proton and Stadia since their respective releases. Both technologies are interesting and tackle different "problems".

Since its announcement and release, Stadia was seen by many as a bridging tech that would bring more games onto Linux. Personally I never saw it as such, as has been proven time and time again, it is up to the publisher which platforms a given game is released on. It is clear that for the likes of Ubisoft, and whoever plublishes Bungie now a days, that desktop Linux is not worth, regardless if they have their games on Stadia (which in itself has proven to not be the solution it was hyped and hoped to be, that's totally besides the point, though might have influence).

From a technical stand point porting games involves more than just the core technologies, remeber when Unreal Tournament 3 port was cancelled (despite Ryan having it running and showed a screenshot in Ubuntu) due to some obscure middleware (theorized to be PhysX or more likely some other anti-cheat software, only Icculus knows for sure). Ultimately it got canned all the same. So despite overcoming all technical difficulties, upper management canned the project. Be it that the company holding the rights of said middleware not allowing Icculus to make it available to the platform, or Epic or whatever. Tradition was broken at that time.

Punlishers and parent companies have the last saying in if a game is or not released in a given platform. Which is where technologies such as Wine & Proton are most welcome, but all the same are no Panacea. Wine has had a number the issues over the years, and while it is an amazing piece of tech, it is prone to breaking compatibility with certain programs, especially if said support was present in a form of more of a hack, than actual proper support, which when implementing a given feature might wreak havok among the earlier 'supported' software. Take a look at ProtonDB to see which games that were able to run (not necessarily 'white listed', though) break in any given release of Proton (even if the underlying version of Wine remains unchanged). That part of always playing catch up, as wine is forced to do, regardless if it currently supports Win9x programs and titles even better than Microsoft's current OS does, puts it at a disadvantage. By principle.

It has been also said by other efforts to get games on Linux with as little effort as possible that part of the problem is a format issue. Assets format at that. Especially textures, which have to be converted from DirectX to either neutral or native formats, and that goes beyond compression algorythms, that is why there are technologies such as Valve ToGL, to perform on-the-fly translation of assets, and which has achieved high performance, in the early beta days of Steam even beating the native Valve ports of games such as Left4Dead2. I am not sure how difficult would it be for developers to have a common pool of resources for games depending on the platform they are released. I suspect that in the end is the DirectX versions (Windows, Xbox) the ones that require special formats, but I am uncertain.

In the end I do celebrate more native ports. Coming from the late 90s days where we hardly got any commercial games to where Linux as a platform is at with Steam and GOG, and Itch and Humble (even though it mostlybare Steam keys) is simply amazing.

View this comment - View article - View full comments

On the topic of screencasting and gameplay recording is what is especially interesting.

On occasion I record my games (never have performed live cast) and I do like to do so for the occasional tut for friends and family.

I have read about that AMD and Intel hardware are now able to leverage VAAPI to use hardware encoders for screen capture be it with OBS or other programs, and OBS only recently (release 24 I think?) added such support.

Now in terms of performance I am a bit sceptic. nVenc has come a long way from lesser Kepler (GTX 600) to Pascal and current Turing boards. I did notice a HUGE difference both in quality and performance when using nvenc on my older desktop GTX 760 card, the laptop's GTX 950 (when running only the blob, so no hybrid graphics) and my current desktop's 1080 (non Ti, and I believe that the jump from Pascal to Turing for nvenc is of about 20%), from Kepler to Maxwell was the biggest jump than from Maxwell to Pascal, which was noticeable, but not as noticeable as the previous, and seems to be a similar case with Pascal to Turing. With my GTX 760 just recording the desktop (in Linux) I could have some dropped frames (dunno if that was the case on Windows as well, might have been a driver issue altogether) and sure enough driver maturity has come a long way for nvidia (even though I am fully aware they care next to nothing about its customers).

Now, what performance, encoder (support and settings), and general quality can you expect to achieve when using hardware encoding on a modern Intel/AMD part in Linux? Especially interesting would be to know if you see an actual performance hit on your gaming (for instance) when using it.

I'm sure this will be of particular interest to that segment of the Steam community that actually wants to stream their game casts from Linux. And to measure how would this compare to nvidia's nvenc offering.

I celebrate that the people in charge of the project have finally implemented this, so now it would be only a matter of allowing the technology to mature and only get better performance, more robust, improved support for different scenarios and software combinations, etc.

I hope the work from Valve on pushing forward Wayland and keep X11 as a compatibility layer for older software/games will make nVidia shift and start working towards a truly common and universal resource allocation API that will benefit us all (wishful thinking), and that includes them as well, if only for those niches they really care about. Still, I am convinced I will be shifting from team Green back to team Red in the future (haven't used AMD graphics hardware since my ancient R9500 and the nefarious fglrx days)

View this comment - View article - View full comments

Quoting: Shmerl

Quoting: ThetargosAny news on multithreaded input support in Wayland yet? About the most annoying thing (for me) in modest systems (I still have and use a netbook, for simple tasks) and Xorg is deffinitely faster in such scenarios, particularily input-wise than Wayland, and reading about these issue, seems it stems from the fact that Xorg has at least the mouse input in a different thread than the window-drawing, and it does show especially under load. Good thing Valve are getting behind further wayland refinement and pushing it forward.

Wayland is a protocol. Multithreading has nothing to do with it. It's up to the compositor to use it. I.e. a proper compositor can be multithreaded, use Vulkan and etc.

I.e. some compositors could indeed be bad. It doesn't mean Wayland is, or all of them are.

Indeed, alas (AFAIK) you cannot use say Weston with Xorg. My experience is rather limited with it as I have only used Weston and did notice that under load, mouse input is rather sluggish, which is not the case with Xorg, albeit in a rather weak netvook sporting an Atom N270 with GMA915 graphics, which speaks volumes in terms of modern [E]GL feature support, but which runs just fine Xorg with composition either through WM (XFCEWin/Sawfish) or even GL accelerated Compiz.

Edit, typos, darn phone keypad.

View this comment - View article - View full comments

Any news on multithreaded input support in Wayland yet? About the most annoying thing (for me) in modest systems (I still have and use a netbook, for simple tasks) and Xorg is deffinitely faster in such scenarios, particularily input-wise than Wayland, and reading about these issue, seems it stems from the fact that Xorg has at least the mouse input in a different thread than the window-drawing, and it does show especially under load. Good thing Valve are getting behind further wayland refinement and pushing it forward.

View this comment - View article - View full comments

BMS Vs original.... tough call. Having the context of the original, especially given the computational resources available to consumers back then, many of the elements we see in BMS are missing, and even feel like prototypes rather than the final version, however, as stated above, one key aspect of the original game was the sound design. Up that point very few games had had such immersive soundscapes and environments, which even though in BMS has been carefully respected, feels a bit odd. I absolutely LOVE the amount of details they put into the environments (especially the first levels where the original felt a bit flat, even back then) and the Homage they present (for instance in the teat chamber, you can see in the screen of the emitters that Freeman has to activate), shots of the original level in the editor, nice touch.

Some of the voices, for us purists, sound off, as is the voice acting (and I do not mean it is 'bad', only different from the version embedded in my hypocampus as aural memories!), and hence collide to what my monkey brain expects.

The original has a fluidity, which confers a distinct feel to it, inherited from the original engine (quake) morphed into the GoldSrc engine, which the Source engine does not have, or rather is different (which is essentially the same as in HL2), and again collides with my propioception and how I remember it, so not bad, just different (though very polished).

I still hold the original Half Life dear, and IIRC, it has been staed several times that the final chapters had to be heavily modified from the original plan due to time contrains, or some such.

I still miss seeing video cards flying when you break crates in BMS, which I thought was a nice joke from Valve back in the day.

View this comment - View article - View full comments

Is amazing the amount of artifacts that CRTs hid from sight, plus the veil of nostalgia.

View this comment - View article - View full comments