Announcement

Collapse
No announcement yet.

VKD3D 1.5 Lands In Wine For Updated Direct3D 12 Over Vulkan

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

  • arQon
    replied
    Originally posted by Awesomeness View Post
    Given the backwards facing rhetoric of upstream Wine developers – somewhat recent (2020?) statements such as saying there is no need to support Wayland because X11 is better anyway for supporting systray – I have the strong suspicion that working with Wine developers are just a chore to work with.
    Or, you could not voice an insulting opinion about people you know absolutely nothing about; and accept the reality that Wayland is a non-functional unstable dumpster fire, which is not exactly a desirable thing to introduce to a project that already has one of those to deal with.
    But, you do you.

    Leave a comment:


  • mulenmar
    replied
    Originally posted by JPFSanders View Post

    some changes to Wine that seem "obvious" in the surface cause other problems moving Wine forward.
    This is a giant red flag that a software project was not designed and maintained properly -- modularity is vital for large projects, specifically so that new technologies can be adapted to with minimal fuss.

    If Wine can't adapt because it would break things, they need to step back and do some rework.

    But yeah Wayland needs to fix its own shit already too, so Wine has a proper target to work with in the first place.

    Leave a comment:


  • JPFSanders
    replied
    Originally posted by Awesomeness View Post
    Your claim makes no sense because the question wasn't about Win32 support in Proton but the Proton fork of vkd3d, so a technology aimed at games.

    Given the backwards facing rhetoric of upstream Wine developers – somewhat recent (2020?) statements such as saying there is no need to support Wayland because X11 is better anyway for supporting systray – I have the strong suspicion that working with Wine developers are just a chore to work with.
    I strongly disagree, In my personal experience the Wine developers have always been helpful, what is not understood by many is that some changes to Wine that seem "obvious" in the surface cause other problems moving Wine forward.

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by Awesomeness View Post
    Your claim makes no sense because the question wasn't about Win32 support in Proton but the Proton fork of vkd3d, so a technology aimed at games.

    Given the backwards facing rhetoric of upstream Wine developers – somewhat recent (2020?) statements such as saying there is no need to support Wayland because X11 is better anyway for supporting systray – I have the strong suspicion that working with Wine developers are just a chore to work with.
    well considering that we have yet to have a somewhat decent cross platform dock or even a good virtual keyboard that works across compositors, I would have to agree with them, everything uses some kind of compositor specific crap, wlr-layers, or whatever KDE or gnome have. Wayland is a fucking mess lol, I would agree with their stance on this one

    Leave a comment:


  • Awesomeness
    replied
    Originally posted by JPFSanders View Post
    They serve different use cases, proton doesn't care about obscure Windows applications that require exotic functionality/integration with other Win APIs and that can get in the way of gaming performance.
    Your claim makes no sense because the question wasn't about Win32 support in Proton but the Proton fork of vkd3d, so a technology aimed at games.

    Given the backwards facing rhetoric of upstream Wine developers – somewhat recent (2020?) statements such as saying there is no need to support Wayland because X11 is better anyway for supporting systray – I have the strong suspicion that working with Wine developers are just a chore to work with.

    Leave a comment:


  • Linuxxx
    replied
    Originally posted by brent View Post

    It still doesn't make much sense. If we assume that CodeWeavers mostly cares about macOS support, a direct Metal to D3D12 wrapper would be easier to develop and deploy and it would have lower overhead as well.
    Looks like the few remaining Linux customers still justify the effort of only writing a D3D12-to-Vulkan wrapper and then using MoltenVK to translate Vulkan-to-Metal on macOS.

    Plus it's Apple users we are talking about here:
    They are simply used to miserable gaming performance!

    Leave a comment:


  • brent
    replied
    Originally posted by Linuxxx View Post

    Because it's developed for CodeWeaver's CrossOver product, which is mainly bought by macOS users.

    And since VKD3D-Proton rightfully doesn't care about Apple's own Metal API, CodeWeavers is forced to develop their own solution, a.k.a. plain VKD3D.
    It still doesn't make much sense. If we assume that CodeWeavers mostly cares about macOS support, a direct Metal to D3D12 wrapper would be easier to develop and deploy and it would have lower overhead as well.

    Leave a comment:


  • Linuxxx
    replied
    Originally posted by brent View Post
    Why does this even exist? vkd3d-proton is so far ahead it's not even funny.
    Because it's developed for CodeWeaver's CrossOver product, which is mainly bought by macOS users.

    And since VKD3D-Proton rightfully doesn't care about Apple's own Metal API, CodeWeavers is forced to develop their own solution, a.k.a. plain VKD3D.

    Leave a comment:


  • JPFSanders
    replied
    Originally posted by brent View Post
    Why does this even exist? vkd3d-proton is so far ahead it's not even funny.
    They serve different use cases, proton doesn't care about obscure Windows applications that require exotic functionality/integration with other Win APIs and that can get in the way of gaming performance.

    Wine cares about those applications.

    Both are open source and code is moved back and forth between them every now and then. They don't exist on separate vacuums.

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by user1 View Post
    Is vkd3d-proton a hard fork of vkd3d, or do they still take some stuff from upstream?
    as far as I can tell, vkd3d will occasionally pick things up from proton, and Hans has a few commits in vkd3d, but they are mostly entirely seperate outside of a few crossovers.

    Leave a comment:

Working...
X