Quoting: Liam Dawe

Quoting: Comandante Ñoñardo42GB!!!???

20GB of that is just teenage angst 🤪

Compressed or raw?

View this comment - View article - View full comments

Quoting: jens

Quoting: GuestBuying games with Linux support and supporting Linux gaming is being a martyr? Buying Linux games is what Linux gamers do and should do, lol...but if you want to be a Windows gamer, have at it.

You're on the wrong website, though, because this is for Linux game news, not for Windows games. Go to pcgamer.com or something if you want Windows game news and don't care about Linux games.

Yeah, this is the correct attitude to get more people using Linux, excellent thinking! :)

I think at this point it is fairly obvious that they are either just trolling or went completely off the deep end with their "us vs them" shtick.
My suggestion in either case is therefore:

View this comment - View article - View full comments

Quoting: dvd

Quoting: haikuThis port is useless, it arrived way to late and the game is running fine via Proton :|

Guess all the people who call out linux gamers asking for linux support on the steam forums to stop using the inferior linux os and start using the - in every way - superior windows os were right after all,

No idea how you came to that conclusion.
I use Linux almost all the time nowadays, because it just suits me much better than Windows, and can play all the games I currently want to play with it.
Some natively, some via Proton. Must have been months ago that I used Windows for some game that I couldn't get to work on Linux.

If at all, the existence of Proton and how well it works (About 60-70% gold+ coverage, tendency rising, obviously) just shows how good Linux is if it doesn't even need native support to play a game.

Quoting: dvdsince it seems like even the "linux gamers" on GoL are commenting under every article mentioning a linux port how it's useless and they want to play the windows version with an unsupported compatibility layer. Pretty amazing.

You're making a lot of fuss about nothing.
If a game works well with Proton, it works well, and you will not have a single downside playing it that way.
If it doesn't work well with Proton, you'll either not play the game at all or dual-boot.

This myth of the great downside of "unsupported" is just that, a myth.
It either works or doesn't. The case that it works but then something breaks it only for Proton is rare enough as to be irrelevant.
And the most common case is probably in multiplayer games when EAC is added or sth. like that.

View this comment - View article - View full comments

Apparently, the Borderlands 3 version on Stadia is several months old.

https://wccftech.com/borderlands-3-stadia-two-month-old-build/


Great move there.
Trying to sell not having to update your games on your machine anymore.
Result: Playing old, unpatched versions...


Hard to put the fault on Stadia here, but that doesn't exactly help their rep, either.

View this comment - View article - View full comments

Quoting: Sir_Diealot

Quoting: TheSHEEEP

Quoting: rkfg

Quoting: Eike

Quoting: rkfgDXVK has a "fundamental flaw" and that is the language it's written in. Wine doesn't accept C++ code, unfortunately.

Now I wondered what they're using.
Pure C?!?

Yes, Wine is written in pure C.

Guess that is one way to make sure a project never has too many people working on it.
What a waste of potential.

Pure C is fine for smaller projects or concise little libraries.
But big ones purely in C is just nightmare fuel. Go take a look at the FFmpeg sources if you don't believe me.

Alright, merge Wine into DXVK, then ;)
C++ isn't picky about having some pure C code within.

Well, there is this little project called Linux that is written in C.

That is a special case as it is a very, very, very old project - 30 years by now? More?
C++ was standardized in 1998, it is younger than Linux itself.
I wouldn't really want to rewrite it to C++, either, if I had been working with it in C for over a decade. At that point, no language better suited in theory will offset the sheer amount of experience. It's not like you can do anything in C++ that couldn't be done in C, it is simply easier to maintain and to code in.
And even if it did switch, what about the endless amounts of modules and packages relying on its C-Style interface.
Nonono, nobody would want to change Linux to C++ just for the sake of it being C++ then ;)

View this comment - View article - View full comments

This actually makes it a lot more likely that I'll give it a go.

View this comment - View article - View full comments

Quoting: Shmerl

Quoting: CreakOff-topic: I don't agree with all the language decisions in Rust, notably the different behavior just if you prefix your variable with `_`:
    // The compiler warns about unused variable bindings; these warnings can
    // be silenced by prefixing the variable name with an underscore
    let _unused_variable = 3u32;
Knowing that there is already a way, which is clearer IMO, to silence some warning. See first lines in https://doc.rust-lang.org/stable/rust-by-example/custom_types/enum/enum_use.html

Yeah, I suppose it can eventually get trimmed (i.e. special meaning of _), unless they have some backwards compatibility concerns about not breaking the current behavior.

That's my biggest gripe with Rust.
It tries to enforce a crapload of conventions, from coding guidelines to how it focuses so much on memory safety that it makes some convenient coding rather impossible.
Basically, you code in the one way Rust wants you to, or you gtfo. Feels too restraining to me, especially considering coming from C/C++, I do know how to keep memory safe myself, I don't need that "safety net".

If the language would open up more, that would make it quite nice.
But of course, it will live or die with its supported libraries and right now, that doesn't look too great.

View this comment - View article - View full comments

Quoting: Creak

Quoting: TheSHEEEPGuess that is one way to make sure a project never has too many people working on it.
What a waste of potential.

Pure C is fine for smaller projects or concise little libraries.
But big ones purely in C is just nightmare fuel. Go take a look at the FFmpeg sources if you don't believe me.

Alright, merge Wine into DXVK, then ;)
C++ isn't picky about having some pure C code within.

Just to be the devil's advocate for a few minutes: good written C code is not so bad. After programming in C++ for more than a decade, I can now see the appeal in C code (sometime). It boils down to being leaner than a C++ code.

The problems really only arise in large projects.

Code is about 10x more often read than written (or more, even).
Thus, making code clear and being able to follow it is more important than either raw speed (especially since C++ isn't really slower than C) or having to write less.
In large projects in pure C, you will have algorithms spanning dozens to hundreds of functions over possibly just as many files. You invariably end up with endless amounts of spaghetti code. It is the inherent flaw of procedural programming - awesome for smaller scales, nightmarish for larger scales.
While the OO-focus in C++ at least makes it a lot less likely to end up with code like that (though not impossible, obviously), as code that belongs together is way more likely to be grouped together and the concept of objects which "do things" is inherently more friendly to the human brain.

And for some reason I will never understand, long-time C coders tend to almost never write comments and almost never have variable names longer than "a, b, c, d, v, x, z"...
It is the devil's work, I have no doubts about it.

Either way, what makes no sense to me is not using C, but not allowing C++ at all.
Have the C++ code be exposed via C-style functions (the famous extern, indeed) so that the core devs can keep their precious. Compile apart, then link.
I just don't see the point in not doing it that way, other than some weird sense of purity.

View this comment - View article - View full comments

Quoting: rkfg

Quoting: Eike

Quoting: rkfgDXVK has a "fundamental flaw" and that is the language it's written in. Wine doesn't accept C++ code, unfortunately.

Now I wondered what they're using.
Pure C?!?

Yes, Wine is written in pure C.

Guess that is one way to make sure a project never has too many people working on it.
What a waste of potential.

Pure C is fine for smaller projects or concise little libraries.
But big ones purely in C is just nightmare fuel. Go take a look at the FFmpeg sources if you don't believe me.

Alright, merge Wine into DXVK, then ;)
C++ isn't picky about having some pure C code within.

View this comment - View article - View full comments

Good. Now merge DXVK with Wine.

View this comment - View article - View full comments