Re: [3/3] WineD3D: Implement per stream offsets
On 17/01/07, Stefan Dösinger [EMAIL PROTECTED] wrote: really tested because I have no app that really needs this, but it should not cause issues with games not using stream offsets. I think Serious Sam 2 required stream offsets. Perhaps I should give that game another try one of these days.
Re: [3/3] WineD3D: Implement per stream offsets
Hi, one or more nvidia sdk demos using instancing.
Mirek
Stefan Dösinger napsal(a):
Stumbled uppon that while reading up instancing. This is a functionality
technically required for all d3d9 drivers. The new functionality is not
really tested because I have no app that really needs this, but it should not
cause issues with games not using stream offsets.
From 6bd68813f3b05e52ab2c28b331d838b50b92 Mon Sep 17 00:00:00 2001
From: Stefan Doesinger [EMAIL PROTECTED]
Date: Sat, 13 Jan 2007 15:09:16 +0100
Subject: [PATCH] WineD3D: Implement per stream offsets
---
dlls/wined3d/directx.c |2 +-
dlls/wined3d/drawprim.c | 47 +--
dlls/wined3d/state.c| 22 --
3 files changed, 50 insertions(+), 21 deletions(-)
diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c
index cbcbdc2..0e6f4bc 100644
--- a/dlls/wined3d/directx.c
+++ b/dlls/wined3d/directx.c
@@ -2244,7 +2244,7 @@ static HRESULT WINAPI IWineD3DImpl_GetDeviceCaps(IWineD3D
*iface, UINT Adapter,
*/
if (This-dxVersion 8) {
/* d3d9.dll sets D3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES here
because StretchRects is implemented in d3d9 */
-*pCaps-DevCaps2 = 0;
+*pCaps-DevCaps2 = D3DDEVCAPS2_STREAMOFFSET;
/* TODO: VS3.0 needs at least
D3DDEVCAPS2_VERTEXELEMENTSCANSHARESTREAMOFFSET */
*pCaps-MaxNpatchTessellationLevel= 0;
*pCaps-MasterAdapterOrdinal = 0;
diff --git a/dlls/wined3d/drawprim.c b/dlls/wined3d/drawprim.c
index 400ffb5..fdc9843 100644
--- a/dlls/wined3d/drawprim.c
+++ b/dlls/wined3d/drawprim.c
@@ -628,8 +628,12 @@ static void drawStridedSlow(IWineD3DDevice *iface,
WineDirect3DVertexStridedData
DWORD diffuseColor = 0x; /* Diffuse Color */
DWORD specularColor = 0; /* Specular Color */
IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *)iface;
+UINT *streamOffset = This-stateBlock-streamOffset;
LONG SkipnStrides = startVertex +
This-stateBlock-loadBaseVertexIndex;
+BYTE *texCoords[WINED3DDP_MAXTEXCOORD];
+BYTE *diffuse = NULL, *specular = NULL, *normal = NULL, *position = NULL;
+
TRACE(Using slow vertex array code\n);
/* Variable Initialization */
@@ -638,6 +642,29 @@ static void drawStridedSlow(IWineD3DDevice *iface,
WineDirect3DVertexStridedData
else pIdxBufL = (const long *) idxData;
}
+/* Adding the stream offset once is cheaper than doing it every iteration. Do not modify the strided data, it is a pointer
+ * to the strided Data in the device and might be needed intact on the
next draw
+ */
+for (textureNo = 0, texture_idx = 0; textureNo
GL_LIMITS(texture_stages); ++textureNo) {
+if(sd-u.s.texCoords[textureNo].lpData) {
+texCoords[textureNo] = sd-u.s.texCoords[textureNo].lpData +
streamOffset[sd-u.s.texCoords[textureNo].streamNo];
+} else {
+texCoords[textureNo] = NULL;
+}
+}
+if(sd-u.s.diffuse.lpData) {
+diffuse = sd-u.s.diffuse.lpData +
streamOffset[sd-u.s.diffuse.streamNo];
+}
+if(sd-u.s.specular.lpData) {
+specular = sd-u.s.specular.lpData +
streamOffset[sd-u.s.specular.streamNo];
+}
+if(sd-u.s.normal.lpData) {
+normal = sd-u.s.normal.lpData + streamOffset[sd-u.s.normal.streamNo];
+}
+if(sd-u.s.position.lpData) {
+position = sd-u.s.position.lpData +
streamOffset[sd-u.s.position.streamNo];
+}
+
/* Start drawing in GL */
VTRACE((glBegin(%x)\n, glPrimType));
glBegin(glPrimType);
@@ -707,8 +734,8 @@ static void drawStridedSlow(IWineD3DDevice *iface,
WineDirect3DVertexStridedData
continue;
}
-ptrToCoords = (float *)(sd-u.s.texCoords[coordIdx].lpData + (SkipnStrides * sd-u.s.texCoords[coordIdx].dwStride));
-if (sd-u.s.texCoords[coordIdx].lpData == NULL) {
+ptrToCoords = (float *)(texCoords[coordIdx] + (SkipnStrides *
sd-u.s.texCoords[coordIdx].dwStride));
+if (texCoords[coordIdx] == NULL) {
TRACE(tex: %d - Skipping tex coords, as no data
supplied\n, textureNo);
++texture_idx;
continue;
@@ -796,8 +823,8 @@ static void drawStridedSlow(IWineD3DDevice *iface,
WineDirect3DVertexStridedData
} /* End of textures */
/* Diffuse */
-if (sd-u.s.diffuse.lpData != NULL) {
-DWORD *ptrToCoords = (DWORD *)(sd-u.s.diffuse.lpData + (SkipnStrides
* sd-u.s.diffuse.dwStride));
+if (diffuse) {
+DWORD *ptrToCoords = (DWORD *)(diffuse + (SkipnStrides *
sd-u.s.diffuse.dwStride));
Re: Using Wine headers on Mac OS X
On Tue, 16 Jan 2007, Mike wrote: [...] My big question is: when I add the Wine headers to my project, it seems that every datatype in the wine headers is undefined. I noticed that most wine headers don't have any #includes in them. Normally the Wine headers have the same set of #include directives as the PSDK headers. If that's not the case then it's a bug. But yes, the PSDK headers often don't include each other. is there some precompiled or metaheader that I should be including in all of the wine files in order to get the compiler to see the data types? You're probably thinking about 'windows.h'. This is the one header included by most Windows applications. However it includes most everything which may be causing problems too. But since you're porting Windows code, how come it does not already include the right PSDK headers? -- Francois Gouget [EMAIL PROTECTED] http://fgouget.free.fr/ In theory, theory and practice are the same, but in practice they're different.
Re: [3/3] WineD3D: Implement per stream offsets
Call of duty 2 uses steam offsets. 2007. január 17. 00.06 dátummal Stefan Dösinger ezt írta: Stumbled uppon that while reading up instancing. This is a functionality technically required for all d3d9 drivers. The new functionality is not really tested because I have no app that really needs this, but it should not cause issues with games not using stream offsets. -- -- andras NetClub Lamarr csevego.net [EMAIL PROTECTED] --
Re: [3/3] WineD3D: Implement per stream offsets
Wow, CoD 2 in menu now works!! Mirek Kovács András napsal(a): Call of duty 2 uses steam offsets. 2007. január 17. 00.06 dátummal Stefan Dösinger ezt írta: Stumbled uppon that while reading up instancing. This is a functionality technically required for all d3d9 drivers. The new functionality is not really tested because I have no app that really needs this, but it should not cause issues with games not using stream offsets.
Re: [3/3] WineD3D: Implement per stream offsets
Serious Sam 2 can now even run, but graphic is completly broken. Mirek H. Verbeet napsal(a): On 17/01/07, Stefan Dösinger [EMAIL PROTECTED] wrote: really tested because I have no app that really needs this, but it should not cause issues with games not using stream offsets. I think Serious Sam 2 required stream offsets. Perhaps I should give that game another try one of these days.
Re: Make.rules.in: Add variables for BISONFLAGS and LEXFLAGS.
Robert Shearman [EMAIL PROTECTED] writes: Make BISONFLAGS default to generating debug information so that parser tracing works in the various tools. You should add this to the makefile of the tool you want to debug. There's no reason to force it for all parsers, and defining it in Make.rules prevents individual makefiles from having their own flags. -- Alexandre Julliard [EMAIL PROTECTED]
[try2] user32/tests: add tests for WM_SETICON - what's wrong?
Hi, Traditional questions from rejected patch-sender: 1) What's wrong with the patch: http://www.winehq.org/pipermail/wine-patches/2007-January/034949.html 2) What can be done to improve it? -- Kirill
Re: [3/3] WineD3D: Implement per stream offsets
Am Mittwoch 17 Januar 2007 10:51 schrieb Kovács András: Call of duty 2 uses steam offsets. I think you had some other games(BGE?) which had strange geometry corruption. Can you test them with that patch? pgpw89EAUBQgQ.pgp Description: PGP signature
Re: [try2] user32/tests: add tests for WM_SETICON - what's wrong?
Kirill K. Smirnov [EMAIL PROTECTED] writes: Traditional questions from rejected patch-sender: 1) What's wrong with the patch: http://www.winehq.org/pipermail/wine-patches/2007-January/034949.html 2) What can be done to improve it? The test fails on Windows XP: msg.c:3944: Test failed: WM_SETICON for shown window with caption: the msg sequence is not complete: expected - actual 00ae -- Alexandre Julliard [EMAIL PROTECTED]
Re: [1/4] D3D9: Implement IDirect3DDevice9::StretchRect
Hi, this patch caused big performance regression in some D3D games
(Flatout 2, Tomb Raider: Legend, HalfLife 2: Episode One).
Mirek Slugen
Stefan Dösinger napsal(a):
This time with a FIXME for unsupported filtering options. If we implement
them, it should be done in Blt and private blitting flags used.
From 95f4217d366770b9b05214ae68274ce4ab4b9fb6 Mon Sep 17 00:00:00 2001
From: Stefan Doesinger [EMAIL PROTECTED]
Date: Thu, 11 Jan 2007 22:39:03 +0100
Subject: [PATCH] D3D9: Implement IDirect3DDevice9::StretchRect
---
dlls/d3d9/device.c | 10 +++---
dlls/d3d9/directx.c |3 +++
dlls/wined3d/device.c|9 -
include/wine/wined3d_interface.h |2 --
4 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/dlls/d3d9/device.c b/dlls/d3d9/device.c
index aa788af..4c27853 100644
--- a/dlls/d3d9/device.c
+++ b/dlls/d3d9/device.c
@@ -356,9 +356,13 @@ static HRESULT WINAPI
IDirect3DDevice9Impl_GetFrontBufferData(LPDIRECT3DDEVICE
}
static HRESULT WINAPI IDirect3DDevice9Impl_StretchRect(LPDIRECT3DDEVICE9 iface, IDirect3DSurface9* pSourceSurface, CONST RECT* pSourceRect, IDirect3DSurface9* pDestSurface, CONST RECT* pDestRect, D3DTEXTUREFILTERTYPE Filter) {
-IDirect3DDevice9Impl *This = (IDirect3DDevice9Impl *)iface;
-TRACE((%p) Relay\n , This);
-return IWineD3DDevice_StretchRect(This-WineD3DDevice, ((IDirect3DSurface9Impl *)pSourceSurface)-wineD3DSurface, pSourceRect, ((IDirect3DSurface9Impl *)pDestSurface)-wineD3DSurface, pDestRect, (WINED3DTEXTUREFILTERTYPE) Filter);
+IDirect3DDevice9Impl *This = (IDirect3DDevice9Impl *)iface;
+IDirect3DSurface9Impl *src = (IDirect3DSurface9Impl *) pSourceSurface;
+IDirect3DSurface9Impl *dst = (IDirect3DSurface9Impl *) pDestSurface;
+
+TRACE((%p)-(%p,%p,%p,%p,%d)\n , This, src, pSourceRect, dst, pDestRect,
Filter);
+if(Filter != D3DTEXF_NONE) ERR(Texture filters not supported yet\n);
+return IWineD3DSurface_Blt(dst-wineD3DSurface, (RECT *) pDestRect,
src-wineD3DSurface, (RECT *) pSourceRect, 0, NULL);
}
static HRESULT WINAPI IDirect3DDevice9Impl_ColorFill(LPDIRECT3DDEVICE9 iface, IDirect3DSurface9* pSurface, CONST RECT* pRect, D3DCOLOR color) {
diff --git a/dlls/d3d9/directx.c b/dlls/d3d9/directx.c
index f360b4e..57062b2 100644
--- a/dlls/d3d9/directx.c
+++ b/dlls/d3d9/directx.c
@@ -170,6 +170,9 @@ static HRESULT WINAPI
IDirect3D9Impl_GetDeviceCaps(LPDIRECT3D9 iface, UINT Adapt
D3D9CAPSTOWINECAPS(pCaps, pWineCaps)
hrc = IWineD3D_GetDeviceCaps(This-WineD3D, Adapter, DeviceType,
pWineCaps);
HeapFree(GetProcessHeap(), 0, pWineCaps);
+
+/* Some functionality is implemented in d3d9.dll, not wined3d.dll. Add the
needed caps */
+pCaps-Caps2 |= D3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES;
TRACE((%p) returning %p\n, This, pCaps);
return hrc;
}
diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c
index 7b81f0e..5f964fb 100644
--- a/dlls/wined3d/device.c
+++ b/dlls/wined3d/device.c
@@ -4930,14 +4930,6 @@ static HRESULT WINAPI IWineD3DDeviceImpl_UpdateTexture
(IWineD3DDevice *iface, I
return hr;
}
-static HRESULT WINAPI IWineD3DDeviceImpl_StretchRect(IWineD3DDevice *iface, IWineD3DSurface *pSourceSurface,
-CONST RECT* pSourceRect,
IWineD3DSurface *pDestinationSurface,
-CONST RECT* pDestRect,
WINED3DTEXTUREFILTERTYPE Filter) {
-IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *)iface;
-
-TRACE((%p) : stub\n, This);
-return WINED3D_OK;
-}
static HRESULT WINAPI IWineD3DDeviceImpl_GetRenderTargetData(IWineD3DDevice
*iface, IWineD3DSurface *pRenderTarget, IWineD3DSurface *pSurface) {
IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *)iface;
/** TODO: remove remove casts to IWineD3DSurfaceImpl *
@@ -6776,7 +6768,6 @@ const IWineD3DDeviceVtbl IWineD3DDevice_Vtbl =
IWineD3DDeviceImpl_ColorFill,
IWineD3DDeviceImpl_UpdateTexture,
IWineD3DDeviceImpl_UpdateSurface,
-IWineD3DDeviceImpl_StretchRect,
IWineD3DDeviceImpl_GetRenderTargetData,
IWineD3DDeviceImpl_GetFrontBufferData,
/*** object tracking ***/
diff --git a/include/wine/wined3d_interface.h b/include/wine/wined3d_interface.h
index 8a685f0..4a24636 100644
--- a/include/wine/wined3d_interface.h
+++ b/include/wine/wined3d_interface.h
@@ -469,7 +469,6 @@ DECLARE_INTERFACE_(IWineD3DDevice,IWineD3DBase)
STDMETHOD(ColorFill)(THIS_ struct IWineD3DSurface* pSurface, CONST
WINED3DRECT* pRect, WINED3DCOLOR color) PURE;
STDMETHOD(UpdateTexture)(THIS_ struct IWineD3DBaseTexture *pSourceTexture,
struct IWineD3DBaseTexture *pDestinationTexture) PURE;
STDMETHOD(UpdateSurface)(THIS_ struct IWineD3DSurface* pSourceSurface,
CONST RECT* pSourceRect, struct IWineD3DSurface* pDestinationSurface, CONST
POINT* pDestPoint) PURE;
-
Re: [17/49] wined3d: Rewrite shader_glsl_mov() to properly take the write mask into account, in case of writing to an address register round the source
Hi, this patch caused regression in TES: Oblivion, some objects like
peoples are broken.
Mirek Slugen
H. Verbeet napsal(a):
Changelog:
- Rewrite shader_glsl_mov() to properly take the write mask into account
- in case of writing to an address register round the source, rather
than just dropping the fractional part
---
dlls/wined3d/glsl_shader.c | 33 -
1 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/dlls/wined3d/glsl_shader.c b/dlls/wined3d/glsl_shader.c
index 60f74c0..6579e6d 100644
--- a/dlls/wined3d/glsl_shader.c
+++ b/dlls/wined3d/glsl_shader.c
@@ -963,17 +963,32 @@ void shader_glsl_arith(SHADER_OPCODE_ARG* arg) {
/* Process the WINED3DSIO_MOV opcode using GLSL (dst = src) */
void shader_glsl_mov(SHADER_OPCODE_ARG* arg) {
-
+IWineD3DBaseShaderImpl* shader = (IWineD3DBaseShaderImpl*) arg-shader;
SHADER_BUFFER* buffer = arg-buffer;
-char tmpLine[256];
-char dst_str[100], src0_str[100];
-char dst_reg[50], src0_reg[50];
-char dst_mask[6], src0_mask[6];
+char src0_str[100];
+char src0_reg[50];
+char src0_mask[6];
+DWORD write_mask;
-shader_glsl_add_dst_param(arg, arg-dst, 0, dst_reg, dst_mask, dst_str);
-shader_glsl_add_src_param_old(arg, arg-src[0], arg-src_addr[0],
src0_reg, src0_mask, src0_str);
-shader_glsl_add_dst_old(arg-dst, dst_reg, dst_mask, tmpLine);
-shader_addline(buffer, %s%s)%s;\n, tmpLine, src0_str, dst_mask);
+write_mask = shader_glsl_append_dst(buffer, arg);
+shader_glsl_add_src_param(arg, arg-src[0], arg-src_addr[0], write_mask,
src0_reg, src0_mask, src0_str);
+
+/* In vs_1_1 WINED3DSIO_MOV can write to the adress register. In later
+ * shader versions WINED3DSIO_MOVA is used for this. */
+if ((WINED3DSHADER_VERSION_MAJOR(shader-baseShader.hex_version) == 1
+!shader_is_pshader_version(shader-baseShader.hex_version)
+shader_get_regtype(arg-dst) == WINED3DSPR_ADDR) ||
+arg-opcode-opcode == WINED3DSIO_MOVA) {
+/* We need to *round* to the nearest int here. */
+size_t mask_size = shader_glsl_get_write_mask_size(write_mask);
+if (mask_size 1) {
+shader_addline(buffer, ivec%d(floor(%s + vec%d(0.5;\n,
mask_size, src0_str, mask_size);
+} else {
+shader_addline(buffer, int(floor(%s + 0.5)));\n, src0_str);
+}
+} else {
+shader_addline(buffer, %s);\n, src0_str);
+}
}
/* Process the dot product operators DP3 and DP4 in GLSL (dst = dot(src0, src1)) */
Re: [17/49] wined3d: Rewrite shader_glsl_mov() to properly take the write mask into account, in case of writing to an address register round the source
On 17/01/07, Mirek [EMAIL PROTECTED] wrote: Hi, this patch caused regression in TES: Oblivion, some objects like peoples are broken. That doesn't have a demo, does it?
Re: [17/49] wined3d: Rewrite shader_glsl_mov() to properly take the write mask into account, in case of writing to an address register round the source
I have Nvidia GF6800GS with latest stable drivers (OpenGL version string: 2.1.0 NVIDIA 97.46). All errors from log file are here (with current cvs): athlon64:/usr/games/oblivion# cat log.log | grep err err:d3d:IWineD3DImpl_CheckDepthStencilMatch unsupported format pair: WINED3DFMT_A4R4G4B4 and WINED3DFMT_D16_LOCKABLE err:d3d:IWineD3DImpl_CheckDepthStencilMatch unsupported format pair: WINED3DFMT_A4R4G4B4 and WINED3DFMT_D32 err:d3d:IWineD3DImpl_CheckDepthStencilMatch unsupported format pair: WINED3DFMT_A4R4G4B4 and WINED3DFMT_D15S1 err:d3d:IWineD3DImpl_CheckDepthStencilMatch unsupported format pair: WINED3DFMT_A4R4G4B4 and WINED3DFMT_D24S8 err:d3d:IWineD3DImpl_CheckDepthStencilMatch unsupported format pair: WINED3DFMT_A4R4G4B4 and WINED3DFMT_D24X8 err:d3d:IWineD3DImpl_CheckDepthStencilMatch unsupported format pair: WINED3DFMT_A4R4G4B4 and WINED3DFMT_D24X4S4 err:d3d:IWineD3DImpl_CheckDepthStencilMatch unsupported format pair: WINED3DFMT_A4R4G4B4 and WINED3DFMT_D32F_LOCKABLE err:d3d:IWineD3DImpl_CheckDepthStencilMatch unsupported format pair: WINED3DFMT_A4R4G4B4 and WINED3DFMT_D24FS8 err:d3d:IWineD3DImpl_CheckDepthStencilMatch unsupported format pair: WINED3DFMT_A4R4G4B4 and WINED3DFMT_D16 err:d3d:IWineD3DImpl_CheckDepthStencilMatch unsupported format pair: WINED3DFMT_X4R4G4B4 and WINED3DFMT_D16_LOCKABLE err:d3d:IWineD3DImpl_CheckDepthStencilMatch unsupported format pair: WINED3DFMT_X4R4G4B4 and WINED3DFMT_D32 err:d3d:IWineD3DImpl_CheckDepthStencilMatch unsupported format pair: WINED3DFMT_X4R4G4B4 and WINED3DFMT_D15S1 err:d3d:IWineD3DImpl_CheckDepthStencilMatch unsupported format pair: WINED3DFMT_X4R4G4B4 and WINED3DFMT_D24S8 err:d3d:IWineD3DImpl_CheckDepthStencilMatch unsupported format pair: WINED3DFMT_X4R4G4B4 and WINED3DFMT_D24X8 err:d3d:IWineD3DImpl_CheckDepthStencilMatch unsupported format pair: WINED3DFMT_X4R4G4B4 and WINED3DFMT_D24X4S4 err:d3d:IWineD3DImpl_CheckDepthStencilMatch unsupported format pair: WINED3DFMT_X4R4G4B4 and WINED3DFMT_D32F_LOCKABLE err:d3d:IWineD3DImpl_CheckDepthStencilMatch unsupported format pair: WINED3DFMT_X4R4G4B4 and WINED3DFMT_D24FS8 err:d3d:IWineD3DImpl_CheckDepthStencilMatch unsupported format pair: WINED3DFMT_X4R4G4B4 and WINED3DFMT_D16 err:d3d:IWineD3DImpl_CheckDepthStencilMatch unsupported format pair: WINED3DFMT_A4R4G4B4 and WINED3DFMT_D16_LOCKABLE err:d3d:IWineD3DImpl_CheckDepthStencilMatch unsupported format pair: WINED3DFMT_A4R4G4B4 and WINED3DFMT_D32 err:d3d:IWineD3DImpl_CheckDepthStencilMatch unsupported format pair: WINED3DFMT_A4R4G4B4 and WINED3DFMT_D15S1 err:d3d:IWineD3DImpl_CheckDepthStencilMatch unsupported format pair: WINED3DFMT_A4R4G4B4 and WINED3DFMT_D24S8 err:d3d:IWineD3DImpl_CheckDepthStencilMatch unsupported format pair: WINED3DFMT_A4R4G4B4 and WINED3DFMT_D24X8 err:d3d:IWineD3DImpl_CheckDepthStencilMatch unsupported format pair: WINED3DFMT_A4R4G4B4 and WINED3DFMT_D24X4S4 err:d3d:IWineD3DImpl_CheckDepthStencilMatch unsupported format pair: WINED3DFMT_A4R4G4B4 and WINED3DFMT_D32F_LOCKABLE err:d3d:IWineD3DImpl_CheckDepthStencilMatch unsupported format pair: WINED3DFMT_A4R4G4B4 and WINED3DFMT_D24FS8 err:d3d:IWineD3DImpl_CheckDepthStencilMatch unsupported format pair: WINED3DFMT_A4R4G4B4 and WINED3DFMT_D16 err:d3d:IWineD3DImpl_CheckDepthStencilMatch unsupported format pair: WINED3DFMT_X4R4G4B4 and WINED3DFMT_D16_LOCKABLE err:d3d:IWineD3DImpl_CheckDepthStencilMatch unsupported format pair: WINED3DFMT_X4R4G4B4 and WINED3DFMT_D32 err:d3d:IWineD3DImpl_CheckDepthStencilMatch unsupported format pair: WINED3DFMT_X4R4G4B4 and WINED3DFMT_D15S1 err:d3d:IWineD3DImpl_CheckDepthStencilMatch unsupported format pair: WINED3DFMT_X4R4G4B4 and WINED3DFMT_D24S8 err:d3d:IWineD3DImpl_CheckDepthStencilMatch unsupported format pair: WINED3DFMT_X4R4G4B4 and WINED3DFMT_D24X8 err:d3d:IWineD3DImpl_CheckDepthStencilMatch unsupported format pair: WINED3DFMT_X4R4G4B4 and WINED3DFMT_D24X4S4 err:d3d:IWineD3DImpl_CheckDepthStencilMatch unsupported format pair: WINED3DFMT_X4R4G4B4 and WINED3DFMT_D32F_LOCKABLE err:d3d:IWineD3DImpl_CheckDepthStencilMatch unsupported format pair: WINED3DFMT_X4R4G4B4 and WINED3DFMT_D24FS8 err:d3d:IWineD3DImpl_CheckDepthStencilMatch unsupported format pair: WINED3DFMT_X4R4G4B4 and WINED3DFMT_D16 err:d3d:IWineD3DImpl_CheckDepthStencilMatch unsupported format pair: WINED3DFMT_A4R4G4B4 and WINED3DFMT_D16_LOCKABLE err:d3d:IWineD3DImpl_CheckDepthStencilMatch unsupported format pair: WINED3DFMT_A4R4G4B4 and WINED3DFMT_D32 err:d3d:IWineD3DImpl_CheckDepthStencilMatch unsupported format pair: WINED3DFMT_A4R4G4B4 and WINED3DFMT_D15S1 err:d3d:IWineD3DImpl_CheckDepthStencilMatch unsupported format pair: WINED3DFMT_A4R4G4B4 and WINED3DFMT_D24S8 err:d3d:IWineD3DImpl_CheckDepthStencilMatch unsupported format pair: WINED3DFMT_A4R4G4B4 and WINED3DFMT_D24X8 err:d3d:IWineD3DImpl_CheckDepthStencilMatch unsupported format pair: WINED3DFMT_A4R4G4B4 and WINED3DFMT_D24X4S4 err:d3d:IWineD3DImpl_CheckDepthStencilMatch unsupported format
Re: [17/49] wined3d: Rewrite shader_glsl_mov() to properly take the write mask into account, in case of writing to an address register round the source
No, but i can send you some screenshots and if you want even some debug or i can try some patches. Mirek H. Verbeet napsal(a): On 17/01/07, Mirek [EMAIL PROTECTED] wrote: Hi, this patch caused regression in TES: Oblivion, some objects like peoples are broken. That doesn't have a demo, does it?
Re: [17/49] wined3d: Rewrite shader_glsl_mov() to properly take the write mask into account, in case of writing to an address register round the source
On 17/01/07, Mirek [EMAIL PROTECTED] wrote: fixme:d3d_shader:print_glsl_info_log Error received from GLSL shader #50: (12) : warning C7505: OpenGL does not allow swizzles on scalar expressions\n(12) : error C1031: swizzle mask element not present in operand \xyzw\\n fixme:d3d_shader:print_glsl_info_log Error received from GLSL shader #51: Fragment info\n-\n(12) : warning C7505: OpenGL does not allow swizzles on scalar expressions\n(12) : error C1031: swizzle mask element not present in operand \xyzw\\n That doesn't look quite right :-) Could you open a bug report and attach the complete +d3d_shader trace?
Re: [17/49] wined3d: Rewrite shader_glsl_mov() to properly take the write mask into account, in case of writing to an address register round the source
On 17/01/07, Mirek [EMAIL PROTECTED] wrote: No, but i can send you some screenshots and if you want even some debug or i can try some patches. Mirek What drivers are you using at the moment? Does +d3d_shader produce any errors?
Anonymous structs/unions
As seen here http://source.winehq.org/source/include/winnt.h#L152, we seem to be going through a lot of trouble to enable anonymous structs and unions for those compilers that support it. Why do this, especially when we need to name them anyway for those that don't? My reason for asking is that I'm doing a casual ANSI sweep of the code, and anonymous unions are causing problems (they're not allowed). I could just put in a test for __STRICT_ANSI__ and disable them if found, but that feels like gaming the system, and it's not a standard macro anyway. The best way (other than just naming all the structs/unions) is to test for __STDC__, but GCC includes that one even when not using -ansi mode. Thoughts? -- Joel Parker
Re: [17/49] wined3d: Rewrite shader_glsl_mov() to properly take the write mask into account, in case of writing to an address register round the source
H. Verbeet napsal(a): On 17/01/07, Mirek [EMAIL PROTECTED] wrote: fixme:d3d_shader:print_glsl_info_log Error received from GLSL shader #50: (12) : warning C7505: OpenGL does not allow swizzles on scalar expressions\n(12) : error C1031: swizzle mask element not present in operand \xyzw\\n fixme:d3d_shader:print_glsl_info_log Error received from GLSL shader #51: Fragment info\n-\n(12) : warning C7505: OpenGL does not allow swizzles on scalar expressions\n(12) : error C1031: swizzle mask element not present in operand \xyzw\\n That doesn't look quite right :-) Could you open a bug report and attach the complete +d3d_shader trace? Ok, but complete d3d_shader trace has about 2 GB :( Mirek
Re: [17/49] wined3d: Rewrite shader_glsl_mov() to properly take the write mask into account, in case of writing to an address register round the source
On 17/01/07, Mirek [EMAIL PROTECTED] wrote: Ok, but complete d3d_shader trace has about 2 GB :( If you want to narrow it down, just include the GLSL part for the shader that generates the error, and the d3d part. Ie, the TRACE for SetFunction for that shader. We should probably give shader constants their own debug channel.
Re: [Wine] www.winehq.com newsletter dead forever?
I would love for someone to take it over, but I'm not sure that'll happen. Life is calming down a bit to the point where I could probably write it again if I had Internet access at home. But I don't and getting it isn't that high of a priority for me. So maybe sometime there will be a resurrection of it, but for now I think it's on hiatus. -Brian On 1/16/07, Hiji [EMAIL PROTECTED] wrote: The developer's list was talking about this a couple of weeks back. Somebody was going to take over and continue the newsletter, but nothing yet. - Original Message From: Michal Seliga [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, January 16, 2007 10:14:31 AM Subject: [Wine] www.winehq.com newsletter dead forever? I know its like this for a long time, but i have to ask... what happened with Wine newsletter? it was interesting reading and now its gone there is no update since last wineconf ___ wine-users mailing list [EMAIL PROTECTED] http://www.winehq.org/mailman/listinfo/wine-users Be a PS3 game guru. Get your game face on with the latest PS3 news and previews at Yahoo! Games. http://videogames.yahoo.com/platform?platform=120121
Re: Anonymous structs/unions
Joel Parker wrote: As seen here http://source.winehq.org/source/include/winnt.h#L152, we seem to be going through a lot of trouble to enable anonymous structs and unions for those compilers that support it. Why do this, especially when we need to name them anyway for those that don't? For compatibility with source code without NONAMELESSUNIONS/STRUCTS that is compiled with compilers that support anonymous structs and unions. My reason for asking is that I'm doing a casual ANSI sweep of the code, and anonymous unions are causing problems (they're not allowed). I could just put in a test for __STRICT_ANSI__ and disable them if found, but that feels like gaming the system, and it's not a standard macro anyway. The best way (other than just naming all the structs/unions) is to test for __STDC__, but GCC includes that one even when not using -ansi mode. Thoughts? I have never been a fan of changing code for the benefit of enabling obscure compiler options that don't help to fix bugs, but I guess the check for __STRICT_ANSI__ is the best. -- Rob Shearman
Re: Anonymous structs/unions
Joel Parker wrote: As seen here http://source.winehq.org/source/include/winnt.h#L152, we seem to be going through a lot of trouble to enable anonymous structs and unions for those compilers that support it. Why do this, especially when we need to name them anyway for those that don't? My reason for asking is that I'm doing a casual ANSI sweep of the code, I doubt that is useful. If you do that i would at least check for C99. There is no point for checking for compatibility with an old standard just for the sake of being compliant. There is a point though to keep compliance with an old existing compiler that people still use. That is for Wine gcc-2.95. and anonymous unions are causing problems (they're not allowed). I could just put in a test for __STRICT_ANSI__ and disable them if found, but that feels like gaming the system, and it's not a standard macro anyway. The best way (other than just naming all the structs/unions) is to test for __STDC__, but GCC includes that one even when not using -ansi mode. Thoughts? See above. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network EngineerFax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart
File buffering
Hi, I have a Visual Fortran application which exhibits problems related to concurrency and file buffer flushing when run under wine (it works under all versions of windows). The program does essentially this: opens a file writes to it closes it forks another program to read the file just written deletes the file in the original process Under wine, the forked program does not find the file just written. If I run the program under winedbg and set a breakpoint somewhere between writing and deletion, the buffers are flushed when the breakpoint is reached, and the program works as it does under windows. To my mind this would indicate that windows flushes all open buffers before forking a new process (the api call I see in wine debug output is CreateProcessW). Would it make sense to add flush-calls to the wine implementation as well? I tried to make the program work by adding calls to the Fortran subroutine FLUSH between closing and forking, but somewhat surprisingly, that didn't help. Teemu
Re: [kernel32][console][try3] Adds comment for function
Anatoly Lyutin wrote:
+ * NOTES
+ * Has appeared, since Windows 2000 Professional
*/
HWND WINAPI GetConsoleWindow(VOID)
{
We don't tend to add notes like this for functions as it is meaningless
in the context of Wine.
Also, when adding comments you must also add a disclaimer stating that
you didn't copy it from MSDN.
--
Rob Shearman
ntdll: Declare some functions static
Sorry. This patch breaks compilation. Please do not apply. -- Andy.
Re: ntdll: Declare some functions static
On Wed, Jan 17, 2007 at 08:20:32PM +, Andrew Talbot wrote:
Changelog:
ntdll: Declare some functions static.
diff -urN a/dlls/ntdll/exception.c b/dlls/ntdll/exception.c
--- a/dlls/ntdll/exception.c 2007-01-10 22:13:12.0 +
+++ b/dlls/ntdll/exception.c 2007-01-17 20:11:06.0 +
@@ -374,7 +374,7 @@
/***
* RtlRaiseException (NTDLL.@)
*/
-void WINAPI __regs_RtlRaiseException( EXCEPTION_RECORD *rec, CONTEXT
*context )
+static void WINAPI __regs_RtlRaiseException( EXCEPTION_RECORD *rec, CONTEXT
*context )
{
NTSTATUS status = raise_exception( rec, context, TRUE );
if (status != STATUS_SUCCESS)
@@ -624,7 +624,7 @@
* ntdll-specific implementation to avoid depending on kernel functions.
* Can be removed once ntdll.spec no longer contains stubs.
*/
-void __wine_spec_unimplemented_stub( const char *module, const char
*function )
+static void __wine_spec_unimplemented_stub( const char *module, const char
*function )
{
EXCEPTION_RECORD record;
This is not a good idea, it will optimize those functions away, since gcc
cannot look
into the DEFINE_REGS_ENTRYPOINT() assembly.
Ciao, Marcs
Re: [17/49] wined3d: Rewrite shader_glsl_mov() to properly take the write mask into account, in case of writing to an address register round the source
Can i apply your latest patch for shader debuging and post debuging with +d3d_shader? Mirek Slugen H. Verbeet napsal(a): On 17/01/07, Mirek [EMAIL PROTECTED] wrote: Ok, but complete d3d_shader trace has about 2 GB :( If you want to narrow it down, just include the GLSL part for the shader that generates the error, and the d3d part. Ie, the TRACE for SetFunction for that shader. We should probably give shader constants their own debug channel.
Re: ntdll: Declare some functions static
Marcus Meissner wrote: This is not a good idea, it will optimize those functions away, since gcc cannot look into the DEFINE_REGS_ENTRYPOINT() assembly. Ciao, Marcs Hi Marcus, Thanks for putting me straight. I accidentally submitted this patch before realising that I had forgotten to rebuild Wine. -- Andy.
Re: [1/4] D3D9: Implement IDirect3DDevice9::StretchRect
Am Mittwoch 17 Januar 2007 17:33 schrieb Mirek: Hi, this patch caused big performance regression in some D3D games (Flatout 2, Tomb Raider: Legend, HalfLife 2: Episode One). Yes, this is a known problem. It is a feature, not a bug :-) The underlying Blit operation is pretty slow because glCopyTexSubImage cannot do stretching. I am working on optimizing it. pgpBlQY8eqJnW.pgp Description: PGP signature
Re: [17/49] wined3d: Rewrite shader_glsl_mov() to properly take the write mask into account, in case of writing to an address register round the source
On 17/01/07, Mirek [EMAIL PROTECTED] wrote: Can i apply your latest patch for shader debuging and post debuging with +d3d_shader? Sure.
Re: [Wine] www.winehq.com newsletter dead forever?
On Wednesday 17 January 2007 20:20, Brian Vincent wrote: I would love for someone to take it over, but I'm not sure that'll happen. I said this before (in IRC, I guess), but I think that WWN could be done with a load balancing scheme. Round robin seems to be fine for that. So, let's say we get 4 people to do it, then it's one issue per month and person. That would be doable. Any takers? Kai -- Kai Blin, kai Dot blin At gmail Dot com WorldForge developerhttp://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton. pgpsnGhrLIil4.pgp Description: PGP signature
Re: [17/49] wined3d: Rewrite shader_glsl_mov() to properly take the write mask into account, in case of writing to an address register round the source
http://bugs.winehq.org/show_bug.cgi?id=7203 Mirek Slugen H. Verbeet napsal(a): On 17/01/07, Mirek [EMAIL PROTECTED] wrote: Can i apply your latest patch for shader debuging and post debuging with +d3d_shader? Sure.
Re: Using Wine headers on Mac OS X
The correct answer to my problem is: #include guiddefs.h which I found only via much searching. As for why the correct headers are not included, the answer to that is: 1. Typical, usual sloppy coding practices. 2. Lack of attention to detail and code organization. 3. The Windows developers probably used some kind of precompiled headers which makes up for the lack of the correct includes in the source files. 4. The source files do include the right headers, but the Windows headers don't work on Mac OS X and hence I have to substitute my own. Mike Francois Gouget wrote: On Tue, 16 Jan 2007, Mike wrote: [...] My big question is: when I add the Wine headers to my project, it seems that every datatype in the wine headers is undefined. I noticed that most wine headers don't have any #includes in them. Normally the Wine headers have the same set of #include directives as the PSDK headers. If that's not the case then it's a bug. But yes, the PSDK headers often don't include each other. is there some precompiled or metaheader that I should be including in all of the wine files in order to get the compiler to see the data types? You're probably thinking about 'windows.h'. This is the one header included by most Windows applications. However it includes most everything which may be causing problems too. But since you're porting Windows code, how come it does not already include the right PSDK headers?
Re: [1/4] D3D9: Implement IDirect3DDevice9::StretchRect
Confirmed. HL2 and Counter Strike Source work *much* faster in 1024x768 then in my default 800x600. However TRL is still roughly .2 FPS I would like to note that this patch does fix intro movies in HL2 and adds some missing details too (4th rotating panel in CSS stress test has correct colors now, two big columns in Cliner's lab now correct color with raising bubbles). Great work! Vitaliy Margolen Mirek wrote: Hi, this patch caused big performance regression in some D3D games (Flatout 2, Tomb Raider: Legend, HalfLife 2: Episode One). Mirek Slugen Stefan Dösinger napsal(a): This time with a FIXME for unsupported filtering options. If we implement them, it should be done in Blt and private blitting flags used. From 95f4217d366770b9b05214ae68274ce4ab4b9fb6 Mon Sep 17 00:00:00 2001 From: Stefan Doesinger [EMAIL PROTECTED] Date: Thu, 11 Jan 2007 22:39:03 +0100 Subject: [PATCH] D3D9: Implement IDirect3DDevice9::StretchRect
Re: File buffering
On 1/17/07, Teemu Ikonen [EMAIL PROTECTED] wrote: Hi, I have a Visual Fortran application which exhibits problems related to concurrency and file buffer flushing when run under wine (it works under all versions of windows). The program does essentially this: opens a file writes to it closes it forks another program to read the file just written deletes the file in the original process Under wine, the forked program does not find the file just written. If I run the program under winedbg and set a breakpoint somewhere between writing and deletion, the buffers are flushed when the breakpoint is reached, and the program works as it does under windows. If you don't wait for the forked process to finish before deleting the file, then you have a bug called a race condition which apparently manifests in wine and not in Windows: you're relying on the forked process to open the file before it gets deleted. Either wait for the forked process to finish and then delete the file, or have the forked process delete the file. To my mind this would indicate that windows flushes all open buffers before forking a new process (the api call I see in wine debug output is CreateProcessW). Would it make sense to add flush-calls to the wine implementation as well? I tried to make the program work by adding calls to the Fortran subroutine FLUSH between closing and forking, but somewhat surprisingly, that didn't help. Doesn't closing a file automatically flush it? Teemu Damjan
Re: [Wine] www.winehq.com newsletter dead forever?
On 1/17/07, Kai Blin [EMAIL PROTECTED] wrote: I said this before (in IRC, I guess), but I think that WWN could be done with a load balancing scheme. Round robin seems to be fine for that. So, let's say we get 4 people to do it, then it's one issue per month and person. That would be doable. Any takers? I've not been able to actively contribute much over the past year and due to time and work constraints and could not do it every week but I think I could commit to once a month. I am happy to give it a shot the first week in February as I was going to take a few days off work then and would like to contribute something else back to winehq. -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
Re: [Wine] www.winehq.com newsletter dead forever?
On 1/18/07, Kai Blin [EMAIL PROTECTED] wrote: On Wednesday 17 January 2007 20:20, Brian Vincent wrote: I would love for someone to take it over, but I'm not sure that'll happen. I said this before (in IRC, I guess), but I think that WWN could be done with a load balancing scheme. Round robin seems to be fine for that. So, let's say we get 4 people to do it, then it's one issue per month and person. That would be doable. Any takers? If it's one per month, I'd like to help out. The problem is there's about 6 months of catching up to do :-). Kai Damjan
Re: user32: invalidate button area instead of painting immediatly
On 1/17/07, Clinton Stimpson [EMAIL PROTECTED] wrote: WM_SETFONT on a button should invalidate the area so the system can send a WM_PAINT event, instead of painting the button immediately. This is a partial fix for bug# 6006. The other part of the fix is for ShowWindow(button, SW_HIDE) to cause a WM_PAINT event on the button's parent to paint in the newly exposed region. Thanks, Clinton Stimpson ChangeLog: user32: invalidate button area instead of painting button immediately. Can you write a message test for this in dlls/user32/tests/msg.c to verify your fix? Thanks, James Hawkins
