Fourth release candidate of Wine 1.8 is out

In this wine version appears corrected some bugs, at simple seek very similar to rc3

View video on youtube.com

^_^


Last edited by mrdeathjr on 13 December 2015 at 9:47 pm UTC

These frequent updates are sure garnishing regular attention from blogs & the Linux world.

I think it's good because the prestige of working on a primary Foss project will surely draw additional hands.

Similar to how Ubuntu took the spotlight with 6 month advertising campaigns.

View video on youtube.com

Shadow complex remastered shows another steps to work

View video on youtube.com

In lastest wine versions farcry 3 / farcry blood dragon work have limited pixel shaders and vertex shaders to 3 version in wine registry aka MaxShaderModelPS and MaxShaderModelVS

But in shadow complex remastered is needed new step, in this step is needed disable d3d10, d3d10core and d3d11 in libraries tab on winecfg*

*this step also needed in farcry 3 / farcry blood dragon

Maybe this situation are caused for recent changes in wine related with DX10 and upper

In other things is possible this wine rc is be last release candidate series, next could be wine 1.8 based in this communication (however devs can change this if them want)

Folks,

I'm pleased with the progress we've made since code freeze started, with
about 40 regressions and many other bugs fixed. Thanks to everybody for
taking the time to fix them!

At this point it looks like we are running out of easily fixable bugs,
so my plan is that rc4 is going to be the last release candidate, and
that 1.8 will be released next week.

Note also that rc4 is going to be a little delayed since I'm travelling
on Friday; it will be out during the weekend.

Thank you all for your help!

Alexandre Julliard
julliard at winehq.org

For see original message can see this link

https://www.winehq.org/pipermail/wine-devel/2015-December/110766.html

However in other news this week patch for doublebuffer is sended but not approved, based in this message

> Am 08.12.2015 um 20:42 schrieb Henri Verbeet <hverbeet at codeweavers.com>:
>
> - if (device->create_parms.flags & WINED3DCREATE_SOFTWARE_VERTEXPROCESSING)
> + if (device->create_parms.flags & WINED3DCREATE_SOFTWARE_VERTEXPROCESSING || pool == WINED3D_POOL_MANAGED)
This also helps bugs like 29878, or the Crysis bug that was I think incorrectly closed.

However, the reason why I've never made this seemingly obvious change is that you'll get other applications that crash due to VM exhaustion now. So I'm afraid you'll just trade one kind of breakage for another. The proper fix is probably somewhere in GL_ARB_buffer_storage, but that is too complicated for 1.8.

One app that needed direct mapping of managed buffers to run properly was Half Life 2. I think the game changed since then and sets the LAA flag, but there are other games with the same problem.

> Am 08.12.2015 um 20:42 schrieb Henri Verbeet <hverbeet at codeweavers.com>:
>
> - if (device->create_parms.flags & WINED3DCREATE_SOFTWARE_VERTEXPROCESSING)
> + if (device->create_parms.flags & WINED3DCREATE_SOFTWARE_VERTEXPROCESSING || pool == WINED3D_POOL_MANAGED)
This also helps bugs like 29878, or the Crysis bug that was I think incorrectly closed.

However, the reason why I've never made this seemingly obvious change is that you'll get other applications that crash due to VM exhaustion now. So I'm afraid you'll just trade one kind of breakage for another. The proper fix is probably somewhere in GL_ARB_buffer_storage, but that is too complicated for 1.8.

One app that needed direct mapping of managed buffers to run properly was Half Life 2. I think the game changed since then and sets the LAA flag, but there are other games with the same problem.

> Am 08.12.2015 um 22:33 schrieb Henri Verbeet <hverbeet at gmail.com>:
>
> That said, I'm not particularly attached to fixing this bug before
> 1.8, and the application in question needs additional patches to even
> start. The patch could certainly be deferred if you think the risk
> isn't worth it.
I'd say defer it, but change this shortly after 1.8. At the time 29878 was filed DOUBLEBUFFER was a no-go because it broke all source engine games, but a lot has changed since then.

> Yeah, there's that risk. It seems preferable though, and there are
> probably more options for reducing vm usage / fragmentation than for
> fixing this bug.
Agreed.

Personally I want the GL buffer code merged for surfaces, volumes and buffers before dealing with ARB_buffer_storage, but I'm convinced this extension is the path forward on solving a lot of buffer issues we have.

2015-12-08 22:53 GMT+01:00 Stefan Dösinger <stefandoesinger at gmail.com>:
>
>> Am 08.12.2015 um 20:42 schrieb Henri Verbeet <hverbeet at codeweavers.com>:
>>
>> - if (device->create_parms.flags & WINED3DCREATE_SOFTWARE_VERTEXPROCESSING)
>> + if (device->create_parms.flags & WINED3DCREATE_SOFTWARE_VERTEXPROCESSING || pool == WINED3D_POOL_MANAGED)
> This also helps bugs like 29878, or the Crysis bug that was I think incorrectly closed.

I guess you mean https://bugs.winehq.org/show_bug.cgi?id=18799, right?
I think we should reopen that one if you recall that Crysis uses the
managed pool for the relevant vertex buffer (which would make a lot of
sense).

WRT VM exhaustion, yeah, this might hurt but overall it still seems a
step in the right direction.
Not sure if it makes sense but we could potentially use
glBufferSubData() in buffer_direct_upload() instead of mapping the
VBO, that might help a bit with VM pressure or at least move the
problem to the GL implementation (also I'm not sure if
glBufferSubData() is still a bad idea for performance with some GL
drivers). Just thinking out loud...

But in good news them have thinking about ARB for solve this situation but for next development series, based in before message

^_^


Last edited by mrdeathjr on 14 December 2015 at 12:11 pm UTC

I guess it would be nice to know what games do support DX10/DX11 in wine-1.8, since support for that seems to be a little shaky for this release...