March 2007 - Wine-Devel - list.winehq.org

Re: DirectDrawRenderer - opengl non power of 2 windows

by Chris Bandy

Stefan Dösinger wrote: >> @@ -3194,6 +3193,7 @@ static HRESULT WINAPI >> > IWineD3DSurfaceImpl_PrivateSetup(IWineD3DSurface *iface) { > >> } else { >> /* No oversize, gl rect is the full texture size */ >> This->Flags &= ~SFLAG_OVERSIZE; >> + This->Flags &= SFLAG_NONPOW2; >> > > > This is not correct. This removes every flag except SFLAG_NONPOW2. If you want > to remove the SFLAG_NONPOW2 flag you have to invert the flag: > > This->Flags &= ~SFLAG_NONPOW2 > If you want to set the SFLAG_NONPOW2 flag... This->Flags |= SFLAG_NONPOW2

March 31, 2007

Re: DirectDrawRenderer - opengl non power of 2 windows

by Nathan Williams

Actually I needed to set that flag, otherwise other code further on fails, using the incorrect height. And now that I look at it, all my bitwise operator knowledge is coming back from university, that should have been a bitwise or! so: This->Flags |= SFLAG_NONPOW2; I'll fix it and resend an updated patch. On 3/31/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > > > @@ -3194,6 +3193,7 @@ static HRESULT WINAPI > IWineD3DSurfaceImpl_PrivateSetup(IWineD3DSurface *iface) { > > } else { > > /* No oversize, gl rect is the full texture size */ > > This->Flags &= ~SFLAG_OVERSIZE; > > + This->Flags &= SFLAG_NONPOW2; > > > This is not correct. This removes every flag except SFLAG_NONPOW2. If you want > to remove the SFLAG_NONPOW2 flag you have to invert the flag: > > This->Flags &= ~SFLAG_NONPOW2 > > -- Nathan

March 31, 2007

Re: [PATCH 1/1] wined3d: Make 8bpp a valid depth in EnumAdapterModes

by Stefan Dösinger

> You'll probably need to wait for Stefan or Henri to respond to figure out > what to do. Though, it appears DDraw can be patched to do a second > enumeration loop with WINED3DFORMAT_P8 if the first was with > WINED3DFMT_UNKNOWN.. whether or not this is acceptable, I'm not sure, but > it's an idea I just had. You can change WineD3D to allow WINED3DFMT_P8, but you have to modify d3d8 and d3d9 to filter it out. This is the correct approach then. Injecting P8 in ddraw will work too, but it is not correct from the design point of view(since then wined3d says "I can't do that", and ddraw says "But I insist you can do it"

March 31, 2007

Re: DirectDrawRenderer - opengl non power of 2 windows

by Stefan Dösinger

> @@ -3194,6 +3193,7 @@ static HRESULT WINAPI IWineD3DSurfaceImpl_PrivateSetup(IWineD3DSurface *iface) { > } else { > /* No oversize, gl rect is the full texture size */ > This->Flags &= ~SFLAG_OVERSIZE; > + This->Flags &= SFLAG_NONPOW2; This is not correct. This removes every flag except SFLAG_NONPOW2. If you want to remove the SFLAG_NONPOW2 flag you have to invert the flag: This->Flags &= ~SFLAG_NONPOW2

March 31, 2007

Re: Excluding a Windows version from the tests

by Alexandre Julliard

Paul Vriens <paul.vriens.wine(a)gmail.com> writes: > It turns out we had a lof of failures with this test on win98. It looks like > win98 doesn't assign a new handle when the same registry key is opened. This > means that the close test close the main handle and we thus have an issue in the > first test after that (which assumes to have a valid handle). > > The attached file uses the GetVersion to check for win9x, is that acceptable in > this case? Or is just an extra RegOpenKey (with comments) enough? > > The todo_wine is only there btw. to don't have an error when run in > win9x emulated mode. That brings up another question. Should all test > succeed in Wine regardless of the emulated mode? That's precisely why we don't want to add version checks in the tests. It requires todo_wine, then to fix the todos we need to add version checks in the code, which adds complexity and extra code paths, for no benefit. There are a gazillion differences between NT and win9x, and we don't want to replicate them unless strictly necessary. The tests should simply be written in a way that works on all platforms without version checks. -- Alexandre Julliard julliard(a)winehq.org

March 31, 2007

Re: [PATCH 1/1] wined3d: Make 8bpp a valid depth in EnumAdapterModes

by Vitaly Budovski

Chris Robinson wrote: > On Friday 30 March 2007 08:11:54 pm Vitaly Budovski wrote: > >> Make 8bpp a valid depth in EnumAdapterModes. This allows Age of Empires to >> start. >> --- >> dlls/wined3d/directx.c | 9 +++++++-- >> 1 files changed, 7 insertions(+), 2 deletions(-) >> > > > This causes the d3d8 device test to fail for me: > device.c:755: Test failed: Unexpected display mode returned for mode 42: 0x29 > ...all the way through to... > device.c:755: Test failed: Unexpected display mode returned for mode 83: 0x29 > > D3D8 only supports 32-bit X8R8G8B8 and 16-bit R5G6B5 modes as far as Windows > testing has shown, and passing WINED3DFMT_UNKNOWN to WineD3D for mode > enumeration makes it work on D3D8 modes only. > > You'll probably need to wait for Stefan or Henri to respond to figure out what > to do. Though, it appears DDraw can be patched to do a second enumeration > loop with WINED3DFORMAT_P8 if the first was with WINED3DFMT_UNKNOWN.. whether > or not this is acceptable, I'm not sure, but it's an idea I just had. > > > > I haven't really tested this patch much and I don't expect it to be applied. There was just a regression that prevented AOE from starting due to it not finding an 8bpp mode. The regression was caused by this patch: http://www.winehq.com/pipermail/wine-cvs/2007-February/030394.html BTW.

March 31, 2007

Re: [PATCH 1/1] wined3d: Make 8bpp a valid depth in EnumAdapterModes

by Chris Robinson

On Friday 30 March 2007 08:11:54 pm Vitaly Budovski wrote: > Make 8bpp a valid depth in EnumAdapterModes. This allows Age of Empires to > start. > --- > dlls/wined3d/directx.c | 9 +++++++-- > 1 files changed, 7 insertions(+), 2 deletions(-) This causes the d3d8 device test to fail for me: device.c:755: Test failed: Unexpected display mode returned for mode 42: 0x29 ...all the way through to... device.c:755: Test failed: Unexpected display mode returned for mode 83: 0x29 D3D8 only supports 32-bit X8R8G8B8 and 16-bit R5G6B5 modes as far as Windows testing has shown, and passing WINED3DFMT_UNKNOWN to WineD3D for mode enumeration makes it work on D3D8 modes only. You'll probably need to wait for Stefan or Henri to respond to figure out what to do. Though, it appears DDraw can be patched to do a second enumeration loop with WINED3DFORMAT_P8 if the first was with WINED3DFMT_UNKNOWN.. whether or not this is acceptable, I'm not sure, but it's an idea I just had.

March 31, 2007

Re: DirectDrawRenderer - opengl non power of 2 windows

by Nathan Williams

My first patch! Sorry this took so long for such a simple patch, I have just been run off my feet until now. Before I submit this to wine-patches, is anyone able to do some further testing for me, to make sure it doesn't break any currently working games? This patch fixes a bug that causes a crash for direct draw games when using opengl as the DirectDrawRenderer. I wanted to make sure this works and is safe, before I venture into making it optimized as Stefan suggested. On 3/25/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > > case WINED3DFMT_P8: > { > int height = This->glRect.bottom - This->glRect.top; <--!!! > type = GL_UNSIGNED_BYTE; > fmt = GL_RGBA; > > mem = HeapAlloc(GetProcessHeap(), 0, This->resource.size * sizeof(DWORD)); > if(!mem) { > ERR("Out of memory\n"); > return; > } > memory_allocated = TRUE; > d3dfmt_convert_surface(This->resource.allocatedMemory, > ... > > > I think the int height = This->glRect.bottom - This->glRect.top is the > problem. It should use This->currentDesc.Height instead. The opengl rectangle > is a helper for surfaces which are bigger than the max size supported by > opengl If they are used for 2D blits. For example swat3 creates a 3000x32 > surface to blit text in 32x32 rectangles. In this case only the needed area > is uploaded to gl and used for blits. > > Here the gl rectangle does not apply. For the sake of optimization you may > change the code to only convert the dirty rectangle instead of the whole > surface. > > -- Nathan

March 31, 2007

Re: Release notes

by Stefan Dösinger

Am Freitag 30 März 2007 22:26 schrieb John Voltz: > I have a question about the Wine release notes. Do the Wine developers > work from bugzilla or do they usually just work on a specific > application feature? Would it require too much extra effort on the > release notes to associate a specific change with a bugzilla bug-fix or > specific application/feature fix? I believe IMHO that this would make > the release notes more relevant and useful to the end user. I never can > tell what was actually fixed in a particular release because of the > obscure developer notes. I've been lurking on the wine-devel list > watching how development progresses, because at some point I would like > to attempt joining in on the development effort. I am personally mostly working on certain application features. If I am working on a bugzilla bug then I'll write a comment asking for retest there.

March 30, 2007

RE: [PATCH 13/18] XCOPY: Add support for /EXCLUDELIST:file1+file2 etc

by Ann & Jason Edmeades

Further investigations shows the strstr bit is right, but the string I am comparing with differs from windows. I have fixed up xcopy's output display to mirror windows, and added that as a patch on the end of the resubmitted patchset, as it is not directly related to the strstr bit Regards, Jason

March 30, 2007