Lots of regressions in games in last few versions

[Zachary Goldberg]

On Sun, May 11, 2008 at 10:58 AM, Alexander Dorofeyev <alexd4 at inbox.lv> wrote:
> Vitaliy Margolen wrote:
>> James McKenzie wrote:
>>> Vitaliy Margolen wrote:
>>>> Several latest releases introduced lots and lots of regressions to a
>>>> point that no games run as-is. Considering that we are at the code
>>>> freeze, I'd like to see all patches that cause regressions, and all
>>>> patches that depend on them starting from wine-0.9.58 be reverted.
>>>>
>>>> Also each patch to have a conformance test and statement which games
>>>> where tested and what problems were fixed with each patch.
>>>>
>>>> Bugs: 13120, 13110, 13101, 13086 and on and on and on.
>>>>
>>>> Can some one explain what's the deal with games not working full
>>>> screen? Why are there are of the sudden problems with pixel formats?
>>>> Why lots of games crashing ActivatingContext? Why most games don't
>>>> work anymore on ATI?
>>>>
>>>>
>>
>> I'd like to trust all developers to make right decisions about what patches
>> are low risk and which have to be tested with loads of apps. But it seems I
>> can't. And no one saying what might break if some patch gets committed. And
>> of course I understand that most things can't be tested with conformance
>> tests there. But at least a minimum of several major titles have to be
>> tested for regressions.
>>
>>
>> Vitaliy.
>
> Vitaliy,
>
> I mostly use wine for games, and I agree with you that regressions with games
> regularly appear (not that it's so different from any other area whenever
> there's active development) and it sucks. To some extent, tests may help, but,
> unfortunately, even with tests things are still rather fragile. One reason is
> many different codepaths and variables that affect how wined3d works. To give an
> example, with an old game like Starcraft, you would have this:
>
> 1) DirectDrawRenderer: gdi or opengl
>
> if opengl, then
>
> 2) EXT_paletted_texture offered by driver or not
> 3) ARB_fragment_program offered or not
> 4) PBO available or not
> 5) various RenderTargetLockMode settings
> 6) various OffscreenRenderingMode settings
>
> Running tests on one machine may miss many breakages because of so many
> variables. On top of that, add the hazard of buggy and broken drivers.
>
> If we want to guarantee no regressions in major game titles, we must have a list
> of these titles and probably also volunteers who care about games to regularly
> test them with current git on different types of hardware and preferably also
> playing with the above mentioned settings while doing so. There is so much to
> test with these things a single person can't handle it, unless he has several
> computers with all kinds of popular hardware and many hours a day for this (and
> also many games, which nowadays tend to take gigabytes even for a demo).
> Basically this means making some titles part of either official or at least
> unofficial / "voluntary" release criteria. You are welcome to propose ideas
> about possible list of such titles. Regularly running conformance tests on
> specific hardware is also good, but in this case testers must be aware of known
> issues - failing tests sometimes mean known bugs in drivers, whereas if a game
> worked in the past but regressed it's definitely a wine problem.
>
> As for low risk, it's unfortunately difficult to assess, as, for example, it
> often happens that a relatively obvious, simple and correct fix breaks things
> because it exposes previously hidden bugs.
>
> Just my 0.02 € :).
>
>
>


I think most of the participants in this thread thus far recognize the
complexity of Wine and the difficulty of the task at hand.  I do
believe however, that Vitaliy's original arguement still stands.  Are
we working to make Wine 1.0 be the best at running applications that
Wine has ever been?  If so then reverting recent patches which break
things is a good idea.  If we're _only_ concerned about those 4 listed
applications and those still work and the status of other regressions
isn't as important then we continue and leave in the regressions.

So it comes down to: Ship with known regressions, or ship with as few
regressions as possible, even if it means reverting patches which may
fix some things but break others.

I think for the sake of 1.0 we _should_ revert known breakages, and
reapply them after 1.0 and attempt to properly fix them.  I'd love to
see a Wine 1.0 that is, as Linus calls them, one of those 'magical
releases' that just works and has almost no regressions.

-Zach