Games/League Of Legends : DirectX9 error?

[Kreyren]

Once all verbs are installed I receive this error:

Originally posted by @Zemogiter in https://github.com/PhoenicisOrg/scripts/pull/797#issuecomment-454341965

[ImperatorS79]

Seems sufficient, but it still requires constant maintainance.. Woudn't limit it on debian stretch assuming that broken lib is fixed elsewhere.

Latest stable debian is used to build wine. Once the runtime is done, it does not change, unless debian is updated to a newer version.

It does considering that provided wine is broken in phoenicis repo which i think is likely considering that rolling are using newer versions that may depend on different libs.

What does this (which is related to the "runtime" point), have to do with:

i believe that we can't provide reliable binaries for wine on each system assuming different hardware configuration and methods that distros handle the drivers.

?

well depends.. lots of winehackers are patching lots of libraries and functions in wine for their testing and usecase which is impossible on phoenicis..

Well, I think "winehackers" are good enough in programmation to do their test without any help.

[Kreyren]

It does considering that provided wine is broken in phoenicis repo which i think is likely considering that rolling are using newer versions that may depend on different libs. What does this (which is related to the "runtime" point), have to do with: i believe that we can't provide reliable binaries for wine on each system assuming different hardware configuration and methods that distros handle the drivers.

Elaborate? i believe that i've explained that?

Well, I think "winehackers" are good enough in programmation to do their test without any help.

fair enough, but i would still include such feature for reasons above.. Usefull for testing and working around phoenicis wine bugs.

[Kreyren]

btw. recommends voice for conversations alike.. its pita to resolve in chat

[qparis]

@Kreyren A lot of shortcuts and misconprehension of what is at stake here. I'll try to put it in a nutshell but:

