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

Yup, I would go the Rust way as well. I'd say that, as of today, the community knowledge and resources are not as good as for C and C++ (think stackoverflow and C/C++ libraries). But I truly hope Rust will continue to be more and more popular.

Off-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

View this comment - View article - View full comments

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

I see your point, though in this kind of projects, performance is an important priority. And, while it is easier to maintain object oriented code base, it is easier to make data oriented code in C than in C++ (since you never mix data and logic together).

That said, in the end I agree with you (like I said, I was just making the devil's advocate here). Most of the game engine are several millions lines of code long and performance in in the top priority, and, today, they are mostly written in object oriented C++.

View this comment - View article - View full comments

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.

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...

View this comment - View article - View full comments

Quoting: Liam Dawe

Quoting: Sir_DiealotIsn't DXVK that project that just went into maintenance mode because it's not feasible to develop it further?

No, that was other sites making a mountain out of a little GitHub comment rant. Don't read into it.

@Liam: Might be worth doing an article about it, I was like @Sir_Dialot, thinking DXVK was slowly dying in place of another project.. Although I have been reading mainly Linux news every day.

View this comment - View article - View full comments

Let's debunk a few myths here..

Vulkan is great, but it doesn't have the knowledge database of the other graphics APIs. That's probably the main reason why it's not wildly used. But it will come in time. Successes like Doom is a good advertisement for Vulkan.

C++ is faster because you have more control over the memory, and in game engine development, memory is everything.

That is exactly why DOTS (formerly known as ECS) is being worked on at Unity: it is a Data Oriented Tech Stack. When the data is properly layed out in memory, it can do wonders in terms of optimization.

And I tell you that as a game developer myself, who works at Ubisoft right now, and actually worked on DOTS at Unity.

View this comment - View article - View full comments

Quoting: Guest

Quoting: BrazilianGamerThe IL2CPP issue has been a big one. Nice to see we'll get rid of it

Would someone mind explaining what that is and why it's an issue?

It is a transpiler that takes the intermediate language (IL) from C# interpreter and convert it to C++ (CPP).

Then the C++ code is compiled to the targeted platform.

The result is a binary that runs faster than if using the .net framework.

Doc: https://docs.unity3d.com/Manual/IL2CPP.html

View this comment - View article - View full comments

@Liam Dawe How do you enable all these details?

View this comment - View article - View full comments

I didn't know about the loyalty discount. Where do you find that?

View this comment - View article - View full comments

Quoting: woox2kDoesn't seem all that different from first game. Probably worth to wait until it goes on sale.

I find there's quite a lot actually. More control over the train station constructions, possibility to have one train station with both cargo and passengers, ship cargo by plane, simulating noise problems with trains and trucks, ...

On the ui/graphics side, the graphics are better than the previous opus (which.. you would expect in a new iteration), there's the "level of gray" view that allows to have a way better view of specific features, like bus lines, etc.. (which has been taken from Cities Skyline, but a good feature nonetheless), the UI is far better and clearer than in the previous iteration, with issues addressed, at last, like cloning a train with one button.

You could argue that they could have made all this as an update of Transport Fever 1, but that would have been a hell of an update! and I'm pretty sure they need to eat too ;)

View this comment - View article - View full comments

Quoting: NeverthelessAnother solution is starting Steam with firejail --private=/another-directory steam, which then uses "another-directory" as home dir for Steam. Or you could use the Flatpak Steam install.

Is using flatpak Steam producing the same behavior as setting the HOME env variable?

It certainly limits the Steam app, but is it true as well for the games launched from it?

View this comment - View article - View full comments