On Manjaro I did need to install some extra SDL2 packages like "sdl2_net", and additionally since GOG package for Ubuntu the library name for "libfluidsynth.so.1" from FluidSynth did not match up. Creating a link between what it wants and what the Arch package has will make it work.

Or you can simply take game resource files, and use your distro packaged ScummVM (I'm sure Manjaro should have it) with them, without any library tweaking. That's what I usually do with all such GOG releases.

View this comment - View article - View full comments

Awesome! Instabought it. Huge thanks to ScummVM developers for reconstructing the engine, and to GOG for working on getting the permission to release it!

View this comment - View article - View full comments

Quoting: Beamboom[Look at Apple.
They have 6-7% of the desktop computer market. Big fucking APPLE! One of the richest companies in THE WORLD!! Apple, who spends who knows how many billions on advertising across the entire world has only 6-7%! That's all they've achieved after DECADES fighting for the desktop of the computer users. DECADES, and they are only a few times times bigger than the Linux desktop!

Since their mobile craze, they aren't fighting for the desktop though. They simply don't care about it. macOS is utter trash in so many ways, especially for gaming. And I'd say despite the fact that it's so bad, they have higher than Linux market share. Because of marketing.

View this comment - View article - View full comments

Quoting: TheSHEEEPBasically, you code in the one way Rust wants you to, or you gtfo. Feels to 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".

That's exactly the selling point though. You might know, but that won't prevent you from making a mistake better than the compiler (type system combined with borrow checker) would. Human factor is the biggest cause of memory related errors in C and C++. So removing it is a huge benefit.

However, the trade off is a more restrictive way of how you can approach memory structures. Making something like linked list in Rust can be surprisingly complex in comparison with C or C++ as a consequence:

https://rust-unofficial.github.io/too-many-lists/ [External Link]

Rust designers understood, that there are cases when borrow checker is too restrictive, that's why there is unsafe option. In fact, standard Rust library itself is using unsafe when appropriate. The outward interface remains safe though. Unsafe is also needed when interacting with non Rust modules (such as C or C++) from within Rust.

See: https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html [External Link]

View this comment - View article - View full comments

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 [External Link]

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.

View this comment - View article - View full comments

Quoting: CreakJust 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.

Also, for some reason, the C++ standard has very weird statement. For instance, there is no standard over name mangling. The consequence is that each compiler has their own name mangler, which makes the binaries incompatible.

There is a solution to that... which is to go back to C mangling using this syntax:
extern "C"
{
    // Your C++ code.
}

For each problem, there is always "a way" to work around, but this is one example of how messed up C++ can be sometime, whereas simple C code doesn't have these problems.

That being said, the more it goes, the less I want to code in C or C++. My main reason why is the pre-processor. How come a modern language like C++ still needs another language (i.e. the pre-processor language) to work? For instance: #include...

Rust is a thing today. I'd take Rust over C++ and for sure over C. And you phrased it very well: "the more it goes, the less I want to code in C or C++". I have the same exact feeling, when there is a better designed language.

View this comment - View article - View full comments

Quoting: rkfg

Quoting: TheSHEEEPGood. Now merge DXVK with Wine.

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

And I find it a bad policy.

View this comment - View article - View full comments

Agreed. Linux beats Windows in user friendliness and productivity both. The myth that Windows is easier to use should be put to rest for good. Of course usability in part depends on DE and how it's configured (and whether it's using sane defaults). So it's not just about Linux, but about how particular distros set up defaults as well.

View this comment - View article - View full comments

Quoting: Liam DaweExactly. ACO affects AMD GPUs in a big way across basically all Linux games.

Also, not sure how much they are invested, but they seem to be quite busy with VR, and were working on the Linux side of things. VR is a niche technology now, due to high costs of the headsets, but still.

View this comment - View article - View full comments

Quoting: subWhen has been the last time you heard some enthusiastic plans
about Linux from Valve?

fsync and ACO are quite big efforts.

View this comment - View article - View full comments