I am actually likely to be buying a case soon. (I'm going to be forced, kicking and screaming, to upgrade beloved hardware because of AVX instructions creeping into things)

If I were to get one, it would be the largest size, the Nebula49. I always buy a big, full tower case and full ATX motherboards, to accommodate big video cards, if not now, later. The bigger your case, the more likely it is you'll actually be able to use slots on your motherboard too. The bigger your case the more air space there will be around components, PSU further away etc.

However, I'm not sure I'd go this route because I'd have to purchase fans and accessories separately, whereas a big Corsair or Antec case will come with everything I need and more (extra doohickeys... "WTF is that for?" lol)

Also, I'm afraid the prices of those cases are pretty high for what it looks like you get. We're into high end enthusiast case prices here.

View this comment - View article - View full comments

Wow, that's awesome. I'm sure everybody here is just dancing in the streets because they can play "Toilet Invaders" now :tongue:

(I'm sure it's "crap" if it needs Proton workarounds lol)

View this comment - View article - View full comments

Quoting: dziadulewiczDoes a significant portion of Linux gamers have a short memory or just being naive? Microsoft :heart: Linux zilch or has changed one bit when looked closer...

I wouldn't say that, nobody is actually praising this situation, they just aren't belching forth the brimstone and fire.

The site certainly isn't wrong to showcase a marvelous looking game though (I'd want this one), I just hope folks actually get to play it, "later down the road" as the PR statement goes.

View this comment - View article - View full comments

I'll never buy anything developed or published by Bethesda now... that's Microsoft. It's not even just vindictive hatred (though, guilty as charged), I simply don't trust that they won't wrap it up in some detestable UWP/Microsoft Store interface either now, or down the road when they convert all their titles. I'll be lucky if they leave the Bethesda games I already have, alone.

It is also my opinion that Microsoft intends to undermine the Steam Deck and what Valve is doing. Look at what they did with that Asus handheld running Windows... Microsoft offering Steam Deck trade-ins. Despite their smarm, the leopard has neither changed its spots nor has it lost its appetite for your face.

P.S. If anybody thinks Microsoft has any noble motives in buying game publishers and the studios under their auspices:

Indiana Jones Game Is Not Coming To PS5 As Bethesda Confirms Xbox-Exclusivity
https://www.psu.com/news/indiana-jones-game-is-not-coming-to-ps5-as-bethesda-confirms-xbox-exclusivity/ [External Link]

MachineGames’ highly anticipated Indiana Jones game is an Xbox console exclusive, Bethesda’s Pete Hines has revealed while speaking in court yesterday on the opening day of Microsoft’s battle with the Federal Trade Commission.

FTC lawyers asked the executive if Disney had signed a deal with Bethesda parent company ZeniMax prior to Microsoft acquiring the studio to “make an Indiana Jones game for multiple consoles,” with Hines replying “yes.” He later confirmed that Bethesda had amended the Disney agreement so that he game would now be appearing exclusively for PC and Xbox platforms.

View this comment - View article - View full comments

I got on that this morning before bed. Indeed, some new stuff to say "n" to :-)

