Intel Arc Graphics Conceals Itself To Get Diablo IV Running On Linux

[r1348]

To be honest, Diablo 4 is not worth the hassle.
Get BG3 instead.

[theriddick]

Thinking about putting a A380 in my server for encoding purposes (not gaming).

I've watched some videos saying its great at encoding but no idea how it performs under Linux with OBS. Anyone know? Can it encode as good as a A750 or 770, that is allowing 4k 60fps encoding possible.

[ssokolow]

Also, Blizzard games are incompatible with life and even less to sex. That company are the drug overlords of gaming.

No doubt the reasons Microsoft bought them.

I never liked their games. Anyway, those people trying to should expect issues running them on Linux in the near future. Don't be so naive, Microsoft is extremely passive-aggressive about Linux

I enjoyed Warcraft 2 and Starcraft as a kid. The original Warcraft was boring unless you turned up the walk speed to max, but it had its appeal, and I dabbled in Diablo. Heck, I even enjoyed a bit of Warcraft 3 and Diablo 2 before the period when I got so fed up with Windows XP that I switched to Linux and more or less ditched non-emulator gaming in favour of my at-the-time anime, manga, and fanfiction addiction.

[sophisticles]

It's doubtful. Some people here are purists that only use FOSS software. Some people are even more extreme than that and won't use certain kinds of FOSS because it doesn't have the right kind of FOSS license.

Yeah, they are the very rare type of purist that insists that they play closed source proprietary games using only open source drivers running on an open source OS.

Perfectly logical and obviously a very well thought out belief system.

[ssokolow]

Yeah, they are the very rare type of purist that insists that they play closed source proprietary games using only open source drivers running on an open source OS.

Perfectly logical and obviously a very well thought out belief system.

Aside from my nVidia drivers being grandfathered in, I'm one of those people. It's about three things:

1. Games have demonstrated that they're not readily amenable to the "refine a long-standing need over a decade" approach that open source excels at. (ScummVM and OpenTTD are examples of how that dynamic changes in the rare cases when you've got a dedicated enough fanbase to provide their own extended support.)
2. I can sandbox games. I can't sandbox package managers, drivers, etc.
3. If a game breaks, i'll be annoyed, but I won't suddenly need the ability to write a patch and compile a patched version to restore functionality I need for work.

Ideally, I prefer to run my games under some kind of virtualized or emulated environment (eg. DOSBox, libretro, etc.) because that means there's a defined, frozen API the frozen game is talking to, and some open-source code dedicated to translating that API to the moving target that is the underlying OS. (Wine's still a bit too much of a moving target for me to prefer it instead of "my choice of native Linux or Wine versions" for that purpose.)

It's all about ensuring that, if my software works today, it'll be a easy as possible to make it work in ten years.

[sophisticles]

[*]Games have demonstrated that they're not readily amenable to the "refine a long-standing need over a decade" approach that open source excels at.

This is a nice way of saying that it takes decades for open source software to be worth a damn.

Gnome had a memory leak for over 10 years before it was finally fixed, curl has had a security vulnerability for over 2 years before the developer realized it, X11 had a security vulnerability for over 35 years before anyone realized.

The for profit model is vastly superior, because you either fix the problem or you lose paying customers and close up shop. MS routinely releases 0-day fixes that no one is even aware exists, open source software takes decades to even acknowledge that a problem exists.

Go file a big report with various open source projects and watch the responses:

1) At best they will tell you they can't replicate it and close the ticket.

2) They will accuse you of "trolling".

3) My personal "favorite" response: "patches welcome".

Imagine if Microsoft or Apple responded to a bug report with any of these.

It's all about ensuring that, if my software works today, it'll be a easy as possible to make it work in ten years.

If this is the case then you should be using Windows. Windows is legendary for having a stable ABI, wgere i used to work we had a custom application that was written in Visual Basic 5, back in the early 90's, that we used through countless Windows upgrades, all the way to Win 7.

When the decision was made to switch the company desktops to Win 10, the application needed to be modified slightly because it used a 16-bit installer that wouldn't run on Win 10, but with a little bit of reworking, which i think amounted to importing the project into Visual Basic 6 and recompiling, the application ran fine.

Linux applications look for excuses to break, a perfect example is Audacity that will refuse to run on certain distros, like Gecko Linux, if it's installed from the repos, but will run if you use the appimage. I always thought that it was because of a missing library, but yast is supposed to hand;e all dependencies, and even if i try to install the libraries manually, you still get hot or miss support. Handbrake is the same way, though if i manually compile these from source, or install the flatpak, they work fine.

Sorry, but Linux stability is a mess, whenever i read posts claiming how reliable and stable Linux is i assume that they are not doing anything of note with their computers other than creating a few text files.

[ssokolow]

This is a nice way of saying that it takes decades for open source software to be worth a damn.

No, it's a nice way of saying that open source works best for stuff where a bunch of enthusiasts can slowly catch up to a niche where too much change will drive away customers, like OSes, office suites, etc. while games are much closer to "sprint for a year, then throw it away and start over".

There's a reason Godot is where Blender was maybe half a decade ago but the games made in it that you see on places like GOG.com and Steam are ordinary closed-source games.

Opera and Netscape as paid retail products are dead. Microsoft Internet Information Server and Windows Server are increasingly confined to enterprise deployments. Paid programming languages like Embarcadero Delphi (formerly Borland Delphi) are clinging to niches. Blender has been gaining steam and the anime studio Khara announced a switch to it in 2019. DOSBox and ScummVM are the most popular way to re-release vintage games.

It's like the parable of the tortoise and the hare. The hare may be first out of the gate, but if you give him enough time, the tortoise will win. Slow and steady wins the race. The only niches where open source isn't on that track are ones like finished games, where the nature of the market keeps pushing a reset button before open source can catch up... and we still see a forest of engine remakes like ScummVM, OpenTTD, OpenXCom, VCMI, and on and on and on.

If this is the case then you should be using Windows. Windows is legendary for having a stable ABI, wgere i used to work we had a custom application that was written in Visual Basic 5, back in the early 90's, that we used through countless Windows upgrades, all the way to Win 7.

And yet there are tons of 16-bit and early 32-bit games that require either a move to the Windows XP machine in my retro-hobby corner or the installation of something open-source like DOSBox (plus Win3.1) or Wine/WineVDM that'll run just as well on Linux as on my airgapped Windows 7 "gaming console that's not a console" that I have KVM-switched together with my Linux daily driver for quick and easy leisure breaks.

(I don't consider anything post-Win7 fit for purpose, any more than I consider the OSX side of the Power Mac G4 in my retro-hobby corner to be a demonstration that Apple made both Mac OS and UNIX locked-down and boring in one fell swoop. The only time I boot the 10.1 off its restore discs, or the 10.3, 10.4, or 10.5 off the retail discs I bought, is when I need to generate test data from things like later versions of StuffIt, where they won't run on Mac OS 9.2.)

With the Linux stuff, it works well enough (especially with Debian Stable or Kubuntu LTS for the base OS and Flatpak for the apps) and, if it doesn't, I know enough C and C++ that I have a decent chance of fixing it myself.