Re: What happened to the videos from WineConf?
On Jan 4, 2008 2:32 PM, Lei Zhang [EMAIL PROTECTED] wrote: On Jan 3, 2008 10:50 AM, Lei Zhang [EMAIL PROTECTED] wrote: On Dec 28, 2007 8:54 AM, Maarten Lankhorst [EMAIL PROTECTED] wrote: I remember at wineconf there were some videos created, what happened with those? I tried to look on youtube for wineconf, but I didn't find anything. Are they online yet? Or will they be put online? -Maarten Three videos were uploaded to Youtube last night: Alexandre's Keynote http://www.youtube.com/watch?v=GqEp8psjv5s Detlef Riekenberg - Printing in Wine http://www.youtube.com/watch?v=1-n6mClDdBQ Kai Blin - Wine and Samba http://www.youtube.com/watch?v=ToKeJbQ87c0 - Lei Two more videos: Martin Pilka - CxTest http://www.youtube.com/watch?v=VBZNOTngyeo Marteen Lankhorst - Wine and Sound http://www.youtube.com/watch?v=qKaYqsm4I_Q - Lei Stefan Dösinger's talk on Direct3D http://www.youtube.com/watch?v=eJ-zyKR1N2A
RE : Re: d3dx implementation senseless?
Since everybody agrees that we need a built-in d3dx9, we could begin to implement it. In the last talk about it, no plan was found to implement it: does one create a wined3dx or implement on the top of the last d3dx9 dll? So, I think that a definitive answer should be given very quickly. David - Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail
Re: What happened to the videos from WineConf?
Three videos were uploaded to Youtube last night: Alexandre's Keynote http://www.youtube.com/watch?v=GqEp8psjv5s Detlef Riekenberg - Printing in Wine http://www.youtube.com/watch?v=1-n6mClDdBQ Kai Blin - Wine and Samba http://www.youtube.com/watch?v=ToKeJbQ87c0 Martin Pilka - CxTest http://www.youtube.com/watch?v=VBZNOTngyeo Marteen Lankhorst - Wine and Sound http://www.youtube.com/watch?v=qKaYqsm4I_Q Stefan Dösinger's talk on Direct3D http://www.youtube.com/watch?v=eJ-zyKR1N2A I added the links to http://wiki.winehq.org/WineConf2007 Ciao, Marcus
Re: Bow and question
Juan Carlos Montes wrote: Hi all, I am new in this list, so... Hello!!! Well, I work in a CERT and we are create a automatic malware detection tool with wine. I think you should be aware that Wine is no replacement for a security tool. If you run a malware using Wine, it is possible for this malware to interact directly with your Linux machine, bypassing your protection. Shachar
Re: Where are the bugzilla admins?
On Sat, Jan 05, 2008 at 09:55:12PM -0700, James Hawkins wrote: On Jan 5, 2008 6:36 PM, Jan Zerebecki [EMAIL PROTECTED] wrote: On Sat, Jan 05, 2008 at 03:32:10PM -0700, Vitaliy Margolen wrote: Jan Zerebecki wrote: On Sat, Dec 29, 2007 at 09:11:17AM -0700, Vitaliy Margolen wrote: Where did our buzilla admins go? 3 weeks and nothing is changing! If we have only one bugzilla admin and we can not get any response from that admin for the 4!!! weeks - REGARDLESS what the reasons are, we need more admins period. In case of these component changes I felt that there was too much controversy (and no final proposal where the only response was yes; this paired with that some bugzilla admins wanted me to have an -devel approved list of changes) for me to do changes to bugzilla before waiting some more. (Though some delay can probably be attributed to the fact that I am currently without Internet on weekdays, outside of work.) Anyway no part of that was in any way urgent. What controversy? The final list proposed by me and Vitaliy was unchallenged. With controversy I was refering to the discussion before. Btw. the last mail on that thread is now only 2 weeks old and was not even one week old when Vitaliy sent the first mail in this thread. Anyone who wants to to do stuff is welcome, just speak up. Jan
Re: bugs audit volunteers require
On Sat, Jan 05, 2008 at 09:59:52PM -0700, James Hawkins wrote: On Jan 5, 2008 7:02 PM, Jan Zerebecki [EMAIL PROTECTED] wrote: On Wed, Jan 02, 2008 at 01:19:35AM -0800, Dan Kegel wrote: Maybe add a resolution of NEEDMOREINFO? There is no need to add one more reason for a bug resolution IMHO, INVALID with appropriate comment does the job. INVALID seems harsh, it may scare away novice reporters. Yes if it's used without waiting for an answer (or even even more without requesting further clarification) it might make one feel shot down. And usually it's used too quickly. Most bug resolutions should probably be only done when some care or communication was done to check that it's the correct resolution, to avoid resolution ping-pong. Do we want to make it easy to search for bugs stuck in a needmoreinfo kind of state? If so, a keyword or state might be handy. I think a keyword would be appropriate. It would nicely fit with the Abandoned? keyword: first add needmoreinfo, if no answer for 6 month add Abandoned?, after further 6 month resolve abandoned. 12 months to close a bug as abandoned? 6 months is already too long for abandoned. The policy has always been: if a reporter does not respond to an information request within X months, close the bug as abandoned. We have 3843 bugs for Wine and the list is only getting larger. This fear of closing bugs is only making the problem worse. People seem to forget that a user can always come back and reopen the bug report. Afaik only selected users can reopen bugs. Users that can edit bugs and the reporter can do that and if I remember correctly we seem to want to also prevent the reporter from doing that. Open bugs lingering in needmoreinfo or Abandoned? don't hurt. Othoh closing bugs too quickly as invalid or abandoned may drive bug reporters away which would hurt us in the long run. If you'd just want to get less bugs we could have a special permission for filing bugs and only let selected people who we trust to report really useful bugs (though I think that is not what we want). Anyway the 12 month were only an example, I'm fine with 6 month. I'm more concerned about closing bugs (e.g. as invalid) where someone is active and disagrees. It might make sense to rename Abandoned? to needmoreinfo, so that one can key a bug as needmoreinfo and after x month with that keyword and no response resolve it abandoned. Though we probably don't want to use needmoreinfo on bugs where it's possible for someone to retest if the bug is still there (e.g. where there is a download for the application and the bug is described sufficiently to check for it oneself). Jan
Re: What happened to the videos from WineConf?
Hi all, Marcus Meissner schreef: I added the links to http://wiki.winehq.org/WineConf2007 I updated that wiki page a little, and added my and newman's photos of wineconf, and the big group photo. Does anyone else have a photo album they want to share? I created mine with picasa for linux, which uses wine. Cheers, Maarten
Re: comdlg32: 1/2 PageSetupDlg: Convert paint procs to Unicode
On Monday 31 December 2007 07:39:28 Dmitry Timoshkov wrote: Alexander Nicolaysen Sørnes [EMAIL PROTECTED] wrote: comdlg32: 1/2 PageSetupDlg: Convert paint procs to Unicod What's the purpose of this patch? It improves nothing IMO except of making the code less readable, making it not thread safe, calling CallWindowProcW where it shouldn't. Would it be better to have separate A/W painting functions? Alexander
Re: comdlg32: 1/2 PageSetupDlg: Convert paint procs to Unicode
Alexander Nicolaysen Sørnes [EMAIL PROTECTED] wrote: Would it be better to have separate A/W painting functions? What that would improve? -- Dmitry.
Re: comdlg32: 1/2 PageSetupDlg: Convert paint procs to Unicode
On Sunday 06 January 2008 15:29:46 Dmitry Timoshkov wrote: Alexander Nicolaysen Sørnes [EMAIL PROTECTED] wrote: Would it be better to have separate A/W painting functions? What that would improve? Nothing that I can think of, but you know the code much beter than me. It just seemed like you disagreed with the intention of my original patch as well as the patch itself. Alexander
Re: dlls/kernel32/task.c -- minor improvement
Gerald Pfeifer [EMAIL PROTECTED] writes: That depends. ;-) You're right, it is not ISO C90, but it is in the C99 standard which is now close to ten years old. We don't use C99 features in Wine. That said, if you don't want to take the original patch, can we take the one below? I don't think that's an improvement, thunks are not really words, they are code. -- Alexandre Julliard [EMAIL PROTECTED]
Why the dash in the new -unknown category?
Is it to make it show up first in the list?
Re: What happened to the videos from WineConf?
On Sun, Jan 06, 2008 at 02:47:24PM +0100, Maarten Lankhorst wrote: and the big group photo OK, and now for those who were not there: An annotated version of that photo with a who is who pretty please :-) Ciao Joerg -- Joerg Mayer [EMAIL PROTECTED] We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology.
Re: [PATCH] ntdll: remove bogus VALGRIND_DISCARD
On Sonntag 06 Januar 2008, Peter Oberndorfer wrote: VALGRIND_DISCARD is used to discard block description handles (which are created by VALGRIND_CREATE_BLOCK) but it was called with the return value of VALGRIND_MAKE_xxx macros which all return 0x dlls/ntdll/signal_i386.c uses this macros already without VALGRIND_DISCARD --- dlls/ntdll/heap.c | 16 1 files changed, 8 insertions(+), 8 deletions(-) Please don't apply this yet, it needs further research. The valgrind manual tells us in the Client Requests section that VALGRIND_MAKE_xxx functions return such a block handle [1], But looking at the implementation of valgrind/adding traces to valgind DISCARD request show it returns 0x ? Greetings Peter [1] valgrind manual Release 3.3.0 - 4.6. Client Requests * VALGRIND_MAKE_MEM_NOACCESS, VALGRIND_MAKE_MEM_UNDEFINED and VALGRIND_MAKE_MEM_DE These mark address ranges as completely inaccessible, accessible but containing undefined data, and accessible and containing defined data, respectively. Subsequent errors may have their faulting addresses described in terms of these blocks. _Returns a block handle_. Returns zero when not run on Valgrind. * VALGRIND_MAKE_MEM_DEFINED_IF_ADDRESSABLE. This is just like VALGRIND_MAKE_MEM_DEFINED but only affects those bytes that are already addressable. * VALGRIND_DISCARD: At some point you may want Valgrind to stop reporting errors in terms of the blocks defined by the previous three macros. To do this, the above macros return a small-integer block handle. You can pass this block handle to VALGRIND_DISCARD. After doing so, Valgrind will no longer be able to relate addressing errors to the user-defined block associated with the handle. The permissions settings associated with the handle remain in place; this just affects how errors are reported, not whether they are reported. Returns 1 for an invalid handle and 0 for a valid handle (although passing invalid handles is harmless). Always returns 0 when not run on Valgrind.
Re: What happened to the videos from WineConf?
On Sun, Jan 06, 2008 at 04:52:23PM +0100, Joerg Mayer wrote: On Sun, Jan 06, 2008 at 02:47:24PM +0100, Maarten Lankhorst wrote: and the big group photo OK, and now for those who were not there: An annotated version of that photo with a who is who pretty please :-) Be there or be a rectangular thing :) Actually I started marking one up, but at one point in time run out of names and time :/ Anyway, the result as I stopped: http://www.lst.de/~mm/wineconf2007group_annotated.jpg And the GIMP xcf with every name as another layer: http://www.lst.de/~mm/IMG_1187.xcf (26 MB) If someone mails me what names to fill in where I can update it further. Ciao, Marcus
Re: ole32: Fix a failed call to DllGetClassObject while retrieving class object interface pointer.
Huang, Zhangrong wrote:
Hi,
Sorry for the delay.
Here is a test, pls import the attached registry files, and copy
native activeds.dll, adsldpc.dll,
adsldp.dll to your windows system32 dir, and patch
wine/dlls/ole32/tests/moniker.c
Then run the test:
$ ../../../wine ole32_test.exe.so moniker
err:ole:apartment_getclassobject DllGetClassObject returned error 0x80004002
err:ole:create_server class {228d9a81-c302-11cf-9aa4-00aa004a5691} not
registered
fixme:ole:CoGetClassObject CLSCTX_REMOTE_SERVER not supported
err:ole:CoGetClassObject no class object
{228d9a81-c302-11cf-9aa4-00aa004a5691} could be created for context
0x15
moniker.c:783: Test failed: LDAP**
moniker: 2 tests executed (0 marked as todo, 1 failure), 0 skipped.
after my patch:
$ ../../../wine ole32_test.exe.so moniker
moniker.c:783: Test failed: LDAP**
moniker: 2 tests executed (0 marked as todo, 1 failure), 0 skipped.
Although the test failed, but loading class
{228d9a81-c302-11cf-9aa4-00aa004a5691} success.
I've just sent a patch for this. Thanks for reporting it and going to
the trouble of describing how to reproduce it and proposing a patch.
--
Rob Shearman
Strange bash error shell-init: error retrieving current directory
I've been seeing the error shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory a lot recently when running Wine, probably when installers finish. It started a couple weeks ago. I think it's a bash error message. Anyone else seeing that, or know what causes it? (Do we run our wrapper script in a directory that goes away, say?)
bugzilla component and keyword cleanup
I'm done with one step of the changes. See the following URLs for how things currently look: http://bugs.winehq.org/describekeywords.cgi http://bugs.winehq.org/describecomponents.cgi?product=Wine Improvement suggestions are welcome. Does anyone know how the CVS/GIT version is marked so that it gets selected on the new bug page and if that is also possible for the component? Now for further improvements: Changes which IMHO should not be done: wine-help - hhctrl - Help viewer implementation help is currently not for the various help APIs but for user that want help. We should obsolete this component. We can create a new component for the help APIs if there is demand. (new) - vdm - Wine 16-bit compatibility layer (new) - win16 - Wine 16-bit compatibility layer vdm is part of the component dos, right? A win16 keyword is probably useful as win16 support is intertwined in quite some other DLLs and thus components. Components that are marked as obsolete now, but where it's not sure how to replace them: multimedia Should we really replace this? Replace it with what? An mci and winmm component? console I didn't really made my mind up about this one yet... files ipc ports winelib Possibly replace each with a keyword, see below. Changes to the keywords: conformance (delete) Delete this keyword, because it fits probably most wine bugs. testcase (new) Bugs that have a testcase attached, in source form but not necessarily integrated into the Wine test suite. win16 (new) Bugs in the win16 parts of Wine. dotnet (new) Bugs that appear in applications using dotNet and that are related to this dotNet useage. winelib (new) Bugs during winelib useage but not during useage through windows native executables. ports (new) Bugs regarding porting to specific platforms or OSs. FIXME needs clarification tasklet needs clarification tasklist needs clarification Abandoned? - needmoreinfo This is currently discussed in another thread. filesystem (new) Do we want such a component? Is it maybe related with console? What exactly should it cover? Only things that possibly can destroy data? console (new) I didn't really made my mind up about this one yet... Jan
Re: Why the dash in the new -unknown category?
On Sun, Jan 06, 2008 at 07:48:42AM -0800, Dan Kegel wrote: Is it to make it show up first in the list? Yes. Jan
Re: d3dx implementation senseless?
Since everybody agrees that we need a built-in d3dx9, we could begin to implement it. In the last talk about it, no plan was found to implement it: does one create a wined3dx or implement on the top of the last d3dx9 dll? So, I think that a definitive answer should be given very quickly. David As far as I read, we decided to create the dlls/d3dx9_** directories, use the latest one for all the code and forward all calls from older dlls to this one. However, I don't think that it is a problem if a dll contains more functions than the native dll, so we could also just use 12 (sth. around that) copies of the same dll. And about starting development: I have already began to implement the D3DXRenderToSurface interface, but I'm new to COM programming so the progress is quite slow, so I'd recommend someone other to do the base of the dll. A suggestion I'd like to do is a message that Wine should print out when a program wants to use the d3dx9 dll, sth. like: MESSAGE(The application you want to run makes use of the D3DX9 library!n); MESSAGE(tIts implementation under Wine is very young and far away from complete.n); MESSAGE(tYou may be better off using a native d3dx9_24.dll file.n);
Re: dlls/kernel32/task.c -- minor improvement
Gerald Pfeifer [EMAIL PROTECTED] writes: On Sun, 6 Jan 2008, Alexandre Julliard wrote: We don't use C99 features in Wine. Actually we do. % egrep -r ^(static )?inline $WINE_SOURCE/ | wc -l 2031 inline is pretty similar to flexible array members in that both were not in C90, both are in C99, and both have been GNU extensions before C99, so I'm not sure why we use one but not the other. inline is automatically disabled if the compiler doesn't support it. -- Alexandre Julliard [EMAIL PROTECTED]
Re: bugzilla component and keyword cleanup
On Jan 6, 2008 9:55 AM, Jan Zerebecki [EMAIL PROTECTED] wrote: I'm done with one step of the changes. See the following URLs for how things currently look: http://bugs.winehq.org/describekeywords.cgi http://bugs.winehq.org/describecomponents.cgi?product=Wine Improvement suggestions are welcome. Does anyone know how the CVS/GIT version is marked so that it gets selected on the new bug page and if that is also possible for the component? Now for further improvements: Changes which IMHO should not be done: wine-help - hhctrl - Help viewer implementation help is currently not for the various help APIs but for user that want help. We should obsolete this component. We can create a new component for the help APIs if there is demand. There is demand. Using the now _obsolete_help keyword, there are 7 bugs relating to the help APIs. (new) - vdm - Wine 16-bit compatibility layer (new) - win16 - Wine 16-bit compatibility layer vdm is part of the component dos, right? A win16 keyword is probably useful as win16 support is intertwined in quite some other DLLs and thus components. Components that are marked as obsolete now, but where it's not sure how to replace them: multimedia Should we really replace this? Replace it with what? An mci and winmm component? Yes it should be replaced with the appropriate components, whichever Dlls they belong to. We can start arranging those and then remove the component when that's done. console I didn't really made my mind up about this one yet... Yes, the bug is either in wine-programs (wineconsole) or the console APIs, kernel32. files ipc ports winelib Possibly replace each with a keyword, see below. Changes to the keywords: conformance (delete) Delete this keyword, because it fits probably most wine bugs. testcase (new) Bugs that have a testcase attached, in source form but not necessarily integrated into the Wine test suite. win16 (new) Bugs in the win16 parts of Wine. dotnet (new) Bugs that appear in applications using dotNet and that are related to this dotNet useage. winelib (new) Bugs during winelib useage but not during useage through windows native executables. ports (new) Bugs regarding porting to specific platforms or OSs. FIXME needs clarification tasklet needs clarification tasklist needs clarification Abandoned? - needmoreinfo This is currently discussed in another thread. filesystem (new) Do we want such a component? Is it maybe related with console? What exactly should it cover? Only things that possibly can destroy data? console (new) I didn't really made my mind up about this one yet... Jan -- James Hawkins
Re: msxml3: IXMLDOMAttribute does not support get_nextSibling
Ignore this patch. Alistair Leslie-Hughes wrote: Hi, Changelog: msxml3: IXMLDOMAttribute does not support get_nextSibling Best Regards Alistair Leslie-Hughes
Re: msxml3: IXMLDOMDocument does not support get_nextSibling
Ignore this patch. Alistair Leslie-Hughes wrote: Hi, Changelog: msxml3: IXMLDOMDocument does not support get_nextSibling Best Regards Alistair Leslie-Hughes
question about fixing D3DRENDERSTATE_TEXTUREMAPBLEND
Hi.
I found some problems with D3DRENDERSTATE_TEXTUREMAPBLEND state =
D3DTBLEND_MODULATE in ddraw and handling the alpha channel. This old state is
currently mapped to texture stage states, with alpha part done as
IWineD3DDevice_SetTextureStageState(This-wineD3DDevice, 0,
WINED3DTSS_ALPHAARG1, WINED3DTA_TEXTURE);
IWineD3DDevice_SetTextureStageState(This-wineD3DDevice, 0,
WINED3DTSS_ALPHAOP, WINED3DTOP_SELECTARG1);
This isn't correct, I believe, because in some cases it should be taken from
diffuse color (Aliens vs Predator 1 depends on it). But the latter behavior
isn't correct in all cases either.
I found this description of this state on some random website via google:
D3DTBLEND_MODULATE Modulate texture-blending is supported. In this mode, the
RGB values of the texture are multiplied with the RGB values that would have
been used with no texturing. Any alpha values in the texture replace the alpha
values that would have been used with no texturing.
http://www.hi.is/~snorri/SDK-docs/x/exten203.htm
I guess, this means that it either takes alpha from texture or from diffuse
color, depending on whether the current texture has alpha channel (which takes
priority). I've submitted a test for this to wine-patches that includes checks
with both kinds of textures. It passes on XP and thus supports that this is the
way it is supposed to happen. Unfortunately, this doesn't easily translate to
available texture stage states. So it looks like something more hacky is needed
to make it work correctly in all cases in wine. There are two approaches I can
think of:
1) introduce an internal D3DTOP_ value in wined3d that will map to texture alpha
or diffuse alpha, depending on the pixel format of the currently selected
texture.
2) move D3DRENDERSTATE_TEXTUREMAPBLEND handling to wined3d;
So it would be nice if Stefan Dösinger or maybe somebody else of d3d devs gave
me some directions - which approach (if any) is ok and acceptable for wine
project. I'll attach a diff with my current hacks that show how 1st approach is
about to look.
BTW, this worked in wine around 0.9.15
http://source.winehq.org/git/wine.git/?a=blob;f=dlls/ddraw/opengl_utils.c;h=a2b021985acfe3fbae888cb0e954b8fb47c86db3;hb=0fa7170dc318a6624f960c49e459cb521d2ae999
There it wasn't mapping to texture stage states, but instead was using such
call:
glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
From what I read about GL_MODULATE, I'm not sure it always does exactly the
thing TEXTUREMAPBLEND=MODULATE is supposed to do, but with Aliens vs Predator it
worked better.
diff --git a/dlls/ddraw/device.c b/dlls/ddraw/device.c
index 135d6e9..e2cd23a 100644
--- a/dlls/ddraw/device.c
+++ b/dlls/ddraw/device.c
@@ -2534,10 +2534,9 @@ IDirect3DDeviceImpl_7_SetRenderState(IDirect3DDevice7
*iface,
{
case D3DTBLEND_MODULATE:
IWineD3DDevice_SetTextureStageState(This-wineD3DDevice,
0, WINED3DTSS_COLORARG1, WINED3DTA_TEXTURE);
-IWineD3DDevice_SetTextureStageState(This-wineD3DDevice,
0, WINED3DTSS_ALPHAARG1, WINED3DTA_TEXTURE);
IWineD3DDevice_SetTextureStageState(This-wineD3DDevice,
0, WINED3DTSS_COLORARG2, WINED3DTA_CURRENT);
IWineD3DDevice_SetTextureStageState(This-wineD3DDevice,
0, WINED3DTSS_COLOROP, WINED3DTOP_MODULATE);
-IWineD3DDevice_SetTextureStageState(This-wineD3DDevice,
0, WINED3DTSS_ALPHAOP, WINED3DTOP_SELECTARG1);
+IWineD3DDevice_SetTextureStageState(This-wineD3DDevice,
0, WINED3DTSS_ALPHAOP, WINED3DTOP_DX6MODULATE);
break;
case D3DTBLEND_MODULATEALPHA:
diff --git a/dlls/wined3d/state.c b/dlls/wined3d/state.c
index 59ff3d4..9f11f73 100644
--- a/dlls/wined3d/state.c
+++ b/dlls/wined3d/state.c
@@ -351,6 +351,12 @@ static void state_blend(DWORD state,
IWineD3DStateBlockImpl *stateblock, WineD3D
TRACE(glBlendFunc src=%x, dst=%x\n, srcBlend, dstBlend);
glBlendFunc(srcBlend, dstBlend);
checkGLcall(glBlendFunc);
+
+/* colorkey fixup for stage 0 alphaop depends on
WINED3DRS_ALPHABLENDENABLE state,
+so it may need updating */
+if (stateblock-renderState[WINED3DRS_COLORKEYENABLE]) {
+StateTable[STATE_TEXTURESTAGE(0,
WINED3DTSS_ALPHAOP)].apply(STATE_TEXTURESTAGE(0, WINED3DTSS_ALPHAOP),
stateblock, context);
+}
}
static void state_blendfactor(DWORD state, IWineD3DStateBlockImpl *stateblock,
WineD3DContext *context) {
@@ -1932,6 +1938,24 @@ static void tex_alphaop(DWORD state,
IWineD3DStateBlockImpl *stateblock, WineD3D
arg2 = stateblock-textureState[stage][WINED3DTSS_ALPHAARG2];
arg0 = stateblock-textureState[stage][WINED3DTSS_ALPHAARG0];
+if (op == WINED3DTOP_DX6MODULATE) {
+IWineD3DSurfaceImpl *surf = NULL;
+
+if (stage 0) ERR(unexpected WINED3DTOP_DX6MODULATE at stage 0\n);
+
+if (stateblock-textures[0])
+surf = (IWineD3DSurfaceImpl *)
Re: [1/2][try 3] ddraw/tests: add test for rendering vertices with zero rhw
On 07/01/2008, Alexander Dorofeyev [EMAIL PROTECTED] wrote: Hi. I couldn't reproduce any problems with this patch on wine or on windows, but I moved coordinates of retrieved pixel a bit away from edges. I hope this was the problem :-/ It could've been a depth buffer issue as well. I'm not exactly sure what the state of the depth buffer is when the test is run, but in general it appears the GF8 rounds slightly different compared to previous nvidia cards.
Re: bugs audit volunteers require
Jan Zerebecki wrote: It might make sense to rename Abandoned? to needmoreinfo, so that one can key a bug as needmoreinfo and after x month with that keyword and no response resolve it abandoned. Though we probably don't want to use needmoreinfo on bugs where it's possible for someone to retest if the bug is still there (e.g. where there is a download for the application and the bug is described sufficiently to check for it oneself). Jan: 1. I would give the original reporter less than six months to respond. I would wait no more than a month for a response before closing as abandoned. 2. The purpose of needsmoreinfo is that the original reporter did not supply sufficient information to reproduce the reported problem. If a reported problem can be tested, and the problem determined, then the bug should not be placed in a needsmoreinfo status. Another status would apply, like NEW or CONFIRMED, at this point. James McKenzie
Re: d3dx implementation senseless?
[EMAIL PROTECTED] schreef: Since everybody agrees that we need a built-in d3dx9, we could begin to implement it. In the last talk about it, no plan was found to implement it: does one create a wined3dx or implement on the top of the last d3dx9 dll? So, I think that a definitive answer should be given very quickly. David As far as I read, we decided to create the dlls/d3dx9_** directories, use the latest one for all the code and forward all calls from older dlls to this one. However, I don't think that it is a problem if a dll contains more functions than the native dll, so we could also just use 12 (sth. around that) copies of the same dll. And about starting development: I have already began to implement the D3DXRenderToSurface interface, but I'm new to COM programming so the progress is quite slow, so I'd recommend someone other to do the base of the dll. A suggestion I'd like to do is a message that Wine should print out when a program wants to use the d3dx9 dll, sth. like: MESSAGE(The application you want to run makes use of the D3DX9 library!n); MESSAGE(tIts implementation under Wine is very young and far away from complete.n); MESSAGE(tYou may be better off using a native d3dx9_24.dll file.n); Just copy the DllMain from sfc/sfc_main.c for example. Cheers, Maarten
[Fwd: Re: French LTEXT correction]
Hello, Please use reply-to all so that everybody on the list can read your answer. Forwarded Message From: Vincent Hardy [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: Jonathan Ernst [EMAIL PROTECTED] Subject: Re: French LTEXT correction Date: Mon, 07 Jan 2008 08:45:19 +0100 Jonathan Ernst a écrit : On ven, 2008-01-04 at 11:24 +0100, Vincent Hardy wrote: Regedit displays Rechercher::. Now Regedit displays Rechercher : and so on... It doesn't here (?). Furthermore in French : should be preceded by an unbreakable space (like it's the case now) and not a normal space. Thank you for your explanation. Nevertheless, it is not normal ::. See capture... (sorry for my poor english, I'm french speaking) inline: regedit.png signature.asc Description: This is a digitally signed message part
