https://bugs.winehq.org/show_bug.cgi?id=53453
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEEDINFO Ever confirmed|0 |1
--- Comment #6 from Olivier F. R. Dierick o.dierick@piezo-forte.be ---
Hello,
(In reply to Anonymous from comment #5)
https://wiki.winehq.org/Regression_Testing doesn´t provide cross-platform regression testing code. (For example, it doesn't work unmodified on Guix.)
So, if I want to run a regression test, I'd first have to port this collection of commands into infrastructure suitable for running regression tests. The right way to do this is to have a single program that works across all supported operating systems in order not to exclude some users. Picking favorites w.r.t. distributions discourages innovation.
If you guys wants to export regression testing to users, you should even hide the fact it uses git. All that should be required is some primitive that exports checking for the color of a particular pixel after a particular amount of time and all a user would have to say is for example "a pixel at coordinates (100,100) changes color five times in a row in a repeating pattern" for an OK-test. Literally, every single issue I have had with wine w.r.t. games could have been tested by that. In fact, it should be possible to have the build system ask users with a particular interest in some applications with a particular system configuration to check such a basic property automatically during idle CPU time.
Even Bugzilla could be used for users to automatically send such outputs. If you want people to contribute, you should make it easy to do so. The amount of feedback you would get in that way would dwarf the information obtained from the select few developers that might happen to still play some old game.
I don't understand what you are talking about.
Regression testing is not an application, it's a method for finding the cause of an issue when it results from a change in the code. It's not meant to be done by average users and it can't be made universal as the regressions are unpredictable.
It consists of iterating through the commits (individual changes in the code) between a known working version and a non-working version until the first commit that causes the issue is found. You have to compile Wine at each step and then test the application with the intermediate build.
The instructions given are an example. They use git because that's what the project uses for its own builds and it has an easy to use bisect function that facilitate the regression test by using a dichotomic algorithm.
You have to adapt the instructions to your own building environment and requirements.
I do have 32-bit OpenGL support, but just not for the right set of system components against which 6.01 is compiled (the same binary works fine with an older system configuration). I am not currently using something like https://github.com/guibou/nixGL, which might be the quick fix solution in my case.
Newer versions of wine don't complain about OpenGL(because it's compiled against compatible system components), but they just never show a splash screen.
If you use a pre-build Wine package then it's normal. Wine 6.0.1 packages are now old and were built against old dependencies so when you use it, it tries to load old libraries that are just not there.
That's why the regression test requires building Wine on the current system, so Wine loads libraries that are current installed.
It would be of interest if *anyone* running this game can run it with any wine version >= 7. I do not believe such people exist. The probability that the demo doesn't work is also extremely high, if it uses the same initialization procedure for that splash screen.
I just tested the demo on Wine 7.13 and it works out-of-the-box, so we need more info on what is happening on your system and the first thing you can do is provide the log that I asked earlier.
Regards.