Lots of regressions in games in last few versions

[Vitaliy Margolen]

Alexander Dorofeyev 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.

I understand that. However the person making a change should know which path 
is it. And have a hardware that can use this path. If not, then this patch 
should be tested by others with such hardware.

> 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 
We already have lots of people who using latest GIT. I'm talking about 
regressions that were introduced several versions ago and still not fixed.

> 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.
If developer can not tell if this is a hi risk or not, then such patch have 
to be marked as hi risk and should not be accepted while we are in the code 
freeze. Unless number of people test this patch on different hardware with 
different software and verify it's functionality.

We add more and more features to d3d which is wrong. This is exact point of 
code-freeze to accept low rusk fixes only.

Vitaliy