• Of course it is easy to execute wine once it is built (as you've done with your "POC"). But you cannot claim that you'll solve all of our problems with a 20 line bash script.
• You seem to believe that our goal is to run scripts that are able to install games. We are well aware that it is simple task for a given configuration (like your particular computer running on Gentoo). What is not easy is to make the script work for a large amount of configuration and distributions.
• Phoenicis's goal is to be easy for unexperienced people, not over-optimized. You tend to forget that hardly anybody is capable of building wine correctly with the correct dependencies.
• Also, it seems that you are underestimating the amount of different configuration across different distributions and the amount of bug report we receive for each possible combination
• Phoencis does not "simply" run "wine program.exe". It it was the case, we would not need to write these thousands lines of codes. We also need tools like wineserver, regedit, regsvr32, ... that are not always available in the path.
• The larger the number of script we have, the more effort we need to give to maintain them. Just imagine if all distro fanboys wanted to have its own optimized script for all these games. Currently, we only one script per game in POLv4 and we are not able to keep them maintened yet. You tend to underestimate the time it would require.
• I really doubt that there is a perceptible difference between a wine binary compiled for your CPU and a "generic" one

So no, this is not where we want to go. We prefer to have one script that works in any case that having 100 scripts. Fragmentation is hell.

[plata]

To come back to the original topic: Will this issue be solved if the required dependencies are available as part of the wine package? If so, we should close this and open a new issue in winebuild to collect the required dependencies (at least to the best of our knowledge so far).

[Kreyren]

What is not easy is to make the script work for a large amount of configuration and distributions.

I'm aware of that, but as i said such solution should fix the issue for rolling distro's usecase and allow users to use system wine in case phoenicis wine is not working -> Instead of fatal error..

Phoenicis's goal is to be easy for unexperienced people, not over-optimized. You tend to forget that hardly anybody is capable of building wine correctly with the correct dependencies.

Why can't it be both? Considering that you need experienced users to build scripts and assuming that current implementation seems easy to implement?

Also, it seems that you are underestimating the amount of different configuration across different distributions and the amount of bug report we receive for each possible combination

That's why am i suggesting system wine.. In theory allowing contributors to upload their precompile wine would also be sane assuming that proper checks for malware and code quality are issued.

Phoencis does not "simply" run "wine program.exe". It it was the case, we would not need to write these thousands lines of codes. We also need tools like wineserver, regedit, regsvr32, ... that are not always available in the path.

Yes that is solution for precompiled.. I see no reason to not expand it's functionality further using system wine.

The larger the number of script we have, the more effort we need to give to maintain them. Just imagine if all distro fanboys wanted to have its own optimized script for all these games. Currently, we only one script per game in POLv4 and we are not able to keep them maintened yet. You tend to underestimate the time it would require.

Assuming that i finish the documentation and my suggestions for infrastracture are approved phoenicis should never write any script.. We should only provide a platform for those people to build their own scripts for their chosed distro, kernel etc.. Which would allow us maintaining all scripts for minimal maintainance. Personally if good frontend and backend is provided i can contribute +- 100 scripts and maintain them + educate more people to do the same thing.

I really doubt that there is a perceptible difference between a wine binary compiled for your CPU and a "generic" one

Depends on the configuration there might be or there is not. Note that if there is a function that would offer performance improvement beyond reasonable doubt i'm going to spend a month if needed to research it and adapt it.. such improvement are very important for this usecase.

In theory you can make some small package manager to compile wine based on parsed instructions that are aquired from system's resourced for hardware that is present on the system. Afaik it's 95.1% C so in theory providing a method to compile compiler or precompiled compiler would be sufficient usually it needs to invoke distro's package manager -> provides optimized WINE for minimal maintainance.

Note that end-user woudn't care for such configuration assuming that scrips are provided by the script maintainers.

[qparis]

Ok as @plata said, this is not the right place to discuss about this.

What you are describing is just not as magick and simple as you tend to describe it. You are really underestimating the differences between the distributions and the amount of bug report we are going to receive.

[plata]

I would even say: The suggestions are completely contrary to what we try to do with Phoenicis. So while there maybe might be a use case for your proposals, it is certainly not what we want to achieve here.

[Kreyren]

it is certainly not what we want to achieve here.

Assuming that you want to achieve using precompiled wine i would suggest:

---

Allow contributors upload their precompiled wine.

This could be introduced using instructions in documentation and using different source for repository if not welcomed in upstream.

Should allow alternative way to fix issues with WINE in phoenicis if any + custom configuration of wine that would be insane to introduce in phoenicis alike cherrypicking components from proton combining them with components from master WINE and custom patches that works for specific system and app.. (yes people are doing things alike)

---

Introduce a database with libs which components can be used on demand.

Should fix issues with dlls, but requires maintainance since libs are getting updated all the time which results in multiple issues.. -> In theory difficult maintainance

in theory we can grep output from WINEDEBUG="+dll" and define it in a way that is user friendly to output error with instructions how to get required dependency? alike Error: your system is unable to use vulkan, invoke apt-get vulkan to fix this issue. -> it would require phoenicis to avoid all fatal errors while it's installing alike if phoenicis is missing dependency it will pause and allow end-user to resume once resolved instead of fatal that leaves broken wineprefix behind..

In theory if uname -r == ubuntu -> ask end-user if he/she wants to invoke apt to install vulkan.. In thoery grab those error messages from separate folder in github -> allow contribution for parsed errors with the ability to parse commands/bash script?

---

Became a game developer and modify game source with WINE and redistribute it like Aspyr is doing with borderlands

disclaimer: suggesting it for brainstorming.

Figure out a way to handle lincencing and work with game source to provide wine within the game itself.

In theory some FOSS way to work around it so that game developers would provide required info to make a compatibility? Like OverWatch/Riot Games is doing on community request?

[Kreyren]

Any ETA?

[plata]

We have a separate issue for this in the winebuild repo.

[Kreyren]

@plata reference it please.

[plata]

https://github.com/PhoenicisOrg/phoenicis-winebuild/issues/62

[plata]

Remaining stuff should be discussed in #797.