June 2011 - Wine-Devel - list.winehq.org

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Stefan Dösinger

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.

June 30, 2011

Re: wine bug 27600

by wylda＠volny.cz

> 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.

June 30, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Michael Mc Donnell

On Thu, Jun 30, 2011 at 6:42 PM, Michael Mc Donnell <michael(a)mcdonnell.dk> wrote: > On Thu, Jun 30, 2011 at 4:10 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: >> On 30 June 2011 14:49, Michael Mc Donnell <michael(a)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?

June 30, 2011

Re: wine bug 27600

by Austin English

On Thu, Jun 30, 2011 at 07:57, <wylda(a)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

June 30, 2011

Re: [PATCH 5/5] jscript/tests: Add tests with values related to INT_MAX

by Jacek Caban

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

June 30, 2011

Re: gcc 4.6 warning report

by Juan Lang

> 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

June 30, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Michael Mc Donnell

On Thu, Jun 30, 2011 at 4:10 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 30 June 2011 14:49, Michael Mc Donnell <michael(a)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?

June 30, 2011

Re: [PATCH 1/4] shell32: Implement erasing and restoring items from the trash

by Juan Lang

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

June 30, 2011

Re: dxgi.idl: Added DXGI_SWAP_CHAIN_FLAG enum declaration and DXGI_MWA_* flags

by Jacek Caban

On 06/30/11 17:44, Henri Verbeet wrote: > On 30 June 2011 17:34, Jacek Caban <jacek(a)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_SCREEN 0x4") >> +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

June 30, 2011

Re: GSoC: dinput8 Action Mapping

by Lucas Zawacki

Ouch, that is a leftover from an older try at this code. So much for double checking the patches... 2011/6/30 Marcus Meissner <meissner(a)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 <lfzawacki(a)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 >

June 30, 2011

Re: dxgi.idl: Added DXGI_SWAP_CHAIN_FLAG enum declaration and DXGI_MWA_* flags

by Henri Verbeet

On 30 June 2011 17:34, Jacek Caban <jacek(a)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_SCREEN 0x4") > +cpp_quote("#define DXGI_MWA_VALID 0x7") Aren't those usually done as constants? (I.e., "const UINT DXGI_MWA_NO_WINDOW_CHANGES = 0x1;")

June 30, 2011

Re: wine bug 27600

by Vincas Miliūnas

On 06/30/2011 06:07 PM, Vincas Miliūnas wrote: > On 06/30/2011 05:57 PM, wylda(a)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)

June 30, 2011

Re: wine bug 27600

by Vincas Miliūnas

On 06/30/2011 05:57 PM, wylda(a)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.

June 30, 2011

Re: wine bug 27600

by wylda＠volny.cz

> > $ 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.

June 30, 2011

Re: wine bug 27600

by Matijn Woudt

On Thu, Jun 30, 2011 at 4:52 PM, Austin English <austinenglish(a)gmail.com> wrote: > 2011/6/30 <wylda(a)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(a)debian:~/wine-git$ cat /etc/issue > Debian GNU/Linux wheezy/sid \n \l > > austin(a)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?

June 30, 2011

Re: wine bug 27600

by Austin English

2011/6/30 <wylda(a)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(a)debian:~/wine-git$ cat /etc/issue Debian GNU/Linux wheezy/sid \n \l austin(a)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

June 30, 2011

Re: wine bug 27600

by Vincas Miliūnas

On 06/30/2011 05:31 PM, wylda(a)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 :)

June 30, 2011

Re: wine bug 27600

by wylda＠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.

June 30, 2011

Re: GSoC: dinput8 Action Mapping

by Marcus Meissner

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 <lfzawacki(a)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

June 30, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Henri Verbeet

On 30 June 2011 14:49, Michael Mc Donnell <michael(a)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.

June 30, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Michael Mc Donnell

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

June 30, 2011

Re: [PATCH 1/3] d3dx9/line: Implemented ID3DXLine's Draw method.

by Matteo Bruni

2011/6/30 Charles Welton <charleswfb(a)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...

June 30, 2011

Re: [PATCH 5/5] jscript/tests: Add tests with values related to INT_MAX

by Detlef Riekenberg

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? > > +/* 0x7fffffff 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

June 30, 2011

Re: [3/8] msi: Handle escaped double quotes in command line parsing.

by Marvin

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

June 30, 2011

RectInRegion Question

by Alistair Leslie-Hughes

Hi, When looping Region rects in function RectInRegion, we have the condition if(pCurRect->top >= rc.bottom) break; Should this break actually be a continue, like the other conditions? Best Regards Alistair Leslie-Hughes

June 30, 2011