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
n the "value" of the if statement directly instead
of returning TRUE / FALSE.
Cheers
Rico
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
ted %#x\n", hr,
S_FALSE);
Looks fine to me, but I found one minor issue. I'd write
"FindNextValidTechnique failed, ..." as in the line above.
Cheers
Rico
just
reading the code. ;-)
I've attached a new test with a shader binary without optimization. The
results are the same, only the register usage changed (and the shader size).
Cheers
Rico
I see. Not sure how much that actually matters, since setting the bool
field via the constant table wouldn&
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
think, changing the Find* functions is bad, as there will most likely
an app which depends on the order of the file creation date on FAT32
partitions...
It may be worth a try to report it as a bug to the game support, but try
to be as close to the system requirements as possible.
Cheers
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
atch which by accident works, is not
something which should be applied at all. There are several issues alone
in that line.
Cheers
Rico
3DXBuffer in the error case.
Cheers
Rico
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
_errors)
+*compilation_errors = NULL;
+
No, this is wrong! Your test case doesn't cover all cases.
Cheers
Rico
does D3DXGetShaderInputSemantics(semantics_vs11, NULL, NULL); and
D3DXGetShaderInputSemantics(NULL, NULL, NULL); return? Well both are
corner cases without much meaning.
You may check for the semantics where the count is NULL like
D3DXGetShaderInputSemantics(semantics_vs11, semantics, NULL);
Cheers
Rico
}
Please have a look at the code style (brackets {} at the for loops?). It
should be a bit more consistent. Also I think an increment (as said in
the comment) is something like
"This->vertices_refcounts[bone->vertices[i]]++;".
Maybe you could add a test to verify if the comment or the code is correct?
Cheers
Rico
ATI-Radeon-HD-4000-Serie (de)
http://www.notebookcheck.com/ATI-Radeon-HD-4200.20492.0.html (de)
I couldn't find this information on the English pages. I'm not sure how
much we care about this.
Cheers
Rico
70 - 79).
3. We could also avoid the temps by reordering the calculation (Doing
rotationcenter before the scaling). This way the tempxx could be avoided
by using the out matrix directly.
Cheers
Rico
commit 46c6ed6d9a6950d733652072774e7b01c0277584
Author: Rico Schüller
Date: Mon May 6 10:4
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
else if (header_size == sizeof(BITMAPCOREHEADER))
+{
+BITMAPCOREHEADER*header = (BITMAPCOREHEADER*)*data;
I don't think it's a good idea to use variable names multiple times.
While this works fine it may be a bit confusing...
Cheers
Rico
bit. As it looks like, the same constants and the same
steps are used multiple times. This doesn't have to be defines, static
inline functions would also do the job. I'm fine with either solution
(this includes your solution), it was only a suggestion. :-)
Cheers
Rico
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
e, because they change a lot of
code mostly using copy and paste. Though I vote for the same style and
precision usage in all cases.
Hope this helps a bit
Rico
I used 10 digits since there are a lot of computation, I want to avoid as much
as possible big rounding errors. If we want to uniformiz
s too...
Also is there a reason why we use constants with different accuracy
(e.g. 0.28209479f in D3DXSHMultiply4 and 0.2820948064f)?
Cheers
Rico
commit 5939b27e87acbd1cac30faa975e4c3d246ff5f9d
Author: Rico Schüller
Date: Sun Apr 14 16:49:16 2013 +0200
d3dx9
diff --git a/dlls/d3dx9_36/mat
and Bugzilla were hacked.
There is an open bug for the lack of spam controls in the AppDB:
http://bugs.winehq.org/show_bug.cgi?id=31973.
It's a hassle to delete these stuff, couldn't we do something similar as
done in the forum and moderate each post?
Cheers
Rico
compiler do that already? If not something like this would
probably better:
s = 0.23873...f; /* 0.75f / D3DX_PI */
if (order > 2)
s = 1.0625f / D3DX_PI;
if (order > 4)
s = 0.96875f / D3DX_PI;
Cheers
Rico
, one for D3DXMatrixDeterminant
and one for D3DXMatrixInverse. I think it's a nice step forward. Thought
we might test the speed of an sse version and may use it later ...
Are there any other opinions?
Cheers
Rico
On 25.02.2013 12:34, Nozomi Kodama wrote:
Rico,
can you give a try to
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
= v.z / det;
pout->u.m[3][i] = v.w / det;
det = -det;
}
return pout;
Maybe we could reuse some calculations from the D3DXVec4Cross function ...
Cheers
Rico
;
-TRACE("iface %p\n", iface);
+TRACE("iface %p, %pm\n", iface, pm);
Typo.
+TRACE("iface %p, x %f, y %f, z %f\n", iface, x, y, z);
+TRACE("(pout %p, pvpoint %p, pvnormal %p)\n", pout, pvpoint, pvnormal);
Well, I would use the same style for both... I'd prefer the first one.
Cheers
Rico
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
lock function but in the header it's a HRESULT... Is msdn wrong here?
Cheers
Rico
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
ptr
ptr) d3dx9_36.D3DXSHEvalSphericalLight
->
@ stdcall D3DXSHEvalSphericalLight(long ptr float float float float ptr
ptr ptr) d3dx9_36.D3DXSHEvalSphericalLight
Cheers
Rico
ge, pool, buffer, &ddraw_null_wined3d_parent_ops,
+wined3d_buffer);
Is there a reason why you don't use "enum wined3d_pool" for pool?
Cheers
Rico
Is the HEAP_ZERO_MEMORY really needed? You may kill that too while you
change those lines.
Cheers
Rico
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
use the
system is not able to hand out the needed memory. Just do a git grep.
There are ~400 usages for ERR and out of memory... What's your
suggestion how to do that with the "Out of memory"?
Cheers
Rico
: I'd put that fixes in patch 4/5. It doesn't make much
sense to add a line and change the style in the next patch from the same
series. I think it's better to correct this when it is added in the
first place.
Cheers
Rico
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" be
All machines (http://test.winehq.org/data/tests/d3dxof:d3dxof.html) seem
to run 107 tests or skip all of them, which is the same on my machine (I
got 107 tests), so none of them is running the whole test_dump ... How
is this supposed to work?
Cheers
Rico
On 21.10.2012 14:50, Christian Costa w
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
anging from left-to-right layout to
right-to-left layout. Instead, use MapWindowPoints. For more
information, see "Window Layout and Mirroring" in Window Features." We
may also check that case. So they may not share the exact same steps.
Cheers
Rico
On 20.10.2012 12:27, Chris
int to make a nice
test. Nevertheless attached is my latest version of the test and
implementation, but be warned, it is still not ready to be send to
wine-patches.
If I remember correctly, lotro doesn't need the Get/SetLastError part,
but I added it anyway. It may be split out and added in
worth the effort.
Cheers
Rico
diff --git a/dlls/d3dx9_36/math.c b/dlls/d3dx9_36/math.c
index 220ac31..1190226 100644
--- a/dlls/d3dx9_36/math.c
+++ b/dlls/d3dx9_36/math.c
@@ -3010,68 +3010,44 @@ FLOAT* WINAPI D3DXSHRotate(FLOAT *out, UINT order, CONST D3DXMATRIX *matrix, CON
FLOAT * WINAPI D3DX
0 */
if (!hwnd || !lppnt) return FALSE;
return MapWindowPoints( 0, hwnd, lppnt, 1 ) != 0;
}
If I remember correctly, the game passes some NULL hwnd and invalid hwnd in.
Cheers
Rico
ConeLight patch. Does the
compiler optimize the function call away to a constant value? If not it
may be better to use something like 1.7724538509f for sqrtf(pi)...
Cheers
Rico
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
comments as for D3DXSHEvalConeLight apply here too.
Beside that, does it make sens to define the coeffs with a better name
as static and reuse them? They seem to be the same for both usages.
Cheers
Rico
j] * scale;
rout[i * i + j] = temp * Rintensity;
if (gout) gout[i * i + j] = temp * Gintensity;
if (bout) bout[i * i + j] = temp * Bintensity;
}
}
Cheers
Rico
so work, but I'm not sure for
cases where in = out, if it's working, we don't need the temp at all, it
may be needed to reorder the calculation in that case to start with the
index needed in the result ... out[5] = y * in[5]; out[5] += x * in[4];
out[5] += z * in[6]; ...).
Cheers
Rico
= 4 && j < order * order)
+expected = 0.0f;
+else if ( j >= order * order )
I'd use "if (x == y)" without spaces on all occurrences... there are a
couple of them in the patch.
Cheers
Rico
a couple of times.
And I think I mentioned the problem already ... I accidentally send it
to wine-patches instead of wine-devel (sorry, this was my mistake):
http://www.winehq.org/pipermail/wine-patches/2012-September/118230.html.
Cheers
Rico
E("out %p, a %p, b %p\n", out, a, b);"
And the one also used in the file is:
"TRACE("(%p, %p, %p)\n", out, a, b);"
Please use exactly one of those. Not mixture, no extra brackets...
Sorry, I should have written an answer to the (try 3), but I wasn't fast
enough.
Cheers
Rico
~2000
while git grep "if ( " dlls/d3dx9_36/* | wc -l does ~100
> +ok(relative_error(expected, blue_out[j]) <
admitted_error,
> + "Blue: case %u, order %u: expected[%u] = %f,
received %f \n", l, order, j, expected, blue_out[j]);
Please indent 8 instead of 2 spaces when a new line is used ...
Cheers
Rico
out[0] = 0.28209479f * a[0] * b[0];
There are still double spaces ... Hint: it's not the only occurrence.
Cheers
Rico
for (i = 0; i < 9; i++)
+for (i = 0; i <= D3DXSH_MAXORDER + 1; i++)
Again: You may correct the (array) size for the expected value ...
If we run til element 7 instead of 8, I think the last element could be
thrown away?
Cheers
Rico
t I can
simplify slightly the function by calling D3DXSHMultiply3.
Ok, no problem. See above. I'd say compatibility before simplicity. It
was just a thought, because there was no test / comment in the code that
makes my suggestion a stupid idea, but the test above makes this idea
obsolete.
Cheers
Rico
To
me it looks like they do share a lot of calculations, And if the order
doesn't matter (see comment above) then it may be possible to rearrange
the calculation.
ta = 0.28209479f * a[0] - 0.12615663f * a[6] - 0.21850969f * a[8];
vs
ta = 0.28209479f * a[0] - 0.12615662f * a[6] - 0.21850968f * a[8];
Cheers
Rico
onger lines into two. Though, I don't know the actual recommended
line length, but 200 seems a bit long... I only found this
http://www.winehq.org/pipermail/wine-devel/2010-September/086996.html .
Cheers
Rico
f, 2.6f, 3.5f, rout, rout, rout);
Well the implementation seems to be correct, but it may be nice to test
for this as well. Maybe in another patch.
Cheers
Rico
se ask - before sending
another try, sometimes the hints could be wrong and sometimes they are
worth to think about it.
That's all I have to say, there won't be any more comments from my side
to this patch. I need my time to get my own screwed up patches into
wine. :-)
Cheers
Rico
Why do
we need to produce more bad examples, if it is relatively easy to write
clean code?
Cheers
Rico
27;t annoyed you and we'll see some good quality patches
in the feature from you. :-)
Cheers
Rico
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, ou
and reuse the returned
pointer. You also may use "BOOL pm" since it uses only 0 and 1 or you
may pass the "FLOAT a" directly to the function. Whatever pm stands for...
Cheers
Rico
it in the else case. You may get an unhandled exception
and this is not what the software should do in the first place, it
should run and not produce exceptions! :-)
The same is done in test_D3DXSHRotateZ, which I'm not happy about it.
Cheers
Rico
.. order > D3DXSH_MAXORDER)
says exactly that, so no need to further than 7, since the parameters or
did I miss something?
I guess you'd also out of bounds?
table[36 * j + i]; (for j=3 and i=99 => 207) since the table only has
4*36 => 144 elements.
Cheers
Rico
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
g the highest bit for comparison against the
D3DXHANDLE. We just have to take care that an easy switch is possible.
Thanks for the input.
Rico
he lowest 2gb. But my tests showed,
that I always get the lower 31bit of addresses in my test runs when
allocating memory. Thus I'm very unlucky by not getting a higher address
or this might be the way it works on windows. Has anyone a technical
argument against this solution?
I hope this helps you to make the correct decisions.
Cheers
Rico
quot;,
matrix_pointer, 1);
ID3DXConstantTable_SetMatrixPointerArray(ctable, device, "vec3",
matrix_pointer, 1);
ID3DXConstantTable_SetMatrixPointerArray(ctable, device, "scalar",
matrix_pointer, 1);
Cheers
Rico
quot;f4", f);
+ok(res == D3D_OK, "ID3DXConstantTable_SetFloat failed on variable f4:
0x%08x\n", res);
Cheers
Rico
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
fa69a359fb6b517:/dlls/d3dx9_36/tests/effect.c#l1191
. A test may help to check how variables in shaders are handled.
Cheers
Rico
ssful...
Cheers
Rico
; k++)
Where is the variable out?
Cheers
Rico
fect files, which I could confirm.
Do you mean, that the HeapAlloc for the additional pointer for textures
should be avoided? This could be done, it just needs separate handling
for textures. As it is now, it mostly uses the same handling together
with the shaders (e.g. IUnknown_Release(*(IUnknown **)param->data)).
Cheers
Rico
ww.winehq.org/pipermail/wine-devel/2011-December/093489.html)
but not the if and the memcopy. :-) Well, I've overseen this. Feel free
to send a patch, otherwise I'll do that tomorrow.
Cheers
Rico
L is returned? Maybe on e.g. D3DXPT_PIXELSHADER, which
isn't implemented in wine, yet?
Cheers
Rico
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
lly we may handle all D3DXHANDLEs the same way. Some possible
solutions are listed in [3].
Any thoughts which way is preferred?
Cheers
Rico
References:
[1] http://www.winehq.org/pipermail/wine-devel/2010-April/082900.html
[2] http://www.winehq.org/pipermail/wine-patches/2011-July/104325.htm
1 - 100 of 211 matches
Mail list logo