I haven't used it yet in 6.4 and don't have cause to, but I've noticed that ntfs3 driver in kernel is getting good. That's the one donated by Paragon, the commercial NTFS driver for MacOS (also reverse engineered). When it was first ported it had some bugs that took a while to get fixed. Not serious for me, but NTFS is a scary FS. It's been my rule that if I EVER write to an NTFS filesystem from Linux, I run chkdsk on that volume as soon as its connected to Windows again. The old ro driver was dangerous for writes (it was OK if you didn't change the length of files, for example, blanking a password hash in a Windows SAM registry database) and while NTFS-3g is much better and generally regarded as safe, I still used to find inconsistencies (not really errors) on running chkdsk. I also like the simplicity of just having to modprobe a driver. (I don't like maintaining things like ntfs-3g and Samba for SMB, which is also in my kernel now)

Anyway, I'm no longer afraid to connect a Windows hard drive and write to it and put it back. I wouldn't have done that with a customer's hard drive (other than the password blanking usually with a boot disk on the system), but now I have more confidence. The Windows chkdsk doesn't complain at all lately.

P.S. I mean to say, everything I need to interoperate with Windows is in kernel now (well, some small utilities that don't change much, to use those features)

View this comment - View article - View full comments

Quoting: CreakAnd also, is Valve planning on using Wine's implementation at some point?

My guess would be no, because it's implemented quite differently. Calling it a "fork" may have been true at inception, but vkd3d-proton doesn't really have a lot to do with Wine's implementation anymore.

First of all, Wine's vkd3d has libraries on the native side (that's where the business end is) while vkd3d-proton is the directx dll implementation (d3d12.dll, which loads d3d12core.dll now in current versions) and wine dll overrides (wine registry). For it to be actually useful, you still need to cross-compile Windows dlls with mingw as things will expect the PE binary format though, so it doesn't really save you anything. In Valve's Proton Wine fork, vkd3d is not enabled in the Wine build in favour of using vkd3d-proton. (I mean this in context of it not just being a drop-in replacement etc.)

It also does not follow the Windows DirectX 12 APIs as well, where the vkd3d-proton implementation at least strives to. vkd3d-proton is not backwards compatible with vkd3d either (i.e. you can't just go and switch Proton over to use that)

Better shader pipeline handling too.

Not only that, vkd3d-proton uses DXVK's implementation of DXGI (DirectX infrastructure). vkd3d-proton has a lot of C++ code.

Add all that up, and Valve isn't going to want to switch implementations.

View this comment - View article - View full comments

I noticed last night, when removing a Steam game, that it completely removed the appid directory in compatdata, probably for the first time ever. Before I remove a Proton game I always grep the .acf files in steamapps, so I can find its appid in the compatdata directory to remove the wine prefix.

One time I cleaned out my Steam directory of all disconnected flotsam (leftover game directories in steamapps/common and wine prefix data in compatdata, and some of them were full blown 500M or 1G wine prefixes) and freed up 22 Gb of space after several years of using the same Steam directory. (I have mine on another drive, I consolidated it and moved it a few times and it's survived like 4 linux distro changes) 22 Gb, that's significant on a 2 TB NVME drive that's filling up, that's prime real estate.

It's not a problem anymore, but for a while (several years ago) Steam was storing its own fontconfig cache files in the game directories and they were piling up because new directories were getting plunked down. I used to nuke those with a script, thousands of them.

So I'm glad to see they are paying more attention to cleaning up after themselves. I have a no littering policy.

View this comment - View article - View full comments

It's a Unity game, so you'd have to be a tubular shaped organ not to have a Linux port, these days. (with Steam Deck and all)

View this comment - View article - View full comments

Just look at what anybody says for "supported Linux versions". Steam still links against libraries for Ubuntu 12. If you believed developers' Linux system requirements, you'd think old Ubuntu was the only thing viable, when it many cases it's not even correct, something may bomb out on that old library stack now as things have been updated but not thoroughly tested on those old environments.

If your stuff doesn't work because of things like older SSL, blame your distributor for not supplying OpenSSL 1.1 for compatibility. Even if they don't want you linking against it, they should be supplying compat libraries. (OpenSSL 3.x is neither binary, nor source compatible).

Distributors don't want to support all this (funny how you don't hear community distros whinging) so they want to shift this to applications running in containers. Make it everybody else's problem but theirs.

This is also where Steam comes in handy with its runtimes.

Supported and working are two different things. The latter is what counts.

P.S. Of course, for really old native games you might have to drop some libraries in the game directory, or have some old libraries found using LD_LIBRARY_PATH. But you can still do that.

View this comment - View article - View full comments

Hmm, yes, I rather like GOG's GTK+ game installer program. It doesn't like my styling much, but it's navigable and functional.

For me, when GoG has a native Linux game I want, it's a royal treat. That means I can even run it on my "From Scratch" system (no 32 bit userspace and therefore no Steam)

View this comment - View article - View full comments