On 09.10.2013 01:12, Matteo Bruni wrote:
Hi Rico,
2013/10/8 Rico Schüller :
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.
1. When an
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 :
---
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.
@@ -5068,6 +5009,9
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, "T
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 GetC
On 31.07.2013 00:14, Matteo Bruni wrote:
2013/7/30 Rico Schüller :
Hi Matteo,
please see the attached patch.
On 25.07.2013 16:13, Matteo Bruni wrote:
2013/7/24 Rico Schüller :
---
dlls/d3dx9_36/tests/shader.c | 308
+++
1 file changed, 308
On 01.08.2013 15:58, Bruno Jesus wrote:
On Thu, Aug 1, 2013 at 9:14 AM, Rico Schüller wrote:
---
dlls/d3dx9_36/effect.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
+if (!This->started)
+return D3D_OK;
+
+This->started = FALSE;
+
+return
Hi Matteo,
please see the attached patch.
On 25.07.2013 16:13, Matteo Bruni wrote:
2013/7/24 Rico Schüller :
---
dlls/d3dx9_36/tests/shader.c | 308
+++
1 file changed, 308 insertions(+)
This is okay, but as a followup can you add some tests with
Hi Matteo,
On 25.07.2013 16:12, Matteo Bruni wrote:
2013/7/24 Rico Schüller :
---
dlls/d3dx9_36/shader.c | 79
--
1 file changed, 77 insertions(+), 2 deletions(-)
So there was actually a logic (an insane one, but yeah...). Have you
found
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 this
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 D3
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
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
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
--- a
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", cou
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 */
+This
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:
http://de.wikipedia.org/wiki/ATI-Radeon-HD
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 don
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 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 fragm
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 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 bit
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 doe
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
IDirect
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
t
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 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 when the AppDB
and Bugz
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 al
se
Nozomi
*De :* Henri Verbeet
*À :* Rico Schüller
*Cc :* wine-devel@winehq.org; Nozomi Kodama
*Envoyé le :* Lundi 25 février 2013 0h08
*Objet :* Re: d3dx9: Avoid expensive computations
On 25 February 2013 10:24, Rico Schüller mailto:kgbric...@web.de>> wrote:
> I d
On 25.02.2013 11:08, Henri Verbeet wrote:
On 25 February 2013 10:24, Rico Schüller 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 assignments and it
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
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. No
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 change
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 M
On 10.01.2013 17:13, Matteo Bruni wrote:
2013/1/10 Rico Schüller :
---
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
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 2
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++)
+{
+s
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_o
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 = dwDa
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 wrote:
+static HRESULT WINAPI ID3DXFileImpl_QueryInterface(ID3DXFile *iface,
REFIID riid, void **ret_iface)
+{
+TRACE("(%p)->(%
On 24.10.2012 18:18, Dmitry Timoshkov wrote:
Rico Schüller 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 16:33, Dmitry Timoshkov wrote:
Christian Costa 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, &IID_IUnknown) ||
+
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: I'd
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
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 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_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?
+ID3DXFileDa
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 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 lit
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 th
On 21.10.2012 14:17, Henri Verbeet wrote:
2012/10/21 Rico Schüller :
---
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
makes it
is welcome.
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
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 y
On 16.10.2012 20:21, Henri Verbeet wrote:
On 16 October 2012 20:12, Christian Costa 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 happens with e.g. a dest
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 -131556728585661638158151798785793064960.00
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: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];
Em
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 commen
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 * sqrtf(D3DX_PI
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],
+ma
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 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 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
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 wrot
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
http://www.wineh
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 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 w
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 wit
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.0
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, D3DSXHEv
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 automatic
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 window
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 carefully
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);
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, temp
On 02.09.2012 23:46, Nozomi Kodama wrote:
For instance, D3DXSHAdd and D3DXSHDot accept order>D3DXSH_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 agre
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 > D3DXSH_M
On 28.08.2012 10:50, Henri Verbeet wrote:
On 28 August 2012 09:12, Rico Schüller 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 ow
On 28.08.2012 10:50, Henri Verbeet wrote:
On 28 August 2012 09:12, Rico Schüller 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 ow
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. If
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 highe
On 22.08.2012 12:23, Józef Kucia wrote:
On Tue, Aug 21, 2012 at 10:52 PM, gurketsky 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
specifically to Józef. I'm not sur
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
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
Am 09.07.2012 16:17, schrieb Matteo Bruni:
2012/7/8 Rico Schüller:
---
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 f
Am 05.06.2012 13:08, schrieb Matteo Bruni:
2012/6/5 Stefan Dösinger:
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 is not the
same as a fl
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; k++
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: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 bytesbytes returns D3DERR_INVALIDCALL.
However, the MS version does not act that way: If the parameter i
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 interfac
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
Am 05.01.2012 06:09, schrieb Henri Verbeet:
2012/1/5 Rico Schüller:
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
Am 04.01.2012 17:26, schrieb Henri Verbeet:
2012/1/5 Rico Schüller:
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,
http
Am 04.01.2012 13:23, schrieb Henri Verbeet:
2012/1/5 Rico Schüller:
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 normal handle
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 be
1 - 100 of 208 matches
Mail list logo
