On 09.10.2013 01:12, Matteo Bruni wrote:
Hi Rico,
2013/10/8 Rico Schüller kgbric...@web.de:
Hi,
this moves the object initialization into a separate function, so it could
be used for strings and resources. It also removes the STATE_TYPE as we
could distinguish the types at the object level
On 01.10.2013 00:06, Frédéric Delanoy wrote:
---
dlls/wldap32/init.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/dlls/wldap32/init.c b/dlls/wldap32/init.c
index b5aed58..54b5b24 100644
--- a/dlls/wldap32/init.c
+++ b/dlls/wldap32/init.c
@@ -113,13 +113,13 @@ oom:
On 25.09.2013 14:02, Matteo Bruni wrote:
2013/9/24 Rico Schüller kgbric...@web.de:
---
dlls/d3dx9_36/effect.c | 248
+++--
1 Datei geändert, 95 Zeilen hinzugefügt(+), 153 Zeilen entfernt(-)
I definitely like the direction this patch takes
On 31.07.2013 00:14, Matteo Bruni wrote:
2013/7/30 Rico Schüller kgbric...@web.de:
Hi Matteo,
please see the attached patch.
On 25.07.2013 16:13, Matteo Bruni wrote:
2013/7/24 Rico Schüller kgbric...@web.de:
---
dlls/d3dx9_36/tests/shader.c | 308
On 01.08.2013 17:25, Matteo Bruni wrote:
Instead of generating an entry for the struct with the correct
members, the compiler generates TWO entries for sbnf, one with all its
fields in D3DXRS_FLOAT4 and the other with D3DXRS_BOOL. Which, if I'm
reading this correctly, makes 0 sense.
Calling
On 02.08.2013 00:03, Christian Costa wrote:
+technique = (D3DXHANDLE)0xdeadbeef;
+hr = effect-lpVtbl-FindNextValidTechnique(effect, technique1,
technique);
+ok(hr == D3D_OK, FindNextValidTechnique failed, got %#x, expected %#x\n,
hr, D3D_OK);
+ok(technique == technique2,
On 01.08.2013 15:58, Bruno Jesus wrote:
On Thu, Aug 1, 2013 at 9:14 AM, Rico Schüller kgbric...@web.de wrote:
---
dlls/d3dx9_36/effect.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
+if (!This-started)
+return D3D_OK;
+
+This-started = FALSE
Hi Matteo,
please see the attached patch.
On 25.07.2013 16:13, Matteo Bruni wrote:
2013/7/24 Rico Schüller kgbric...@web.de:
---
dlls/d3dx9_36/tests/shader.c | 308
+++
1 file changed, 308 insertions(+)
This is okay, but as a followup can you add
Hi Matteo,
On 25.07.2013 16:12, Matteo Bruni wrote:
2013/7/24 Rico Schüller kgbric...@web.de:
---
dlls/d3dx9_36/shader.c | 79
--
1 file changed, 77 insertions(+), 2 deletions(-)
So there was actually a logic (an insane one, but yeah
Hi Michael,
there are several thinks you could check.
1. Could you get a wrong order on winxp/vista/7 by using the default
installation on a local FAT32 partition? Or does the order by accident
match? If this doesn't reproduce the issue, you may also try the ext2fs
driver for windows, as
On 23.07.2013 11:46, Rico Schüller wrote:
---
dlls/d3dx9_36/effect.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
These may not apply correctly. Sorry for the noise. I'll resend a new
version.
Cheers
Rico
Hi Roland,
I'm not exactly sure what your goal is... but there is a rule one patch
per mail only! There is likely no chance to get something like that
mixture committed.
You may have a look here:
http://wiki.winehq.org/SubmittingPatches
On 18.07.2013 01:23, Roland Haeder wrote:
+HRESULT
On 20.06.2013 21:25, Nozomi Kodama wrote:
+if (adjacency)
+{
+DWORD *buffer, size;
+ID3DXBuffer *temp;
+
+size = 3 * sphere-lpVtbl-GetNumFaces(sphere) * sizeof(DWORD);
+hr = D3DXCreateBuffer(size, temp);
+if (hr != D3D_OK)
+return hr;
+
On 12.06.2013 10:31, Christian Costa wrote:
2013/6/11 Rico Schüller kgbric...@web.de
On 11.06.2013 22:08, Christian Costa wrote:
Fixes bug 26598.
---
dlls/d3dx9_36/effect.c |4
dlls/d3dx9_36/tests/effect.c | 17 +
2 files changed, 21 insertions
On 11.06.2013 22:08, Christian Costa wrote:
+TRACE(byte_code = %p, semantics = %p, count = %p\n, byte_code,
semantics, count);
The rest of the file seems to use the trace without the =.
+ok(ret == D3D_OK, Failed with %#xn, ret);
+ok(count == 3, Got %u, expected 1\n, count);
On 11.06.2013 22:08, Christian Costa wrote:
Fixes bug 26598.
---
dlls/d3dx9_36/effect.c |4
dlls/d3dx9_36/tests/effect.c | 17 +
2 files changed, 21 insertions(+)
diff --git a/dlls/d3dx9_36/effect.c b/dlls/d3dx9_36/effect.c
index 1924c07..bab4560 100644
---
On 05.06.2013 08:48, Christian Costa wrote:
bone = This-bones[bone_num];
+/* Decrement refcounts of vertices previously influenced */
+for (i = 0; i bone-num_influences; i++)
+if (bone-vertices[i] This-num_vertices) /* Ignore out of range
value */
+
On 30.05.2013 23:51, Kyle Luna wrote:
+{HW_VENDOR_AMD,CARD_AMD_RADEON_HD4200M,ATI Mobility Radeon HD
4200, DRIVER_AMD_R600, 256 },
I think there are versions available which have only 128MB of graphics
memory, see:
On 05.05.2013 23:00, Nozomi Kodama wrote:
+FLOAT tmp1, tmp2;
+tmp1 = cosf(rotation);
+tmp2 = sinf(rotation);
As of it is really clear what's in those variables, we may name them
with a better name instead of tmp1/tmp2 ... but I'm fine with either
version.
Cheers
Rico
On 05.05.2013 23:01, Nozomi Kodama wrote:
+FLOAT xw, xx, xy, xz, yw, yy, yz, zw, zz;
I'm not very happy with the additional amount of variables...
Please have a look at the attached patches. I think something like the
first one (d3dx9: Apply rotationcenter only when a rotation is
On 25.04.2013 09:59, Henri Verbeet wrote:
-static HRESULT shader_arb_alloc(struct wined3d_device *device, const struct
fragment_pipeline *fragment_pipe)
+static HRESULT shader_arb_alloc(struct wined3d_device *device, const struct
wined3d_vertex_pipe_ops *vertex_pipe,
+const struct
On 20.04.2013 20:49, Nozomi Kodama wrote:
These bunch of define are pretty ugly anyway. I prefer a pretty duplicated code
rather than these tons of defines.
Define should be avoided as much as possible.
Well, the only thing why I proposed something like this, was to reduce
the code size a
On 22.04.2013 23:08, Christian Costa wrote:
+typedef struct {
+DWORD bc2Size;
+DWORD bc2Width;
+DWORD bc2Height;
+WORD bc2Planes;
+WORD bc2BitCount;
+DWORD bc2Compression;
+DWORD bc2SizeImage;
+DWORD bc2XRes;
+DWORD bc2YRes;
+DWORD bc2ClrUsed;
+DWORD
On 15.04.2013 02:10, Nozomi Kodama wrote:
Hello
thanks for the review.
I don't think that calling defines is the way to go. Indeed, I tested my patch
and yours. Yours is about 12% slower than mine in my computer.
And now, we try to take care of efficiency of this dll. So, it is not the time
On 15.04.2013 10:24, Stefan Dösinger wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-04-14 16:53, schrieb Rico Schüller:
+if (iface-lpVtbl != (const IDirect3DBaseTexture8Vtbl
*)Direct3DTexture8_Vtbl + iface-lpVtbl != (const
IDirect3DBaseTexture8Vtbl
On 15.04.2013 13:50, Stefan Dösinger wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-04-15 10:53, schrieb Rico Schüller:
I'm not sure what GetTexture does, a test might show it (I'll have
a look). The problem might be, that we use some members, which
native probably doesn't do
On 13.04.2013 01:55, Nozomi Kodama wrote:
Is there a problem with this patch?
http://source.winehq.org/patches/data/9
Nozomi
Looks pretty much ok, but isn't there a way to reduce the size a bit?
Just see the dirty hack which is attached. D3DXSHMultiply6 will add a
lot of lines too...
On 08.04.2013 21:26, Rosanne DiMesio wrote:
On Mon, 8 Apr 2013 11:04:39 -0700
Austin English austinengl...@gmail.com wrote:
I've deleted the comment, but trying to delete the user from the admin page
just refreshes the page..
I think the ability for admins to delete users was taken away
On 05.04.2013 09:13, Nozomi Kodama wrote:
s = 0.75f;
-if ( order 2 )
-s += 5.0f / 16.0f;
-if ( order 4 )
-s -= 3.0f / 32.0f;
+if (order 2)
+s = 1.0625f;
+if (order 4)
+s = 0.96875f;
s /= D3DX_PI;
Doesn't the compiler do that
*De :* Henri Verbeet hverb...@gmail.com
*À :* Rico Schüller kgbric...@web.de
*Cc :* wine-devel@winehq.org; Nozomi Kodama nozomi.kod...@yahoo.com
*Envoyé le :* Lundi 25 février 2013 0h08
*Objet :* Re: d3dx9: Avoid expensive computations
On 25 February 2013 10:24, Rico Schüller
On 25.02.2013 06:03, Nozomi Kodama wrote:
+out.u.m[2][i] = v.z / signed_det;
+out.u.m[3][i] = v.w / signed_det;
}
*pout = out;
While you are at it, you may fix the indentation of out*, }, *pout =
out; and return pout;.
signed_det = (i % 2)? -det: det;
Couldn't you just
On 25.02.2013 11:08, Henri Verbeet wrote:
On 25 February 2013 10:24, Rico Schüller kgbric...@web.de wrote:
I did some small tests for speed with the following results. You may also
avoid such a lot of variable assignments like *pout = out and you may use 4
vecs instead. This should save ~48
On 15.02.2013 08:20, Nozomi Kodama wrote:
@@ -721,9 +739,10 @@ D3DXMATRIX* WINAPI D3DXMatrixTransformation(D3DXMATRIX
*pout, const D3DXVECTOR3
@@ -797,69 +821,70 @@ D3DXMATRIX* WINAPI D3DXMatrixTransformation2D(D3DXMATRIX
*pout, const D3DXVECTOR
Those two functions need a speed improvement.
Hi,
please don't apply this one, I somehow garbled the rebase ...
Cheers
Rico
On 23.01.2013 12:24, Rico Schüller wrote:
---
dlls/advapi32/registry.c | 18 +++---
dlls/advapi32/tests/registry.c | 54
--
2 files changed, 61
Hi,
is anyone able to get the wiki up again? Somehow the wiki
(http://wiki.winehq.org/) is not reachable from here.
Cheers
Rico
On 11.01.2013 09:40, Christian Costa wrote:
static HRESULT WINAPI ID3DXFileDataImpl_Unlock(ID3DXFileData *iface)
{
-FIXME((%p)-(): stub\n, iface);
+TRACE((%p)-()\n, iface);
-return E_NOTIMPL;
+/* Nothing to do */
+
+return S_OK;
}
Hi Christian,
I stumble over MSDN,
Hi,
please don't apply this patch. There are several other occurrences in
the same file. I'll send an improved version.
Cheers
Rico
On 10.01.2013 13:55, Rico Schüller wrote:
Hi,
this patch removes useless shifts, which may result in wrong data when
the shift is bigger than 24.
Cheers
On 10.01.2013 17:13, Matteo Bruni wrote:
2013/1/10 Rico Schüller kgbric...@web.de:
---
dlls/d3dx9_36/texture.c | 6 +++---
1 Datei geändert, 3 Zeilen hinzugefügt(+), 3 Zeilen entfernt(-
-DWORD i, v;
+DWORD i, v, mask32 = format-bits[c] == 32 ? -1 : ((1
format-bits[c]) - 1
On 05.12.2012 09:07, Nozomi Kodama wrote:
Hello
any problems with the patches
http://source.winehq.org/patches/data/91986
http://source.winehq.org/patches/data/91985
http://source.winehq.org/patches/data/91984
Best regards,
Nozomi
91985/6:
+for (i = 0; i order; i++)
+{
+
On 03.12.2012 23:11, Stefan Dösinger wrote:
+DWORD pool = buffer-Caps D3DVBCAPS_SYSTEMMEMORY ?
WINED3D_POOL_SYSTEM_MEM : WINED3D_POOL_DEFAULT;
...
+return wined3d_buffer_create_vb(buffer-ddraw-wined3d_device,
+buffer-size, usage, pool, buffer, ddraw_null_wined3d_parent_ops,
+
On 28.10.2012 16:13, André Hentschel wrote:
- lpGData-lpRemoteData = lpNewData;
+ lpGData-lpRemoteData = HeapAlloc( GetProcessHeap(), HEAP_ZERO_MEMORY,
sizeof( dwDataSize ) );
+ CopyMemory( lpGData-lpRemoteData, lpData, dwDataSize );
lpGData-dwRemoteDataSize =
On 24.10.2012 16:33, Dmitry Timoshkov wrote:
Christian Costa titan.co...@gmail.com wrote:
+static HRESULT WINAPI ID3DXFileImpl_QueryInterface(ID3DXFile *iface,
REFIID riid, void **ret_iface)
+{
+TRACE((%p)-(%s, %p)\n, iface, debugstr_guid(riid), ret_iface);
+
+if (IsEqualGUID(riid,
On 24.10.2012 18:18, Dmitry Timoshkov wrote:
Rico Schüller kgbric...@web.de wrote:
+if (!object)
+{
+ERR(Out of memory\n);
+return E_OUTOFMEMORY;
+}
The ERR() is useless here, just return E_OUTOFMEMORY in such situations.
It's done this way in many places
On 24.10.2012 19:39, Nikolay Sivov wrote:
On 10/24/2012 19:02, Rico Schüller wrote:
On 24.10.2012 16:33, Dmitry Timoshkov wrote:
Christian Costa titan.co...@gmail.com wrote:
+static HRESULT WINAPI ID3DXFileImpl_QueryInterface(ID3DXFile *iface,
REFIID riid, void **ret_iface)
+{
+TRACE
On 22.10.2012 23:57, Christian Costa wrote:
-static HRESULT WINAPI ID3DXFileDataImpl_GetType(ID3DXFileData *iface, GUID*
guid)
+static HRESULT WINAPI ID3DXFileDataImpl_GetType(ID3DXFileData *iface, GUID
*guid)
-ID3DXFileDataImpl* object;
+ID3DXFileDataImpl *object;
One minor thing:
On 19.10.2012 13:15, Nozomi Kodama wrote:
This patch adds tests for the patch sent by Rico for D3DXSHRotateZ.
Moreover, I changed const in CONST in the declaration of the function in
order to uniformize with the file.
+const FLOAT angle[] = ...
I'd prefer const because it is used a
On 22.10.2012 21:27, Christian Costa wrote:
+static HRESULT WINAPI ID3DXFileImpl_QueryInterface(ID3DXFile *iface, REFIID
riid, LPVOID *ret_iface)
+ID3DXFileImpl *This = impl_from_ID3DXFile(iface);
+ID3DXFileImpl* object;
Please be a bit more consistent across your patch... There are
On 22.10.2012 21:28, Christian Costa wrote:
+static HRESULT WINAPI ID3DXFileDataImpl_GetType(ID3DXFileData *iface, GUID*
guid)
Spacing. msdn says const GUID *pType see
http://msdn.microsoft.com/en-us/library/windows/desktop/bb205843%28v=vs.85%29.aspx.
Is it a bug in msdn?
+
On 22.10.2012 21:28, Christian Costa wrote:
} ID3DXFileImpl;
-
static inline ID3DXFileImpl *impl_from_ID3DXFile(ID3DXFile *iface)
It doesn't make much sense to add an empty line and remove it in the
next patch.
On 22.10.2012 21:28, Christian Costa wrote:
static HRESULT WINAPI ID3DXFileDataImpl_Unlock(ID3DXFileData *iface)
{
+
FIXME((%p)-(): stub\n, iface);
Why?
On 22.10.2012 22:55, Jacek Caban wrote:
On 10/22/12 10:13 PM, Rico Schüller wrote:
On 22.10.2012 21:27, Christian Costa wrote:
+static HRESULT WINAPI ID3DXFileImpl_QueryInterface(ID3DXFile *iface,
REFIID riid, LPVOID *ret_iface)
+ID3DXFileImpl *This = impl_from_ID3DXFile(iface
.
Cheers
Rico
On 20.10.2012 22:58, Christian Costa wrote:
Ok. I'll add it. Thanks!
Le 20/10/2012 21:35, Rico Schüller a écrit :
I think we also need a test to prove that return MapWindowPoints(
hwnd, 0, lppnt, 1 ) != 0; is wrong. I'd probably split the changes to
ScreenToClient/ClientToScreen
On 21.10.2012 14:17, Henri Verbeet wrote:
2012/10/21 Rico Schüller kgbric...@web.de:
---
We've generally been moving in the opposite direction for the D3D
tests, having each set of tests create its own device, window, etc.
instead. This makes the tests much more self-contained, which in turn
Why is there a static guid used in GetType? What happens if you query:
hr = IDirectXFileData_GetType(lpDirectXFileData, clsid_type);
hr = IDirectXFileData_GetType(lpDirectXFileData2, clsid_type2);
Are thy both containing the value to clsid_type2 then? Do clsid_type and
clsid_type2 match in that
I think we also need a test to prove that return MapWindowPoints( hwnd,
0, lppnt, 1 ) != 0; is wrong. I'd probably split the changes to
ScreenToClient/ClientToScreen and MapWindowPoints, because they are not
necessarily bound together.
What about something like:
wnd2 = CreateWindow(static,
On 18.10.2012 21:05, Daniel Santos wrote:
On 10/16/2012 01:12 PM, Christian Costa wrote:
+/* Choose point inside the client area */
+point.x = rect.right / 2 - 50;
+point.y = rect.bottom / 2 - 50;
+ret = ScreenToClient(wnd, point);
+ok(ret, ScreenToClient failed with %#x\n,
On 17.10.2012 08:35, Nozomi Kodama wrote:
My bad.
My patch pass the tests but not yours. Can you check these facts?
Nozomi
Oups, I didn't respect the order while setting the output values.
Splitting the loop and starting with the smallest index should make the
behavior exactly the same as
On 16.10.2012 20:21, Henri Verbeet wrote:
On 16 October 2012 20:12, Christian Costa titan.co...@gmail.com wrote:
+//SetWindowPos(wnd, NULL, 0, 0, rect.right / 2, rect.bottom / 2, 0);
C99 comment.
I don't think these are very interesting cases though, it's probably
more interesting what
On 10.10.2012 09:45, Nozomi Kodama wrote:
+CONST FLOAT coeff[]={
+out[7] -= (matrix-u.m[1][0] * matrix-u.m[0][2] + matrix-u.m[1][2] *
matrix-u.m[0][0]) * in[4];
+
+out[7] += (matrix-u.m[1][0] * matrix-u.m[2][2] + matrix-u.m[1][2] *
matrix-u.m[2][0]) * in[5];
Empty
On 10.10.2012 09:44, Nozomi Kodama wrote:
+if ( green_out )
Same as last time: I'd use if (x == y) without spaces on all
occurrences... there are a couple of them in the patch! Please make all
consistent in the patch.
On 10.10.2012 09:49, Nozomi Kodama wrote:
math.c:2994: Test failed: Red: case 9, order 7: expected[10] = 0.00,
received -134495294795062701298349336420239278080.00
math.c:2994: Test failed: Red: case 9, order 7: expected[15] = 0.00,
received
On 09.10.2012 09:49, Nozomi Kodama wrote:
+HRESULT WINAPI D3DXSHEvalHemisphereLight(UINT order, CONST D3DXVECTOR3 *dir,
D3DXCOLOR top, D3DXCOLOR bottom, FLOAT *rout, FLOAT *gout, FLOAT *bout)
The number of columns used for the code seems to be a little high again.
+if (j = 4
On 09.10.2012 09:49, Nozomi Kodama wrote:
+FLOAT temp[25];
+CONST FLOAT coeff[]={
+matrix-u.m[1][0] * matrix-u.m[0][0], matrix-u.m[1][1] *
matrix-u.m[0][1],
+matrix-u.m[1][1] * matrix-u.m[2][1], matrix-u.m[1][0] *
matrix-u.m[2][0],
+
On 09.10.2012 09:50, Nozomi Kodama wrote:
+static void CapIntegrale(FLOAT *out, FLOAT order, FLOAT angle)
+{
I'd use a lower case name.
+if (order == 5)
+return;
Indentation. If you break to a new line, please indent 8 spaces (in the
case for ok(...)).
+2.0f *
On 09.10.2012 09:50, Nozomi Kodama wrote:
+CONST FLOAT coeff[6] = {
+2.0f * sqrtf(D3DX_PI), 2.0f * sqrtf(D3DX_PI / 3.0f), 0.4f * sqrtf(5.0f
* D3DX_PI),
+2.0f * sqrtf(D3DX_PI / 7.0f), 2.0f / 3.0f * sqrtf(D3DX_PI), 2.0f *
sqrt (D3DX_PI / 11.0f) };
Pretty much the same
On 01.10.2012 03:27, Nozomi Kodama wrote:
I used FLOAT * WINAPI, though I don't like it.
Yeah, that's not much of an issue... and this is not the showstopper.
+TRACE((out %p, a %p, b %p)\n, out, a, b);
What I'm a bit curious about is, why do you reinvent a new style in a
new patch (see
On 01.10.2012 03:28, Nozomi Kodama wrote:
+for (order = 0; order = D3DXSH_MAXORDER + 1 ; order++)
Well, I'm not sure what you are doing with the spaces ...
I say it again, if you got a comment, read it carefully take a look at
your code and fix it. I mentioned white space issues a couple
On 27.09.2012 09:57, Nozomi Kodama wrote:
-FLOAT a[64], b[64], got;
+FLOAT a[49], b[49], got;
CONST FLOAT expected[] =
{ 0.5f, 0.5f, 25.0f, 262.5f, 1428.0f, 5362.0f, 15873.0f, 39812.0f,
88400.0f, };
-for (i = 0; i 64; i++)
+for (i = 0; i 49; i++)
-for (i = 0;
On 27.09.2012 09:56, Nozomi Kodama wrote:
+FLOAT* WINAPI D3DXSHMultiply4(FLOAT *out, CONST FLOAT *a, CONST FLOAT *b)
FLOAT * WINAPI D3DXSHMultiply4(FLOAT *out, const FLOAT *a, const FLOAT *b)
A minor nitpick, anyone against something like? I think that was what
Matteo meant in
Well I think, if you rework a series, please add something like try xyz
or so ... Also try to avoid to add / remove some patches, at least if
they actually don't have anything todo with the rest of the patch set
(if they could be submitted on their own).
On 27.09.2012 10:00, Nozomi Kodama
On 26.09.2012 12:17, Nozomi Kodama wrote:
+ta =0.28209479f * a[0]+ 0.14567312f * a[8]+ 0.12615663f * a[6];
+tb =0.28209479f * b[0]+ 0.14567312f * b[8]+ 0.12615663f * b[6];
+out[13] += ta * b[13] + tb * a[13];
+t = a[13] * b[13];
+out[0] +=0.28209479f *t;
Please use spaces
On 26.09.2012 19:09, Nozomi Kodama wrote:
+D3DXSHMultiply4(c, a, b);
What happens if you use something like D3DXSHMultiply4(c, c, c). Is
that allowed?
Tests in native show that D3DXSHMultiply gives what I implemented.
We can not reuse a input variable as output (we don't obtain what we
On 17.09.2012 00:33, Nozomi Kodama wrote:
+{ { rout, gout, bout, table, (table[90]), (table[180]), 1.01f, 1.02f,
1.03f, },
...
+ { rout, bout, gout, table, (table[90]), (table[180]), 1.01f, 1.02f,
1.03f, },
+ { bout, rout, gout, table, (table[90]), (table[180]), 1.01f, 1.02f,
On 14.09.2012 11:07, Nozomi Kodama wrote:
Hello
one remark about this patch.
Test in real windows shows that D3DXSHEvalDirectionalLight accepts order
D3DXSH_MAXORDER or order D3DXSH_MINORDER.
But in these cases, the colour outputs are unpredictable. For the same
calling arguments,
On 05.09.2012 08:02, Nozomi Kodama wrote:
+out[15] = -0.9682458639f * in[13] + 0.25f * in[15]; !
You didn't find all trailing white spaces. I made a !, so it could be
seen. You could easily get around that by changing your editors
preference. Most editors are able to remove that
On 03.09.2012 20:59, Nozomi Kodama wrote:
Thanks Rico and Henri for your help.
Nozomi
The patch looks much better now. But I have some minor things which I
didn't mention last time...
+ok(received_ptr == out, order %u, Expected %p, received
%p\n, order, out, received_ptr);
On 04.09.2012 13:19, Nozomi Kodama wrote:
+FLOAT expected, in[100], out[100],
...
+for (i = 0; i 49; i++)
+in[i] = i + 1.01f;
I guess this belongs together.
I'd like to make some suggestions, please don't take it personally.
When you got a comment on a patch, read it
On 04.09.2012 19:31, Nozomi Kodama wrote:
Your mail makes me thing two or three remarks.
I agree that in the plain wine, code must be optimized to use less
memory as possible and to be the fastest as possible.
But, the tests are here to check that the implemented function behaves
like the
On 02.09.2012 23:46, Nozomi Kodama wrote:
For instance, D3DXSHAdd and D3DXSHDot accept orderD3DXSH_MAXORDER. So
we must check whether it is acceptable for other D3DXSH functions to
give such an order. If it is not acceptable, then we must know what the
function returns.
Yes, they do and I
I had another look and like to give some suggestion.
On 02.09.2012 22:28, Nozomi Kodama wrote:
+sinb = sqrt( 1.0f - matrix-u.m[2][2] * matrix-u.m[2][2] );
I'd prefer to declare the variables as locally as possible.
+D3DXSHRotateZ(temp5, order, alpha, temp4);
+memcpy(out,
On 02.09.2012 22:28, Nozomi Kodama wrote:
+for (order = 0; order 10; order++)
Is there a reason why we'd want to test til 9? D3DXSH_MAXORDER is 6, so
7 Should be enough? I know the other test do this, but technically I see
no reason for that. Specifically the if (.. order
On 28.08.2012 10:50, Henri Verbeet wrote:
On 28 August 2012 09:12, Rico Schüller kgbric...@web.de wrote:
3. The wine_todo should be fixed in the test. Is there a way to disable them
to show up, when running e.g. wine d3dx9_36_test.exe.so shader? It's a bit
annoying when you search for your own
On 23.08.2012 22:58, Rico Schüller wrote:
On 23.08.2012 15:43, Józef Kucia wrote:
I would prefer you to clean it up submit it. I hope it gets committed
this time.
Ok, I'll try to clean them and send them. I will do it the safe way and
compare each handle with all handles we have
On 28.08.2012 10:50, Henri Verbeet wrote:
On 28 August 2012 09:12, Rico Schüller kgbric...@web.de wrote:
3. The wine_todo should be fixed in the test. Is there a way to disable them
to show up, when running e.g. wine d3dx9_36_test.exe.so shader? It's a bit
annoying when you search for your own
On 23.08.2012 15:43, Józef Kucia wrote:
I would prefer you to clean it up submit it. I hope it gets committed
this time.
Ok, I'll try to clean them and send them. I will do it the safe way and
compare each handle with all handles we have. If it is slow, we could
easily move by using the
On 22.08.2012 12:23, Józef Kucia wrote:
On Tue, Aug 21, 2012 at 10:52 PM, gurketsky gurket...@googlemail.com
mailto:gurket...@googlemail.com wrote:
I just like to present the state of the ID3DXConstantTable
implementation, so that possibly no work is done twice. This goes
On 20.08.2012 17:10, Józef Kucia wrote:
@@ -665,6 +666,31 @@ static void test_setting_basic_table(IDirect3DDevice9
*device)
out[8], out[9], out[10], out[11],
out[12], out[13], out[14], out[15]);
+ID3DXConstantTable_SetFloat(ctable, device, mvp, f);
+ok(res
On 20.08.2012 17:10, Józef Kucia wrote:
+if (desc.Class == D3DXPC_MATRIX_ROWS || desc.Class ==
D3DXPC_MATRIX_COLUMNS)
+{
...
+}
+else if (desc.Class == D3DXPC_SCALAR)
Could you also set D3DXPC_VECTOR variables with this call? It should be
easy to add a test for a scalar and
Am 09.07.2012 16:17, schrieb Matteo Bruni:
2012/7/8 Rico Schüllerkgbric...@web.de:
---
dlls/d3dx9_36/tests/effect.c | 90
++
1 files changed, 90 insertions(+), 0 deletions(-)
Hi Rico,
maybe it's just me misunderstanding this, but:
+FLOAT
Am 05.06.2012 13:08, schrieb Matteo Bruni:
2012/6/5 Stefan Dösingerstefandoesin...@gmx.at:
Am Montag, 4. Juni 2012, 17:58:24 schrieb Matteo Bruni:
+struct hlsl_type
+{
...
+unsigned int dimx;
+unsigned int dimy;
...
+};
One thing I noticed when I wrote my compiler was that a float1x1
Am 20.04.2012 16:20, schrieb David Adam:
+if (adjacency)
I'm not sure that this is correct, but why is adjacency not touched?
What should be returned for adjacency, maybe a test will show it? I
guess the temp ID3DXBuffer should be returned instead of leaked when all
is successful...
Am 01.04.2012 04:33, schrieb David Adam:
+ * Order is not limited by D3DXSH_MINORDER and D3DXSH_MAXORDER!
+ * All values will work, test from 0-7 [D3DXSH_MINORDER = 2,
D3DXSH_MAXORDER = 6]
+ * Exceptions will show up when out, in1 or in2 are NULL
+ */
+for (k = 0; k 8;
Am 07.02.2012 06:02, schrieb Luis Carlos Busquets Pérez:
1. If the functions returns E_FAIL for a sample then
test_effect.c:1917: Test failed: Got result 80004005, expected 0 (D3D_OK)
I'll have a look at those.
2. For D3DXPT_VERTEXSHADER and D3DXPT_PIXELSHADER replying with E_FAIL
avoids
Am 06.02.2012 18:23, schrieb Luis Carlos Busquets Pérez:
The functin returns D3DERR_INVALIDCALL whenever it is tried on a
parameter with elements. A check should be included.
Why do you think this is the case? How did you test this? I think it's
not possible to query the ID3DXBaseEffect
Am 06.02.2012 18:18, schrieb Luis Carlos Busquets Pérez:
The current implementation includes a check on param-bytes= bytes
specifically:
if (data param-bytes= bytes)
{
...
}
So if bytesparam-bytes returns D3DERR_INVALIDCALL.
However, the MS version does not act that way: If the parameter
Please ignore this patch, it seems to break make crosstest.
Cheers
Rico
Am 30.01.2012 09:00, schrieb Rico Schüller:
Hi,
this is try 2 for fixing the build for d3dx9_36 without requiring to
make all includes.
Improvements:
- don't use a generic rule, use a file specific one
Cheers
Rico
Am 04.01.2012 17:26, schrieb Henri Verbeet:
2012/1/5 Rico Schüllerkgbric...@web.de:
I'm not sure what you mean by a normal handle table.
Do you mean a list?
It's pretty much just a table of handles. There are a couple of
different variants spread over the Wine source. For example,
Am 05.01.2012 06:09, schrieb Henri Verbeet:
2012/1/5 Rico Schüllerkgbric...@web.de:
char *name=test; address may be: name - 0x80484c4
Now what happens if the address is equal the index of another variable?
You're not really supposed to have string pointers in the first MB or
so of your
Hi,
I'd like to get up the discussion for the D3DXHANLE in the
ID3DXConstantTable again. There were several tries in the past, but
there wasn't made a decision for one solution.
My opinion about the handles is, that they have to allow at least the
following options:
1. D3DXHANDLEs have to
Am 04.01.2012 13:23, schrieb Henri Verbeet:
2012/1/5 Rico Schüllerkgbric...@web.de:
Ideally we may handle all D3DXHANDLEs the same way. Some possible solutions
are listed in [3].
Any thoughts which way is preferred?
It's not entirely clear to me from any of those links why simply using
a
1 - 100 of 205 matches
Mail list logo
