D9VK is no more as it merges with DXVK, making DXVK a D3D 9/10/11 to Vulkan layer

Good. Now merge DXVK with Wine.

I hope they don't do this. I'm not a fan of redundant work too, but I think maintaining wine as generic as possible it's the best way to keep things working, while projects like proton can "fork" it to our specific needs (games above everything else in our case) without the risk to break something not related to it.

As long as both projects continue to help each other, this current approach is the best option in my opinion :)

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.

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


Last edited by Creak on 16 Dec 2019 at 2:10 pm UTC

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

Isn't GitHub the only channel the DXVK dev uses to communicate? In those little comment rants he clearly stated that after the merge of D9VK his project is going maintenance mode, because it's a "fragile, unreliable and frustrating maintenance nightmare". AFAIK he did not retract that anywhere. Do you know something we don't know or what?

No it's not, they have their own Discord. Don't take comments made out of frustration, as actual plans.

This situation reminds me that case with the devs of Linux mint back in april. I hope we can get a feedback direct from him about this case.

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

Ask and thou shall receive, just wanted to wait a bit for the right time to have the statement. See here.

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.

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.


Last edited by TheSHEEEP on 16 Dec 2019 at 2:38 pm UTC

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

Pretty ironic how this mountain of a code change just got merged into that same project.
Eh, what can you do? Fake news is one of the bigger problems in the modern day.

He did say he was going to include d9vk and some vulkan extensions before the maintance mode

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.

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

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

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

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.


Last edited by Shmerl on 16 Dec 2019 at 5:56 pm UTC

I, for one, welcome my new froggy overlord.

That's just... Remarkable. DX12 Vulkan implementation, we're waiting for you

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.

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

Good job, Joshua! <3

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

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.


Last edited by Shmerl on 16 Dec 2019 at 8:16 pm UTC

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

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.


Last edited by TheSHEEEP on 16 Dec 2019 at 8:48 pm UTC

Basically, 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/

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


Last edited by Shmerl on 17 Dec 2019 at 6:35 am UTC

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

DXVK 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 ;)


Last edited by TheSHEEEP on 18 Dec 2019 at 9:04 am UTC