Announcement

Collapse
No announcement yet.

Lutris Updated With D3D12 DLL Provided By VKD3D-Proton

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • pal666
    replied
    Originally posted by Auzy View Post
    Got a link explaining why they didn't accept it? It's probably not the right way of doing things long term..
    they didn't accept it because their (paying)target audience is macos users who have no vulkan. long term opengl is dead. basically, you live in some inverted reality

    Leave a comment:


  • pal666
    replied
    Originally posted by Auzy View Post
    C++ / OOP doesn't magically make things better. In fact, bad OOP code is WORSE than C code, and you increase the barrier to entry..
    in fact c++ is not an object oriented language and there's plenty of oop code written in c, including in linux kernel which you used as example.
    Originally posted by Auzy View Post
    You also increase the bugs
    it's a lie, it reduces the bugs
    Originally posted by Auzy View Post
    , and if you run both C++/C, you just introduce a whole bunch of new issues..
    most c++ programs contain pieces of c code, c++ was explicitly designed for it, again nothing but lies from you.
    Originally posted by Auzy View Post
    GREAT! Yes, just rewrite 27 years of code so it can be OOP for no reason, and to reduce the number of developers who can assist..
    i've already pointed out your confusion of c++ with oop. now you are suggesting rewrite. did dxvk rewrite 27 years of code?
    Originally posted by Auzy View Post
    Linus Torvalds (who wrote Linux from scratch), also doesn't use C++.
    another lie. linus torvalds has ported his program subsurface from c and gtk to c++ and qt many years ago
    Originally posted by Auzy View Post
    Linux Kernel uses C90 apparently.. So, you better tell Linus he's wrong too
    linus had no choice, when he started linux there were no c++. but what fucking relation does linux have with wine? wine isn't os kernel, it's user application which is easy to switch to c++. why you don't compare wine with gcc, which switched from k&r to c++? gcc was even older than linux and wine. why you don't compare wine with gdb which switched to c++11? why you don't compare wine with every major compiler, browser or office suite? because you found some stupid uneducated linus quote from several decades ago?
    and btw, the language used by kernel isn't c90. it's called "sparse" https://sparse.docs.kernel.org/en/latest/ (because, you know, c90 sucks)
    Originally posted by Auzy View Post
    And you don't think it's a good idea to be able to test the codebase using a reference compiler?
    what makes you think microsoft c from nineties is a reference compiler for dx12?
    Originally posted by Auzy View Post
    What do you expect to gain by using a new version?
    more productive environment. just compare success of dxvk to wine counterpart
    Last edited by pal666; 19 July 2020, 08:22 AM.

    Leave a comment:


  • mos87
    replied
    gotta love this type of software... lutris, play.it, playonlinux.. Still vividly remember when in the noughties CD|DVD burning was in its heyday and 99% topics on various Linux-related forums were stupid questions from people trying to use the so-called user-friendly frontends to the free burning tools, mostly K3B coming from the latter unable to find the actual utility to burn (cdrecord/wodim/etc) and/or from asking the "feature-rich and omnipresent" K3B to do what it never could (like master a DVD-video or convert some stupid proprietary image format to something usable... was even funnier when the given .nero or whatever was just a renamed iso)
    Endless pages of entropy and blind leading the blind were generated. And this only got worse since then))
    Last edited by mos87; 19 July 2020, 07:55 AM.

    Leave a comment:


  • pal666
    replied
    Originally posted by Aryma View Post
    they don't won't C++ in wine code for unknown reasons
    the reason is they don't know c++
    Originally posted by Aryma View Post
    if I decided to do something about this mess I will rewrite wine from scratch with rust or something
    but since rust rewriters are busy writing forum posts, someone else has to write software in real language

    Leave a comment:


  • JoshuaAshton
    replied
    > C++ / OOP doesn't magically make things better. In fact, bad OOP code is WORSE than C code, and you increase the barrier to entry.. You also increase the bugs, and if you run both C++/C, you just introduce a whole bunch of new issues.. GREAT! Yes, just rewrite 27 years of code so it can be OOP for no reason, and to reduce the number of developers who can assist..

    I like C++ when implementing C++ APIs. :^)

    Personally I am not a fan of Wine's C-style as it lends itself to be unsafe and easy to shoot yourself in the foot with uninitialized/old memory.
    I wish they would at least embrace inline declaration + assignment, designated initialization and compound initializers.
    It's 2020, there is no reason not to in my opinion. It just makes things way more annoying.

    > What do you expect to gain by using a new version?

    I expect to be able to write readable and safe code without seeing 0xcccccccc in my debugger.
    Dealing with the Wine coding style + Vulkan pNext chains hurts my brain, I usually just end up writing it my own, sane way, and then butchering it after.

    > Linux Kernel uses C90 apparently.. So, you better tell Linus he's wrong too (these days, he is a lot more passive, so he won't totally destroy you). Updating standards for the sake of doing so with marginal benefit, is silly.

    The Linux kernel uses whatever it wants to with a million and one GNU extensions.

    Leave a comment:


  • Auzy
    replied
    Originally posted by Aryma View Post
    they didn't accept Vulkan backend in the first until see doitsujin dxvk dev succeeded and win valve support
    Got a link explaining why they didn't accept it? It's probably not the right way of doing things long term..

    Just FYI, Linus rejects patches all the time. Just because it fixes one use case, doesn't mean it's the best solution for all.. Sometimes as a leader, you have to make decisions people don't like.. Otherwise we'd still be using DevFS instead of uDev for 20 years with no maintainer.

    Originally posted by Aryma View Post
    they don't won't C++ in wine code for unknown reasons
    The reason's are unknown to you only..

    C++ / OOP doesn't magically make things better. In fact, bad OOP code is WORSE than C code, and you increase the barrier to entry.. You also increase the bugs, and if you run both C++/C, you just introduce a whole bunch of new issues.. GREAT! Yes, just rewrite 27 years of code so it can be OOP for no reason, and to reduce the number of developers who can assist..

    Linus Torvalds (who wrote Linux from scratch), also doesn't use C++. But hey, maybe try explaining to the Linux kernel team why he's mismanaging one of the most popular OS's on the planet.

    Refer to https://www.reddit.com/r/programming..._written_in_c/

    Originally posted by Aryma View Post
    they only support C89 to support Microsoft Visual C compiler ????
    Linux Kernel uses C90 apparently.. So, you better tell Linus he's wrong too (these days, he is a lot more passive, so he won't totally destroy you). Updating standards for the sake of doing so with marginal benefit, is silly.

    And you don't think it's a good idea to be able to test the codebase using a reference compiler? There's a lot in development languages that are ambiguous, and there is a lot of bugs in compilers. So, the benefits could potentially be to identify these ambiguitities between the two, so they can replicate them. Some apps rely on these small bugs to operate correctly.

    What do you expect to gain by using a new version?

    Originally posted by Aryma View Post
    It's a cleary they don't understand how "Clean room" design work
    https://wiki.winehq.org/Clean_Room_Guidelines That list seems fairly accurate to me. What part of it suggests they don't understand?

    Originally posted by Aryma View Post
    if I decided to do something about this mess I will rewrite wine from scratch with rust or something
    WOW, GREAT IDEA!!! Good luck with that.

    You do realise that Wine has a 27 years head start in development, and almost any developer programs in C, whereas barely any have experience with Rust (a 6 year old programming language, which many developers aren't even writing their code purely in yet, because it's not ready). Furthermore, parts of Windows (like copy protection) might even rely on unsafe memory operations. This is possibly the dumbest thing I've heard someone say for a while (thinking it's an easy task).

    I ported plenty of my projects to other languages because I thought it was better (Driver On Demand was written in Perl, and I ported it to D, because I thought it was a better language). Huge mistake.. I wasted time doing the rewrite, and it introduced huge new bugs (including one I couldn't fix at the time, but years later I spoke to Walter Bright randomly on reddit, and he finally recognised the problem with the bug, and fixed it, so huge kudos to him ).

    THEY LITERALLY are at the point that most apps run now with minor help. They reverse engineered most of the Windows API.. Yet, sure, they should definitely take your advice.

    I also love the fact that you're comparing them to the most successful Linux desktop at the moment, which also has the most usability (which is why Ubuntu uses it)... Given the success of these projects, are you sure that perhaps YOU'RE not the worst decision maker?
    Last edited by Auzy; 19 July 2020, 06:10 AM.

    Leave a comment:


  • Mez'
    replied
    I love the effort Wine devs are doing, and I needed it years ago (I even paid for Crossover 6-7), but I've been on Linux for so long that I've transitioned everything I needed to Linux native apps.
    The same goes with Steam, it has enough Linux native/ported games supported for me to be happy and reward game editors that go the extra mile and make the games available on Linux. Which is why I haven't installed Wine in 5 years and I will certainly not play on Proton (and reward "lazy" editors, or editors not deeming Linux as a viable financial option).

    I can see the use case though, if you have friends that play some specific games, it's not cool to be left out. It's nice to see progress is still made to satisfy these use cases.

    Leave a comment:


  • Aryma
    replied
    Originally posted by Auzy View Post

    Made any Wine donations lately? Paid for CX Office? It comes down to money. Crossover is focusing primarily on making App's, installers and Windows API operate.. Transgaming already showed in the past with WineX its not profitable for standalone developers to focus on Wine Gaming.
    what the F are you talking about wine/Crossover team have one of worst decision making after the gnome team

    Originally posted by Auzy View Post

    Either shut up and eat, and thank them, pay for the cake, or help in the kitchen baking it.
    .
    they didn't accept Vulkan backend in the first until see doitsujin dxvk dev succeeded and win valve support
    they don't won't C++ in wine code for unknown reasons
    It's a cleary they don't understand how "Clean room" design work
    they only support C89 to support Microsoft Visual C compiler ????

    if I decided to do something about this mess I will rewrite wine from scratch with rust or something






    Leave a comment:


  • Auzy
    replied
    Originally posted by shmerl View Post

    That doesn't answer the question in any way. I'll repeat it - why is the fork needed? Try answering it, instead of trolling. To give you a hint, forks usually happen, if upstream can't accept changes for whatever reason. If you know the reason feel free to explain, instead of coming up with cake analogies.
    Trolling? Sounds to me like you need a dictionary instead of an explanation.. Just because someone doesn't respond in the way you want, doesn't make them a troll, and your comment came across as an attack against Crossover..

    Here's a "hint", no, that's not the usual reason for forks..

    Think of them like 2 different branches, where one is a gaming branch, and one is an application branch. For gaming optimisation for instance, you want to make heavy use of Vulkan (possibly at the expense of breaking apps on less powerful machines) and you possibly want performance features like shared memory (which increases performance, but decreases security, makes debugging harder and decreases stability). Steam also wants a product which is guaranteed to integrate well with their gaming store (and likely has Steam specific modifications to do so). Wine is designed for totally independent apps, such as Office installers, and needs to be careful with that they redistribute.

    Crossover doesn't want to provide paid support for Steam games either, and Steam probably doesn't want to have to support apps like Microsoft Office purchased outside of their store.

    Both projects are moving incredibly quickly, and to work as one project, they'd need a lot of communication and planning between the teams (slowing both projects down). Look at how slowly working with the Linux kernel is at times (Bus1 for instance years later is still working on getting merged). Even the Linux kernel has branches to accommodate different use-case scenarios.

    It comes down to quality control and requirements for what they are doing. Branching large projects like this is fairly normal. It sounds like you're inferring that Crossover Office is mismanaging the project based on minimal evidence..
    Last edited by Auzy; 19 July 2020, 02:31 AM.

    Leave a comment:


  • smitty3268
    replied
    Originally posted by shmerl View Post
    How is that Wine project can't handle the focus on performance and games compatibility, that it requires a fork to do it?
    In general, the Valve forks are done so that Valve can get the games on their platform up and running as soon as possible.

    That often implies things like game specific hacks that the upstream WINE project won't accept, because they want a full solution to the problem rather than the quickest minimal fix that some game requires.

    Why? Because partial fixes often end up regressing other applications - something that's not a big deal for Proton since it only has a limited number of games to support, but which is a bigger issue for WINE if it wants to support every Windows application. It can also cause maintenance issues over the long run.

    The good news is that the two projects are talking with each other. If the Valve fork figures out how to make a game work, someone is likely looking at how that can then be merged back upstream to WINE.

    Leave a comment:

Working...
X