No announcement yet.

Wine-Staging 3.8 Gets Fixes For Star Citizen, Direct3D 11

  • Filter
  • Time
  • Show
Clear All
new posts

  • Wine-Staging 3.8 Gets Fixes For Star Citizen, Direct3D 11

    Phoronix: Wine-Staging 3.8 Gets Fixes For Star Citizen, Direct3D 11

    For those looking to enjoy Windows-only games on Linux this weekend, Wine-Staging 3.8 has been released as the newest experimental build of Wine...

  • #2
    Originally posted by debianxfce View Post
    I hope they would fix the Watch Dogs game black rendering problem. The game works otherwise fine but gaming is difficult when you see black areas only. A bug report has been made a long time ago.
    Try using DXVK, it may just work.


    • #3
      Wine-Staging 3.8 Gets Fixes For Star Citizen, Direct3D 11
      Nope, Don't work . Like most things with wine.


      • #4
        There is a video on youtube titled "making of star citizen:mutlti region server architecture explained" the deveops engineer Ahmed Shaker is wearing a tux shirt. They use aws linux servers. Amazon dropped support for Linux and are working on mac support... Wasn't Star Citizen suppose to go Vulkan only?


        • #5
          RSI have pulled all engine development in-house. They're basically just using Amazon for the server side.


          • #6
            Yes, the Star Citizen developers did say that they are looking into Vulkan. If I recall correctly they ruled out DX-12.

            But in a display of sanity they are putting that off until they have the game done. I suppose they might have an engine developer working on it in the background and it will just pop out when ready. I think that they have more important things to do with networking changes at the moment. They have to adapt a 16 player engine to support thousands.


            • #7
              Originally posted by debianxfce View Post
              I hope they would fix the Watch Dogs game black rendering problem. The game works otherwise fine but gaming is difficult when you see black areas only. A bug report has been made a long time ago.

              That not a bug report debianxfce. That a test report. So the bug has never been properly reported. There is no associated bug. This is a on going problem developers do not read test reports unless there is a open bug. Test reports are for end users more than developers.

              Reality here is there has never been a bug report over that black areas problem so of course no developer has ever worked on it. So if it got fixed would be pure luck.

              By the bug reports the only thing wrong with that program is uplay issue that can be bipass. It has not been even connected to a generic uplay bug.


              • #8
                Originally posted by debianxfce View Post

                No because wine developers do not read or care bug reports.


                Story videos works and 5 minutes gaming but too much black areas in rendering. "
                Why does the bug you just quote have no application associated thinking it was posted many months ago. Any bug with zero application associate by appdb go right to the back que. Its something I point out in IRC a lot that when creating a bug in wine bugzilla at least associate the application from the appdb as this is important so bug has a chance of being looked at.

                Reality is there is a priority system on wine project bugs. The wine project limited resources and these have to be optimised. Do the wrong process expect your bug ignored.

                More applications validly associated with a bug more likely a developer will look at it. Having a zero application associated with bug means the bug will most likely be duplicated by someone who has more interest in reporting properly at some point in the future so is perfectly valid to totally ignore those bugs.

                Also if you look at the quote bug it only has two posts on the same day. So are developers meant to be mind readers? Yes another thing that increases odds that developers will look at a bug is activity. Even simple posts saying fault still existing in wine version x that is newer than the bugs report version. Developers don't want to waste time and sometime paying for programs only to find out that the bug was fixed in a newer version of wine and the person reporting bug failed to report that.

                Really due to the lack of activity on the bug and lack of application association its on the path to be closed by triage.

                Also with no association with the application a person using nvidia who looked at the appdb would not know about the bug you posted and be able to post if they are effected or not.

                Reality here debianxfce other people are getting their bugs look at by developers and have developers fix them. They are doing things differently to you and those differences are important so your bug don't go into the junk pile. Lets not blame the wine developers for the failure of your reporting.

                debianxfce you bug required the developers to be a mind reader and has not been updated and was not where end users could find it. So please explain why that should not go into the trash pile thinking the wine project has a huge number of bugs to address. If you do not want it in the trash pile fix it.


                • #9
                  Originally posted by debianxfce View Post

                  With the time you use your long posts you could play Watch Dogs and see areas rendered with black. I did update my bug report.
                  You don't have a clue how fast I type. The past post was only 3 min of my time.
                  Notice I pointed to this before. Its still zero of course this could be the link as not been approved yet. But if it that you have not requested the link do the following.

                  While logged into the appdb return to the following page.
                  Notice the "Submit bug link"under knowing bugs put the bug number "43981" before it and push button.
                  There is Watch Dogs more than 1 version.
                  Yes Watch Dogs 2 is also on uplay and it does not have a entry yet.

                  Please note there is no point for me to fix these errors for you. Because if you don't learn how to do reports right you will end up being always stuck on the junk pile. If a developer is not quite sure what version the bug is referring to they click on linked applications if nothing is there they move on to the next bug report. That link means other suffering from the problem may see it when they visit the appdb and provide other information so increasing bug activity.

                  Wine project has a few thousand bug reports in need of processing so small errors in reporting equal totally ignored. I like how you say in the time I did the post I could have played the game and seen the faults.

                  Due to it not being linked properly in the time you most likely think it takes me to type the posts the developer has given up on the bug report because the application effected is not clear because the bug was not linked to the application.

                  Appdb linking is a special feature wine project added bugzilla due to how often it would happen that developer would open bug and not be sure of what application it really was and waste time testing the wrong application and wonder why they could not repeat the fault.


                  • #10
                    Originally posted by debianxfce View Post
                    I am a pro software developer (Msc). You can not even read or see winehq appdb or bugzilla reports of the black rendering bug. In winehq appdb is a picture ( the black rendering bug and several users report the same problem.
                    Sorry don't accuse me of not reading something. I have.

                    Lets get to the final problem. When you test with wine staging you have about 3 developers vs when you test wine development or stable 50+ to look at bug. So of the program does not work with wine development/stable branch those bugs need to have same kinds of things where people are reporting that mainline stable and development don't work. If you look at the uplay bug on that program were is the latest activity.

                    Yes have read you bug reports and I can tell you why they are being ignored. The final post on the uplay bug says it can be worked around is that still the case.

                    Not test reports with development branch must mean you are waiting on the 3 staging developers to fix the fault. Also a lot of uplay affected programs are not linked to the uplay bugs and not having regular testing and bug activity to show they still have problem.

                    Several users have report problem to what group of developers that is a question you never asked.

                    Come on debianxfce someone reporting bugs against a proto type version maintained by 1-5 developers is not going to have a fast response even in a professional field. Now it be something as big and complex as wine 3 developers don't stand a chance of keeping up ever.

                    Reality I have a hard time believing you are a professional developer because all of the above should have been common sense to a professional developer who uses open source with the different branches open source project have. Yes its always important to check what branch you are using if it has enough developers or you bugs will go on deaf ears this is not unique to wine.