Re: [3/8] msi: Handle escaped double quotes in command line parsing.
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=12111
Your paranoid android.
=== WNT4WSSP6 (32 bit install) ===
install.c:5979: Test failed: Per-user icon file isn't where it's expected
(C:\WINNT\Profiles\Default User\Application
Data\Microsoft\Installer\{7DF88A49-996F-4EC8-A022-BF956F9B2CBB}\testicon)
=== W7PRO (32 bit install) ===
Timeout
Re: [PATCH 1/3] d3dx9/line: Implemented ID3DXLine's Draw method.
2011/6/30 Charles Welton charles...@gmail.com: --- +memcpy(buffer_mem, vertices, size); There is no need to allocate and write into your own buffer then copy the content, you can directly write into the vertex buffer. A more important issue: MSDN says The ID3DXLine interface implements line drawing using textured triangles, which is probably true (as far as I know there is otherwise no support in D3D9 to antialiased/stippled/wide lines, which are instead supported by ID3DXLine). So, drawing with D3DPT_LINESTRIP primitives in general is probably not the right way...
Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9
I've implemented ConvertPointRepsToAdjacency, but would like some help
to make it's worst case performance bearable.
In init_edge_face_map I initialize an array of edge_face structs, and
in find_adjacent_face I do a linear search through that array. I would
like to replace the array with a hash table, so that the search time
becomes constant. I've found a standard list (wine/list.h) and
red-black tree implementation (wine/rbtree.h), but not a standard hash
table implementation. Is there a standard hash table implementation,
should I roll my own or find an LGPL'ed one?
Thanks,
Michael Mc Donnell
From 549a95e2f8f218541d3f54afd08ee522e4e27e3e Mon Sep 17 00:00:00 2001
From: Michael Mc Donnell mich...@mcdonnell.dk
Date: Thu, 23 Jun 2011 17:46:51 +0200
Subject: d3dx9/test: Implemented ConvertPointRepsToAdjacency test.
---
dlls/d3dx9_36/tests/mesh.c | 452
1 files changed, 452 insertions(+), 0 deletions(-)
diff --git a/dlls/d3dx9_36/tests/mesh.c b/dlls/d3dx9_36/tests/mesh.c
index 98d77d9..1da6ed0 100644
--- a/dlls/d3dx9_36/tests/mesh.c
+++ b/dlls/d3dx9_36/tests/mesh.c
@@ -4904,6 +4904,457 @@ static void test_create_skin_info(void)
ok(hr == D3DERR_INVALIDCALL, Expected D3DERR_INVALIDCALL, got %#x\n, hr);
}
+static void test_convert_point_reps_to_adjacency(void)
+{
+HRESULT hr;
+struct test_context *test_context = NULL;
+const DWORD options = D3DXMESH_32BIT | D3DXMESH_SYSTEMMEM;
+const DWORD options_16bit = D3DXMESH_SYSTEMMEM;
+const D3DVERTEXELEMENT9 declaration[] =
+{
+{0, 0, D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_POSITION, 0},
+{0, 12, D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_NORMAL, 0},
+{0, 24, D3DDECLTYPE_D3DCOLOR, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_COLOR, 0},
+D3DDECL_END()
+};
+const unsigned int VERTS_PER_FACE = 3;
+void *vertex_buffer;
+void *index_buffer;
+DWORD *attributes_buffer;
+int i, j;
+enum color { RED = 0x, GREEN = 0xff00ff00, BLUE = 0xffff};
+struct vertex_pnc
+{
+D3DXVECTOR3 position;
+D3DXVECTOR3 normal;
+enum color color; /* In case of manual visual inspection */
+};
+D3DXVECTOR3 up = {0.0f, 0.0f, 1.0f};
+/* mesh0 (one face)
+ *
+ * 0--1
+ * | /
+ * |/
+ * 2
+ */
+const struct vertex_pnc vertices0[] =
+{
+{{ 0.0f, 3.0f, 0.f}, up, RED},
+{{ 2.0f, 3.0f, 0.f}, up, GREEN},
+{{ 0.0f, 0.0f, 0.f}, up, BLUE},
+};
+const DWORD indices0[] = {0, 1, 2};
+const unsigned int num_vertices0 = ARRAY_SIZE(vertices0);
+const DWORD exp_adjacency0[] = {-1, -1, -1};
+const DWORD point_rep0[] = {0, 1, 2};
+/* mesh1 (right)
+ *
+ * 0--1 3
+ * | / /|
+ * |/ / |
+ * 2 5--4
+ */
+const struct vertex_pnc vertices1[] =
+{
+{{ 0.0f, 3.0f, 0.f}, up, RED},
+{{ 2.0f, 3.0f, 0.f}, up, GREEN},
+{{ 0.0f, 0.0f, 0.f}, up, BLUE},
+
+{{ 3.0f, 3.0f, 0.f}, up, GREEN},
+{{ 3.0f, 0.0f, 0.f}, up, RED},
+{{ 1.0f, 0.0f, 0.f}, up, BLUE},
+};
+const DWORD indices1[] = {0, 1, 2, 3, 4, 5};
+const unsigned int num_vertices1 = ARRAY_SIZE(vertices1);
+const DWORD exp_adjacency1[] = {-1, 1, -1, -1, -1, 0};
+const DWORD point_rep1[] = {0, 1, 2, 1, 4, 2};
+/* mesh2 (left)
+ *
+ *3 0--1
+ * /| | /
+ * / | |/
+ * 5--4 2
+ */
+const struct vertex_pnc vertices2[] =
+{
+{{ 0.0f, 3.0f, 0.f}, up, RED},
+{{ 2.0f, 3.0f, 0.f}, up, GREEN},
+{{ 0.0f, 0.0f, 0.f}, up, BLUE},
+
+{{-1.0f, 3.0f, 0.f}, up, RED},
+{{-1.0f, 0.0f, 0.f}, up, GREEN},
+{{-3.0f, 0.0f, 0.f}, up, BLUE},
+};
+const DWORD indices2[] = {0, 1, 2, 3, 4, 5};
+const unsigned int num_vertices2 = ARRAY_SIZE(vertices2);
+const DWORD exp_adjacency2[] = {-1, -1, 1, 0, -1, -1};
+const DWORD point_rep2[] = {0, 1, 2, 0, 2, 5};
+/* mesh3 (above)
+ *
+ *3
+ * /|
+ * / |
+ * 5--4
+ * 0--1
+ * | /
+ * |/
+ * 2
+ */
+struct vertex_pnc vertices3[] =
+{
+{{ 0.0f, 3.0f, 0.f}, up, RED},
+{{ 2.0f, 3.0f, 0.f}, up, GREEN},
+{{ 0.0f, 0.0f, 0.f}, up, BLUE},
+
+{{ 2.0f, 7.0f, 0.f}, up, BLUE},
+{{ 2.0f, 4.0f, 0.f}, up, GREEN},
+{{ 0.0f, 4.0f, 0.f}, up, RED},
+};
+const DWORD indices3[] = {0, 1, 2, 3, 4, 5};
+const unsigned int num_vertices3 = ARRAY_SIZE(vertices3);
+const DWORD exp_adjacency3[] = {1, -1, -1, -1, 0, -1};
+const DWORD point_rep3[] = {0, 1, 2, 3, 1, 0};
+/* mesh4 (below, tip against tip)
+ *
+ * 0--1
+ * | /
+ * |/
+ * 2
+ * 3
+ * |\
+ * | \
+ * 5--4
+ */
+struct vertex_pnc vertices4[] =
+{
+{{ 0.0f, 3.0f, 0.f}, up, RED},
+{{ 2.0f, 3.0f, 0.f}, up, GREEN},
+
Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9
On 30 June 2011 14:49, Michael Mc Donnell mich...@mcdonnell.dk wrote:
In init_edge_face_map I initialize an array of edge_face structs, and
in find_adjacent_face I do a linear search through that array. I would
like to replace the array with a hash table, so that the search time
becomes constant. I've found a standard list (wine/list.h) and
red-black tree implementation (wine/rbtree.h), but not a standard hash
table implementation. Is there a standard hash table implementation,
should I roll my own or find an LGPL'ed one?
I'm not sure if a hash table would be faster and how much, but an easy
way to make the lookup cheaper would be to store the edge - face map
as a list for each vertex.
So e.g. if you have these faces:
f0: v0, v2, v1
f1: v1, v4, v3
f2: v1, v2, v4
f3: v2, v5, v4
You'd build these lists:
v0: {v2:f0}
v1: {v0:f0}, {v4:f1}, {v2:f2}
v2: {v1:f0}, {v4:f2}, {v5:f3}
v3: {v1:f1}
v4: {v3:f1}, {v1:f2}, {v2:f3}
v5: {v4:f3}
It's then mostly trivial to determine adjacency. This assumes most
vertices are only part of a handful of edges, but I don't think that's
unreasonable in practice.
We did have a hash table inside wined3d at some point, I suppose you
could also try resurrecting that from git history.
Re: GSoC: dinput8 Action Mapping
On Thu, Jun 30, 2011 at 02:56:08AM -0300, Lucas Zawacki wrote:
Hey guys, how are you doing? I've got some patches for you.
The first is a refactoring of the BuildActionMap implementations for
keyboard and mouse. I think with 'semantic_to_obj_id' the mapping is
pretty much correct for keyboard and mouse and it's being done the
right way.
The second patch is much like one I sent some time ago, it's
SetActionMap for keyboard and mouse, this time (hopefully) with the
dataformat stuff done right too. I've split it up in a third patch,
which implements the action mapping per se.
Anyway, tomorrow I'll code some mouse tests to be sure that this is working.
Cheers
From 37e5a1e6d51778ee0d5c0f3081dad8ca1431968f Mon Sep 17 00:00:00 2001
From: Lucas Fialho Zawacki lfzawa...@gmail.com
Date: Fri, 10 Jun 2011 21:43:53 -0300
Subject: dinput: Keyboard and mouse implementation of BuildActionMap (try 4)
+DWORD semantic_to_obj_id(IDirectInputDeviceImpl* This, DWORD dwSemantic)
+{
...
+if (!found) return 0;
So 0 is the not found case...
+DWORD obj_id = semantic_to_obj_id(This-base,
lpdiaf-rgoAction[i].dwSemantic);
+if (obj_id != -1)
But here you check for -1.
+DWORD obj_id = semantic_to_obj_id(This-base,
lpdiaf-rgoAction[i].dwSemantic);
+if (obj_id != -1)
and here. (both mouse and keyboard code)
should probably check for 0 there, also as DWORD is unsigned ;)
Ciao, Marcus
Re: wine bug 27600
Ok, try with a modified header: OK no problem, i will try later today. But i don't think it's a bug in applicability of those patches. I began with wine testing 2 years ago and did many regression tests, reverse reg.testing, found faulty commit even though it was covered by several other faulty commits etc. I think I can find a problem between patches quite well. I can't go under patch level aka go into lines of code and that's the helping hand i would need here, i.e. i know, that 3rd patch of your series makes troubles to me and i also know, that your one big merged and modified patch works for me. Unfortunately as i said, i can't search a regression between lines of code. And this is a place we should look in, i guess... Sure, i will try again your modified script later today and let you know. For the other guys, could i call for help?? Could you please try to apply the Vincas's 9 patch raw-input series to the current git, try to compile and let me know, if you succeed? I really would like to know if i'm the only one with such problem. Thank you all, W.
Re: wine bug 27600
On 06/30/2011 05:31 PM, wy...@volny.cz wrote: Ok, try with a modified header: OK no problem, i will try later today. But i don't think it's a bug in applicability of those patches. I began with wine testing 2 years ago and did many regression tests, reverse reg.testing, found faulty commit even though it was covered by several other faulty commits etc. I think I can find a problem between patches quite well. I can't go under patch level aka go into lines of code and that's the helping hand i would need here, i.e. i know, that 3rd patch of your series makes troubles to me and i also know, that your one big merged and modified patch works for me. Unfortunately as i said, i can't search a regression between lines of code. And this is a place we should look in, i guess... Sure, i will try again your modified script later today and let you know. For the other guys, could i call for help?? Could you please try to apply the Vincas's 9 patch raw-input series to the current git, try to compile and let me know, if you succeed? I really would like to know if i'm the only one with such problem. Thank you all, W. Well, I am almost certain what the problem is :) I think that you have a 32bit OS (well, the ./configure logs could tell me that). I and the WINE's testbot builder run 64bit OSes, the people from bug 20395 (also a person in #winehq) that compiled and ran the patch successfully most likely also run 64bit OSes, thus 64bit version of gcc by default. The issue is on i386, where a certain include-file combination that is used is hitting this expected declaration specifiers or ‘...’ bug for __ms_va_list. I wrote a small test-case patch, that should fail to compile using 32bit gcc - http://dl.dropbox.com/u/6901628/bug_test.patch If it fails, it's most likely a WINE bug and should be filed to bugzilla. As a solution to workaround that, I will add those unused include statements (as is a similar story with user.h) for it compile on i386; will submit once I've finished some new features. Thanks for discovering this :)
Re: wine bug 27600
2011/6/30 wy...@volny.cz: Ok, try with a modified header: OK no problem, i will try later today. But i don't think it's a bug in applicability of those patches. I began with wine testing 2 years ago and did many regression tests, reverse reg.testing, found faulty commit even though it was covered by several other faulty commits etc. I think I can find a problem between patches quite well. I can't go under patch level aka go into lines of code and that's the helping hand i would need here, i.e. i know, that 3rd patch of your series makes troubles to me and i also know, that your one big merged and modified patch works for me. Unfortunately as i said, i can't search a regression between lines of code. And this is a place we should look in, i guess... Sure, i will try again your modified script later today and let you know. For the other guys, could i call for help?? Could you please try to apply the Vincas's 9 patch raw-input series to the current git, try to compile and let me know, if you succeed? I really would like to know if i'm the only one with such problem. Thank you all, W. $ cd wine-git $ wget http://dl.dropbox.com/u/6901628/raw.patch $ patch -p1 raw.patch $ ./tools/make_requests $ ./configure $ make works here: austin@debian:~/wine-git$ cat /etc/issue Debian GNU/Linux wheezy/sid \n \l austin@debian:~/wine-git$ uname -a Linux debian 2.6.39-2-686-pae #1 SMP Wed Jun 8 11:33:14 UTC 2011 i686 GNU/Linux -- -Austin
Re: wine bug 27600
On Thu, Jun 30, 2011 at 4:52 PM, Austin English austinengl...@gmail.com wrote: 2011/6/30 wy...@volny.cz: Ok, try with a modified header: OK no problem, i will try later today. But i don't think it's a bug in applicability of those patches. I began with wine testing 2 years ago and did many regression tests, reverse reg.testing, found faulty commit even though it was covered by several other faulty commits etc. I think I can find a problem between patches quite well. I can't go under patch level aka go into lines of code and that's the helping hand i would need here, i.e. i know, that 3rd patch of your series makes troubles to me and i also know, that your one big merged and modified patch works for me. Unfortunately as i said, i can't search a regression between lines of code. And this is a place we should look in, i guess... Sure, i will try again your modified script later today and let you know. For the other guys, could i call for help?? Could you please try to apply the Vincas's 9 patch raw-input series to the current git, try to compile and let me know, if you succeed? I really would like to know if i'm the only one with such problem. Thank you all, W. $ cd wine-git $ wget http://dl.dropbox.com/u/6901628/raw.patch $ patch -p1 raw.patch $ ./tools/make_requests $ ./configure $ make works here: austin@debian:~/wine-git$ cat /etc/issue Debian GNU/Linux wheezy/sid \n \l austin@debian:~/wine-git$ uname -a Linux debian 2.6.39-2-686-pae #1 SMP Wed Jun 8 11:33:14 UTC 2011 i686 GNU/Linux -- -Austin Wylda already reported that this big patch worked, but the 9-patch series didn't. Can you try those?
Re: wine bug 27600
On 06/30/2011 05:57 PM, wy...@volny.cz wrote: $ cd wine-git $ wget http://dl.dropbox.com/u/6901628/raw.patch $ patch -p1 raw.patch $ ./tools/make_requests $ ./configure $ make works here: Thanks Austin for testing, but this raw.patch is already modified and works for me too. I would need to retest the series of nine individial patches ;) (thoses in wine-patches queue with status=New). But it looks like Vincas already know where the problem is :-) Regards, W. Austin just reported that I do not :) Another thing that would be helpful would be to get the exact modifications that are applied to the source tree (not only the patches but also the products of code generation from server/protocol.def). So with the non-compiling code, execute these commands: git add . git diff origin/master mod.patch Add send the mod.patch file, maybe that will reveal the secret.
Re: wine bug 27600
On 06/30/2011 06:07 PM, Vincas Miliūnas wrote: On 06/30/2011 05:57 PM, wy...@volny.cz wrote: $ cd wine-git $ wget http://dl.dropbox.com/u/6901628/raw.patch $ patch -p1 raw.patch $ ./tools/make_requests $ ./configure $ make works here: Thanks Austin for testing, but this raw.patch is already modified and works for me too. I would need to retest the series of nine individial patches ;) (thoses in wine-patches queue with status=New). But it looks like Vincas already know where the problem is :-) Regards, W. Austin just reported that I do not :) Another thing that would be helpful would be to get the exact modifications that are applied to the source tree (not only the patches but also the products of code generation from server/protocol.def). So with the non-compiling code, execute these commands: git add . git diff origin/master mod.patch Add send the mod.patch file, maybe that will reveal the secret. Ahh, just looked again and saw that I assumed wrong. Austin ran the http://dl.dropbox.com/u/6901628/raw.patch (with the modified header, that is intended to be fixed), not the http://dl.dropbox.com/u/6901628/bug_test.patch test-case, that should validate that the 32bit gcc WINE build is broken. (also the topic is about bug 27600, but you do not need this patch to reproduce it, left/right-clicking repositions the mouse cursor) (also applying patch http://source.winehq.org/patches/data/75733 fixes one regression, where the game hangs)
Re: dxgi.idl: Added DXGI_SWAP_CHAIN_FLAG enum declaration and DXGI_MWA_* flags
On 30 June 2011 17:34, Jacek Caban ja...@codeweavers.com wrote: +cpp_quote(#define DXGI_MWA_NO_WINDOW_CHANGES 0x1) +cpp_quote(#define DXGI_MWA_NO_ALT_ENTER 0x2) +cpp_quote(#define DXGI_MWA_NO_PRINT_SCREEN0x4) +cpp_quote(#define DXGI_MWA_VALID 0x7) Aren't those usually done as constants? (I.e., const UINT DXGI_MWA_NO_WINDOW_CHANGES = 0x1;)
Re: GSoC: dinput8 Action Mapping
Ouch, that is a leftover from an older try at this code. So much for
double checking the patches...
2011/6/30 Marcus Meissner meiss...@suse.de:
On Thu, Jun 30, 2011 at 02:56:08AM -0300, Lucas Zawacki wrote:
Hey guys, how are you doing? I've got some patches for you.
The first is a refactoring of the BuildActionMap implementations for
keyboard and mouse. I think with 'semantic_to_obj_id' the mapping is
pretty much correct for keyboard and mouse and it's being done the
right way.
The second patch is much like one I sent some time ago, it's
SetActionMap for keyboard and mouse, this time (hopefully) with the
dataformat stuff done right too. I've split it up in a third patch,
which implements the action mapping per se.
Anyway, tomorrow I'll code some mouse tests to be sure that this is working.
Cheers
From 37e5a1e6d51778ee0d5c0f3081dad8ca1431968f Mon Sep 17 00:00:00 2001
From: Lucas Fialho Zawacki lfzawa...@gmail.com
Date: Fri, 10 Jun 2011 21:43:53 -0300
Subject: dinput: Keyboard and mouse implementation of BuildActionMap (try 4)
+DWORD semantic_to_obj_id(IDirectInputDeviceImpl* This, DWORD dwSemantic)
+{
...
+ if (!found) return 0;
So 0 is the not found case...
+ DWORD obj_id = semantic_to_obj_id(This-base,
lpdiaf-rgoAction[i].dwSemantic);
+ if (obj_id != -1)
But here you check for -1.
+ DWORD obj_id = semantic_to_obj_id(This-base,
lpdiaf-rgoAction[i].dwSemantic);
+ if (obj_id != -1)
and here. (both mouse and keyboard code)
should probably check for 0 there, also as DWORD is unsigned ;)
Ciao, Marcus
Re: dxgi.idl: Added DXGI_SWAP_CHAIN_FLAG enum declaration and DXGI_MWA_* flags
On 06/30/11 17:44, Henri Verbeet wrote: On 30 June 2011 17:34, Jacek Caban ja...@codeweavers.com wrote: +cpp_quote(#define DXGI_MWA_NO_WINDOW_CHANGES 0x1) +cpp_quote(#define DXGI_MWA_NO_ALT_ENTER 0x2) +cpp_quote(#define DXGI_MWA_NO_PRINT_SCREEN0x4) +cpp_quote(#define DXGI_MWA_VALID 0x7) Aren't those usually done as constants? (I.e., const UINT DXGI_MWA_NO_WINDOW_CHANGES = 0x1;) They usually are, but these flags are exception, at least in the PSDK I have. Jacek
Re: [PATCH 1/4] shell32: Implement erasing and restoring items from the trash
Hi Jay,
+HRESULT TRASH_RestoreItem(LPCITEMIDLIST pidl){
Nit: the brace should be on its own line.
+HRESULT TRASH_RestoreItem(LPCITEMIDLIST pidl) DECLSPEC_HIDDEN;
+HRESULT TRASH_EraseItem(LPCITEMIDLIST pidl) DECLSPEC_HIDDEN;
These two functions are never called in this patch, so you're
introducing dead code. That's not allowed. Introduce the functions
in the patch that uses them, please. If the resulting patch is too
large, you must split it another way.
--Juan
Re: gcc 4.6 warning report
David is right, the address is not stored as a pointer but as a DWORD in place of the chars. Like this: gethostbyname(winehq.org): wrong: (DWORD) host-h_addr_list[i] = 0x00cbd1c8 = 200.209.203.0 right: *(DWORD*) host-h_addr_list[i] = 0x86192ed1 = 209.46.25.134 Patch welcome ;) --Juan
Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9
On Thu, Jun 30, 2011 at 4:10 PM, Henri Verbeet hverb...@gmail.com wrote:
On 30 June 2011 14:49, Michael Mc Donnell mich...@mcdonnell.dk wrote:
In init_edge_face_map I initialize an array of edge_face structs, and
in find_adjacent_face I do a linear search through that array. I would
like to replace the array with a hash table, so that the search time
becomes constant. I've found a standard list (wine/list.h) and
red-black tree implementation (wine/rbtree.h), but not a standard hash
table implementation. Is there a standard hash table implementation,
should I roll my own or find an LGPL'ed one?
I'm not sure if a hash table would be faster and how much, but an easy
way to make the lookup cheaper would be to store the edge - face map
as a list for each vertex.
So e.g. if you have these faces:
f0: v0, v2, v1
f1: v1, v4, v3
f2: v1, v2, v4
f3: v2, v5, v4
You'd build these lists:
v0: {v2:f0}
v1: {v0:f0}, {v4:f1}, {v2:f2}
v2: {v1:f0}, {v4:f2}, {v5:f3}
v3: {v1:f1}
v4: {v3:f1}, {v1:f2}, {v2:f3}
v5: {v4:f3}
It's then mostly trivial to determine adjacency. This assumes most
vertices are only part of a handful of edges, but I don't think that's
unreasonable in practice.
Thanks for your suggestion. I think you're right that it is safe to
assume that most vertices will only be a part of a few edges. I'll
implement that for now.
We did have a hash table inside wined3d at some point, I suppose you
could also try resurrecting that from git history.
I'll stick with your suggestion as it seems easier to implement :-)
Btw I just searched source.winehq.org for hash_table and found several
hits in different dlls. I think it would be nice if they could all use
the same implementation like list.h and rbtree.h. That way it could
also later be used for other parts of wine. Should I add it to
http://wiki.winehq.org/JanitorialProjects?
Re: [PATCH 5/5] jscript/tests: Add tests with values related to INT_MAX
On Mo, 2011-06-27 at 11:59 +0200, Jacek Caban wrote: How can we force tests to use VT_UI4? It's not JScript builtin type, you need to extend tests host object for that. Sorry, no clue. Which host object? +/* 0x7fff is 2147483647 is INT_MAX */ +tmp = 2147483647*-1; 0x... is correct jscript syntax, why not use it? Didn't know that. Thanks for the hint -- By by ... Detlef
Re: [PATCH 5/5] jscript/tests: Add tests with values related to INT_MAX
On 06/28/11 15:47, Detlef Riekenberg wrote: On Mo, 2011-06-27 at 11:59 +0200, Jacek Caban wrote: How can we force tests to use VT_UI4? It's not JScript builtin type, you need to extend tests host object for that. Sorry, no clue. Which host object Global host object for tests. See how nullDisp is done in run.c. Jacek
Re: wine bug 27600
On Thu, Jun 30, 2011 at 07:57, wy...@volny.cz wrote: $ cd wine-git $ wget http://dl.dropbox.com/u/6901628/raw.patch $ patch -p1 raw.patch $ ./tools/make_requests $ ./configure $ make works here: Thanks Austin for testing, but this raw.patch is already modified and works for me too. I would need to retest the series of nine individial patches ;) (thoses in wine-patches queue with status=New). Ah, right. Doing: git clean -dfx git reset --hard origin for i in 75876 75883 75878 75882 75881 75884 75877 75879 75880 do wget http://source.winehq.org/patches/data/$i -O /tmp/raw-$i.patch git apply /tmp/raw-$i.patch done ./tools/make_requests ./configure make gives: make[1]: Entering directory `/home/austin/wine-git/server' gcc -c -I. -I. -I../include -I../include -D__WINESRC__ -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o raw_input.o raw_input.c In file included from raw_input.c:28: ../include/winternl.h:2361: error: expected declaration specifiers or '...' before 'va_list' ../include/winternl.h:2531: error: expected declaration specifiers or '...' before 'va_list' ../include/winternl.h:2532: error: expected declaration specifiers or '...' before 'va_list' In file included from raw_input.c:29: ../include/winbase.h:1578: error: expected declaration specifiers or '...' before 'va_list' ../include/winbase.h:1579: error: expected declaration specifiers or '...' before 'va_list' make[1]: *** [raw_input.o] Error 1 make[1]: Leaving directory `/home/austin/wine-git/server' make: *** [server] Error 2 http://dl.dropbox.com/u/6901628/raw.patch works And the bug test patch: gcc -c -I. -I. -I../include -I../include -D__WINESRC__ -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o bug_test.o bug_test.c In file included from bug_test.c:8: ../include/winternl.h:2361: error: expected declaration specifiers or '...' before 'va_list' ../include/winternl.h:2531: error: expected declaration specifiers or '...' before 'va_list' ../include/winternl.h:2532: error: expected declaration specifiers or '...' before 'va_list' In file included from bug_test.c:9: ../include/winbase.h:1578: error: expected declaration specifiers or '...' before 'va_list' ../include/winbase.h:1579: error: expected declaration specifiers or '...' before 'va_list' make: *** [bug_test.o] Error 1 These tests were on: Linux aw25 2.6.37 #1 SMP Thu Apr 21 17:36:51 PDT 2011 i686 Intel(R) Core(TM) i7 CPU 960 @ 3.20GHz GenuineIntel GNU/Linux (gentoo) -- -Austin
Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9
On Thu, Jun 30, 2011 at 6:42 PM, Michael Mc Donnell
mich...@mcdonnell.dk wrote:
On Thu, Jun 30, 2011 at 4:10 PM, Henri Verbeet hverb...@gmail.com wrote:
On 30 June 2011 14:49, Michael Mc Donnell mich...@mcdonnell.dk wrote:
In init_edge_face_map I initialize an array of edge_face structs, and
in find_adjacent_face I do a linear search through that array. I would
like to replace the array with a hash table, so that the search time
becomes constant. I've found a standard list (wine/list.h) and
red-black tree implementation (wine/rbtree.h), but not a standard hash
table implementation. Is there a standard hash table implementation,
should I roll my own or find an LGPL'ed one?
I'm not sure if a hash table would be faster and how much, but an easy
way to make the lookup cheaper would be to store the edge - face map
as a list for each vertex.
...
It's then mostly trivial to determine adjacency. This assumes most
vertices are only part of a handful of edges, but I don't think that's
unreasonable in practice.
Thanks for your suggestion. I think you're right that it is safe to
assume that most vertices will only be a part of a few edges. I'll
implement that for now.
I've implemented the look-up scheme that you described.
I have another question about my test. I've basically copied all the
test data from my ConvertAdjacencyToPointReps test, and then just
inverted the conditions. Should I merge the two tests, put the test
data in a separate function, or just ignore the duplication?
From 549a95e2f8f218541d3f54afd08ee522e4e27e3e Mon Sep 17 00:00:00 2001
From: Michael Mc Donnell mich...@mcdonnell.dk
Date: Thu, 23 Jun 2011 17:46:51 +0200
Subject: d3dx9/test: Implemented ConvertPointRepsToAdjacency test.
---
dlls/d3dx9_36/tests/mesh.c | 452
1 files changed, 452 insertions(+), 0 deletions(-)
diff --git a/dlls/d3dx9_36/tests/mesh.c b/dlls/d3dx9_36/tests/mesh.c
index 98d77d9..1da6ed0 100644
--- a/dlls/d3dx9_36/tests/mesh.c
+++ b/dlls/d3dx9_36/tests/mesh.c
@@ -4904,6 +4904,457 @@ static void test_create_skin_info(void)
ok(hr == D3DERR_INVALIDCALL, Expected D3DERR_INVALIDCALL, got %#x\n, hr);
}
+static void test_convert_point_reps_to_adjacency(void)
+{
+HRESULT hr;
+struct test_context *test_context = NULL;
+const DWORD options = D3DXMESH_32BIT | D3DXMESH_SYSTEMMEM;
+const DWORD options_16bit = D3DXMESH_SYSTEMMEM;
+const D3DVERTEXELEMENT9 declaration[] =
+{
+{0, 0, D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_POSITION, 0},
+{0, 12, D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_NORMAL, 0},
+{0, 24, D3DDECLTYPE_D3DCOLOR, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_COLOR, 0},
+D3DDECL_END()
+};
+const unsigned int VERTS_PER_FACE = 3;
+void *vertex_buffer;
+void *index_buffer;
+DWORD *attributes_buffer;
+int i, j;
+enum color { RED = 0x, GREEN = 0xff00ff00, BLUE = 0xffff};
+struct vertex_pnc
+{
+D3DXVECTOR3 position;
+D3DXVECTOR3 normal;
+enum color color; /* In case of manual visual inspection */
+};
+D3DXVECTOR3 up = {0.0f, 0.0f, 1.0f};
+/* mesh0 (one face)
+ *
+ * 0--1
+ * | /
+ * |/
+ * 2
+ */
+const struct vertex_pnc vertices0[] =
+{
+{{ 0.0f, 3.0f, 0.f}, up, RED},
+{{ 2.0f, 3.0f, 0.f}, up, GREEN},
+{{ 0.0f, 0.0f, 0.f}, up, BLUE},
+};
+const DWORD indices0[] = {0, 1, 2};
+const unsigned int num_vertices0 = ARRAY_SIZE(vertices0);
+const DWORD exp_adjacency0[] = {-1, -1, -1};
+const DWORD point_rep0[] = {0, 1, 2};
+/* mesh1 (right)
+ *
+ * 0--1 3
+ * | / /|
+ * |/ / |
+ * 2 5--4
+ */
+const struct vertex_pnc vertices1[] =
+{
+{{ 0.0f, 3.0f, 0.f}, up, RED},
+{{ 2.0f, 3.0f, 0.f}, up, GREEN},
+{{ 0.0f, 0.0f, 0.f}, up, BLUE},
+
+{{ 3.0f, 3.0f, 0.f}, up, GREEN},
+{{ 3.0f, 0.0f, 0.f}, up, RED},
+{{ 1.0f, 0.0f, 0.f}, up, BLUE},
+};
+const DWORD indices1[] = {0, 1, 2, 3, 4, 5};
+const unsigned int num_vertices1 = ARRAY_SIZE(vertices1);
+const DWORD exp_adjacency1[] = {-1, 1, -1, -1, -1, 0};
+const DWORD point_rep1[] = {0, 1, 2, 1, 4, 2};
+/* mesh2 (left)
+ *
+ *3 0--1
+ * /| | /
+ * / | |/
+ * 5--4 2
+ */
+const struct vertex_pnc vertices2[] =
+{
+{{ 0.0f, 3.0f, 0.f}, up, RED},
+{{ 2.0f, 3.0f, 0.f}, up, GREEN},
+{{ 0.0f, 0.0f, 0.f}, up, BLUE},
+
+{{-1.0f, 3.0f, 0.f}, up, RED},
+{{-1.0f, 0.0f, 0.f}, up, GREEN},
+{{-3.0f, 0.0f, 0.f}, up, BLUE},
+};
+const DWORD indices2[] = {0, 1, 2, 3, 4, 5};
+const unsigned int num_vertices2 = ARRAY_SIZE(vertices2);
+const DWORD exp_adjacency2[] = {-1, -1, 1, 0, -1, -1};
+const DWORD point_rep2[] = {0, 1, 2, 0, 2, 5};
+/* mesh3 (above)
+ *
+ *
Re: wine bug 27600
Otherwise WINE compilation with 32bit gcc gets broken (not yet 100% confirmed, see the discussion with Wylda on wine-devel mailing list). Small patch to test for the issue - http://dl.dropbox.com/u/6901628/bug_test.patch Now i can confirm for sure, that simple testcase bug_test.patch fails here as in Austin's case: gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -g -O2 -o adsiid.o adsiid.c In file included from bug_test.c:8: ../include/winternl.h:2361: error: expected declaration specifiers or ‘...’ before ‘va_list’ ../include/winternl.h:2531: error: expected declaration specifiers or ‘...’ before ‘va_list’ ../include/winternl.h:2532: error: expected declaration specifiers or ‘...’ before ‘va_list’ In file included from bug_test.c:9: ../include/winbase.h:1578: error: expected declaration specifiers or ‘...’ before ‘va_list’ ../include/winbase.h:1579: error: expected declaration specifiers or ‘...’ before ‘va_list’ make[1]: *** [bug_test.o] Error 1 Including winternl.h before winbase.h and winuser.h must have caused the issue. Vincas could you open a bug for that? You probably know most about this issue ;) Thanks Vincas Austin! W.
Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9
On Thursday 30 June 2011 21:50:45 Michael Mc Donnell wrote: I have another question about my test. I've basically copied all the test data from my ConvertAdjacencyToPointReps test, and then just inverted the conditions. Should I merge the two tests, put the test data in a separate function, or just ignore the duplication? IMO keeping the tests separated and as simple as possible is more important than avoiding code duplication here, but I don't think we have a policy about this. signature.asc Description: This is a digitally signed message part.
Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9
On Thu, Jun 30, 2011 at 3:50 PM, Michael Mc Donnell
mich...@mcdonnell.dk wrote:
I've implemented the look-up scheme that you described.
+if (!point_reps) /* Indentity point reps */
+{
+memset(adjacency, -1, 3 * num_faces * sizeof(*adjacency));
+return D3D_OK;
+}
I think you are missing the most common cases, where vertices are
reused between triangles. For example:
0--1
| /|
|/ |
2--3
If identity point reps are passed to your function it will find the
adjacent edge, but if NULL is passed to the function for point reps,
then it will find no adjacencies even though semantically they should
be the same.
Also, note the spelling error: Indentity - Identity
+static void free_edge_face_map(struct edge_face_map *edge_face_map)
+{
+if (!edge_face_map)
+return;
+
+HeapFree(GetProcessHeap(), 0, edge_face_map-lists);
+HeapFree(GetProcessHeap(), 0, edge_face_map-entries);
+}
...
static HRESULT WINAPI ID3DXMeshImpl_ConvertPointRepsToAdjacency(ID3DXMesh
*iface, CONST DWORD *point_reps, DWORD *adjacency)
{
+struct edge_face_map *edge_face_map = NULL;
...
+free_edge_face_map(edge_face_map);
+iface-lpVtbl-UnlockIndexBuffer(iface);
+return hr;
}
edge_face_map isn't freed. Also, it doesn't need to be allocated on the heap.
+hr = iface-lpVtbl-LockIndexBuffer(iface, 0, ib_ptr);
The LockIndexBuffer flags could be D3DLOCK_READONLY rather than 0
(which seems to have read-write semantics).
