wine-devel

wine-devel@winehq.org

2 participants
84470 discussions

Re: [lostwages] Remove winetools from download page
by Michael Jung 24 Dec '05

24 Dec '05

On Tuesday 20 December 2005 23:23, Vitaliy Margolen wrote: > Thus removing it from the official download page is a wise choice. I'm we > will still get number of users on wine-users and #winehq with winetools > related problems. But at least we will stop spread of "bad habits". I did'nt use winetools for quite a while now, but it was a great tool to get a newbie up and running with wine back then. If it hurts us more than it helps today, then we should take some action. But could we perhaps get in contact with Joachim von Thadden before we remove the link? He has put a lot of effort in winetools and he's a great wine advocate (He wrote a multi page technical article on wine for c't magazine a few months ago, which is one of the big computer publications here in germany. This article was based on winetools, but also did a lot of advertising for CodeWeavers and Wine in general). In my opinion he deserves some respect from our part. We should give him a chance to fix the problems with winetools before we silently remove the link. Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

12 34

Accidentally fixed a bug :-)
by Dan Kegel 24 Dec '05

24 Dec '05

I've been helping a couple small ISVs test their apps and file bugs lately. To my surprise, one of the bugs (ChooseColor() not responding to keystrokes, http://bugs.winehq.org/show_bug.cgi?id=4125) was easy enough to fix without any real knowledge of the code, so I posted a patch that seems to fix it (http://www.winehq.org/pipermail/wine-patches/2005-December/023048.html). It was a pleasant surprise to run into something so easy to fix. Guess I should try it more often! - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 1

Success: The Journal runs mostly great with 0.9.4...
by Dan Kegel 24 Dec '05

24 Dec '05

While surfing, I ran into a "micro-ISV support blog", http://safarisoftware.typepad.com/mlp_developer_news dedicated to the very small developer. It happened to profile a guy who wrote a little notetaking application in Delphi years back just to learn the language, and who was surprised to find he could make a living selling it. It's called "The Journal", and a free demo is available from http://www.davidrm.com/download/jnl4setup.exe It seems to install and run rather well under wine-0.9.4 except for some richtext glitches, a redraw problem (just flip around between the main mode tabs of the app and watch the legend on the right below the toolbar - it gets pretty corrupt), and a bit of sluggishness. Plus, like many other apps I've tested lately, it constantly spews fixme:win:LockWindowUpdate (0x2003e), partial stub! fixme:win:LockWindowUpdate ((nil)), partial stub! I wrote up the redraw problem as http://bugs.winehq.org/show_bug.cgi?id=4145 That's the only problem bad enough to kill a demo of the app so far. -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

[wined3d] D3DXCreateFont
by Aric Cyr 24 Dec '05

24 Dec '05

I've been using some dx9 tutorial/demo apps that use the d3dx9.dll. I got this dll off the net somewhere (d3dx9_27.dll to be exact). This is just a utility library that has some helper functions for D3D apps, like font rendering etc. Oliver has mentioned that he uses some of the same apps for testing wined3d, which is why I picked them (http://www.codesampler.com/dx9src.htm). However, about half of them call D3DXCreateFont, which always fails on my system. As such, the return font object is null and so the demo crashes shortly afterwards when it tries to call a member function through the null object. All of these demos just try to load the "Arial" font, which seems to be registered. I'm just curious how Oliver, and maybe others, are running these demos if they always crash at startup. The demos do pop up a message box like "D3DXCreateFont: failed!!!" or something like that, and after you click the "OK" button, the app continues anyways, and then crashes soon after. If anyone knows how to get around this font thing I'd very much like to know! Cheers, Aric

1 0

Re: [OLE] Storage
by Sven Paschukat 23 Dec '05

23 Dec '05

Ulrich Czekalla schrieb: > ChangeLog: > Ulrich Czekalla <ulrich(a)codeweavers.com> > Return error instead of asserting if file is corrupt This patch seems to hang installation of Internet Explorer. If I assign a native ole32.dll to ie6wzd.exe or use the builtin ole32 before this submit then it's running. The freeze happens when completing the component selection dialog. Sven

1 0

Re: Alexandre Julliard : ntdll: More compatible exception information for protection faults.
by Paul Vriens 23 Dec '05

23 Dec '05

Hi, this latest addition to the tests throws an exception on win98. Screenshot attached. Probably Alexandre's area, as he wrote the test. Cheers, Paul.

3 2

Re: [lostwages] Remove winetools from download page
by Chris Morgan 23 Dec '05

23 Dec '05

On 12/23/05, wino(a)piments.com <wino(a)piments.com> wrote: > On Fri, 23 Dec 2005 17:42:14 +0100, Chris Morgan <chmorgan(a)gmail.com> > wrote: > > > I'm going to have to side with Vitaliy on this one. I've helped > > dozens of users in #winehq that have had problems with wine due to > > winetools since we made the changes to remove the .config file. > > Apparently winetools has been upgraded to work with 0.9x versions of > > wine, this is great news although I don't think we want to promote > > winetools to users if the authors aren't going to help out in #winehq > > and provide better overall support. > > > > Chris > > > > > > Fair point Chris but didnt you have to help dozens of NON winetools users > due that change as well? > I did have to explain to a lot of users where the .config went and that they need to use winecfg. This was quite a bit easier than trying to figure out if winetools had messed up their configuration. If the winetools guys want to provide support in #winehq and rapid releases to fix issues then I'm all for keeping the link on the downloads page. Otherwise I'd rather not burden the people in #winehq with many users that require support for winetools issues. Another aspect is the large number of users that come into #winehq asking why app 'X' doesn't work under wine after winetools said it would. We are better off setting expectations at a level we know we can meet and not adding a burden to those in #winehq that are trying to provide some kind of user support. Chris

1 0

mscms: unregistered color profiles?
by Saulius Krasuckas 23 Dec '05

23 Dec '05

Hello devs, I see some XP [1] and W2k3 [2] boxes fail on every GetStandardColorSpaceProfileA() using valid parameters until SetStandardColorSpaceProfileA() is called for the first time. Then all those GetStandardColorSpaceProfileA() tests succeed. I guess that mean SPACE_RGB color profile isn't registered on those boxes. Failures are just because of missing GLE codes, but IMHO we need to test this both cases. (when SPACE_RGB is registered and when it's not) The problem is that if we test the unregistered color profile and we register it later using *A functions, then repeating same tests for the *W functions won't do OK, as I found no way to unregister Standard Color Space Profile. Any ideas on how to do that? [1] http://test.winehq.org/data/200512221000/xp_punt/mscms:profile.txt [2] http://test.winehq.org/data/200512221000/2003_w2k3/mscms:profile.txt

2 2

RE: _itow tests in ntdll/tests
by Thomas Mertes 23 Dec '05

23 Dec '05

Hello, I am the author of the _itow tests and the _itow function. As far as I can remember when I tested the _itow functions under WIN2000 and under XP (No SP or just SP1) it was allowed to call _itow with _itow(123, NULL, 10) and the result of this call was NULL. The wine _itow function implemented this functionality because of "bug by bug" compatibility (Some Applications might be based on this "Feature"). The Test was done to find regressions or changes in the M$ operating systems. In my opinion testing corner cases is important. What does "there is failure" mean. Does it crash or return something different from NULL. When it crashes under XP SP2 the function _itow should remain unchanged. When some other value (different from NULL) is returned it might be necessary to change _itow. By the way. The reason I stopped developing for Wine is: I now have my own project: Seed7 In the Seed7 programming language new statements and operators can be declared easily. Functions with type results and type parameters are more elegant than a template or generics concept. Look at wikipedia: http://en.wikipedia.org/wiki/Seed7 or at sourceforge: http://sourceforge.net/projects/seed7 Just download Seed7 and see the new concepts. Greetings Thomas Mertes -- GMX DSL-Flatrate 1 Jahr kostenlos* + WLAN-Router ab 0,- Euro* Bis 31.12.2005 einsteigen! Infos unter: http://www.gmx.net/de/go/dsl

2 1

Re: Wine IE6 and JVM
by Dominic Wise 23 Dec '05

23 Dec '05

On Thu, 2005-12-15 at 17:38 +0200, Adrian Munteanu wrote: > Hi guys, > > I am trying to use wine with IE 6. > Most of the pages are displaying fine, however the problem is with pages > requesting JVM running. > So could you please help me find away, if available, to make IE use > installed JVM? > > Thanks and best regards > Adrian > > > Have you tried latest winetools? I ask because it worked for me with IE6 .It has been updated to the 0.9 wine version. Hope this helps, Dom

1 0

Re: msiexec null reference
by Mike McCormack 23 Dec '05

23 Dec '05

Bill Medland wrote: > + static const WCHAR dfv[] = { > + 'M','S',' ','S','h','e','l','l',' ','D','l','g',0 }; > + if (!dialog->default_font) > + { > + DWORD len = strlenW (dfv) + 1; > + dialog->default_font = msi_alloc(len*sizeof(WCHAR)); > + if (!dialog->default_font) return -1; > + memcpy (dialog->default_font, dfv, len*sizeof(WCHAR)); > + } How about this? if (!dialog->default_font) dialog->default_font = msi_strdupW( dfv ); Mike

2 1

Poser label issue [Bug 2737]
by Vikram Kumar 23 Dec '05

23 Dec '05

Hi, I've been looking into Bug 2737 http://bugs.winehq.org/show_bug.cgi?id=2737 and kind of lost on where to go next. Testing on both Poser5 English and Poser6 Japanese versions, The labels (text) on the ui don't show up. As far as the rest of the app goes, Poser 5 seems to be working okay excpet for some redraw issues, so if the lables show up correctly, the app should be quite useable. Anyway, looking at the trace, it looks like it uses DrawTextEx to draw the lables, does something with regions which I can't quite figure out, and renders the ui. The issue seems to be that the label somewhere along the line becomes a 1bit DIB which seems to be wrong. x11drv/dib gives a warning saying: warn:bitmap:X11DRV_DIB_GetImageBits_1 from unknown 1 bit bitmap (ff0000,ff00,ff) to 1 bit DIB, direct color mapping What I tried was to force a negative image on x11drv/dib.c by changing line 901 to: -BYTE neg = 0; +BYTE neg = 1; The attached image shows the result. The black rectangles are where the labels are supposed to be (This is the Poser6 Japanese's register your name & serial number etc dialog) It looks like the DIB is all white (thus the blackness when negating). If I use the non-negated image, this part becomes the same color as the background(transparent?) What the lables are supposed to look like can be found here: http://bugs.winehq.org/attachment.cgi?id=768&action=view and how wine does it is: http://bugs.winehq.org/attachment.cgi?id=767&action=view I'm kind of stuck at this point, not knowing exactly what to do next. I'd aprreciate any help, since it will be nice to have this running. Poser6 demo is available here: http://downloads.e-frontier.com/us/user/product.php?productid=12045&cat=134… Also attached is a trace of WINEDEBUG="+font,+text,+gdi,+bitmap,+seh" wine PoserJ.exe Cheers, Vik

2 1

Re: Use the new RtlExitUserThread function instead of exporting
by Saulius Krasuckas 23 Dec '05

23 Dec '05

With this change [*] header does not compile under MSVC 6: --- include/winternl.h +++ include/winternl.h @@ -1985,6 +1985,7 @@ BOOL WINAPI RtlEqualPrefixSid(PSID, BOOL WINAPI RtlEqualSid(PSID,PSID); BOOLEAN WINAPI RtlEqualString(const STRING*,const STRING*,BOOLEAN); BOOLEAN WINAPI RtlEqualUnicodeString(const UNICODE_STRING*,const UNICODE_STRING*,BOOLEAN); +void WINAPI RtlExitUserThread(ULONG) DECLSPEC_NORETURN; NTSTATUS WINAPI RtlExpandEnvironmentStrings_U(PWSTR, const UNICODE_STRING*, UNICODE_STRING*, ULONG*); LONGLONG WINAPI RtlExtendedMagicDivide(LONGLONG,LONGLONG,INT); LONGLONG WINAPI RtlExtendedIntegerMultiply(LONGLONG,INT); Moving DECLSPEC_NORETURN to before a WINAPI keyword helps. [*] http://source.winehq.org/git/?p=wine.git;a=blobdiff;h=ee582be9bc8ae5797b762…

1 0

Re: advpack: fix LaunchInfSection[Ex] documentation
by James Hawkins 23 Dec '05

23 Dec '05

On 12/22/05, Markus Amsler <markus.amsler(a)oribi.org> wrote: > > - * show [I] How the window should be shown. > + * show [I] Reboot behaviour: > + * 'A' reboot always > + * 'I' default, reboot if needed > + * 'N' no reboot > * Where are you getting this behavior from? Microsoft's public header advpub.h does not include this information, and while that doesn't mean we shouldn't include it either, it would be nice to see tests for this behavior, either in the form of an app that displays the behavior or preferably tests in wine's test suite. -- James Hawkins

2 2

Re: Bug 3885
by Tom Spear 22 Dec '05

22 Dec '05

Aric Cyr wrote: >>>I took a look at the D3D_OK hack, and I believe the problem to be >>>CheckDeviceFormat in wined3d/directx.c. This function should return an error if >>>D3DFMT_D32 is checked for on cards which don't support 32bit depth. Currently >>>it just returns OK for most formats though. This code is really just a stub as >>>it stands, and needs to be converted to check if there are any visuals that meet >>>the requested format's requirements, and if there is, return D3D_OK, otherwise >>>D3D_NOTAVAILBLE. >>> >>>To test my theory, try returning D3D_NOTAVAILABLE for the D3DFMT_D32 case >>>(you'll need to add it) in wined3d/directx.c in IWineD3DImpl_CheckDeviceFormat() >>>and see if that fixes that issue or not. This would be just another hack >>>though, so a real patch would still be necessary as I decribed above. Well I took a stab at adding the case for D3DFMT_D32, to the bottom of the other cases, and let it return the D3DERR_NOTAVAILABLE (as opposed to D3D_NOTAVAILABLE), and ran the benchmarks again.. Now it finishes the first one and then goes to do the second one, but crashes in a different spot, so it seems we also have some stack corrupion (as was mentioned in the bug).. So that hack works for now, I would suggest that since the rest of that code is stubbed out, we should probably go ahead and submit a patch so we can at least run the darn thing and then start debugging the stack corruption issue. I should add that on the first run, I disabled the title screens between benchmarks, and changed the "Display and CPU Settings" so that I was using 32-bit textures and triple buffering, and it ran thru several of the tests, while on the 2nd and 3rd runs, I left all settings at defaults; during run 2, it died just after the title screen for mark #2, and during run 3, it died in the middle of mark #2...

4 3

ATI Opengl regression (DRI?)
by Jesse Allen 22 Dec '05

22 Dec '05

Hi, It seems that the patch git-1399edb0925966a802a6a39835025c22c22c18e1.patch found here http://www.winehq.org/pipermail/wine-cvs/2005-December/019731.html causes an opengl regression on my system. With the patch loading War3 causes X Error of failed request: GLXUnsupportedPrivateRequest Major opcode of failed request: 143 (GLX) Minor opcode of failed request: 17 (X_GLXVendorPrivateWithReply) Serial number of failed request: 429 Current serial number in output stream: 429 Which seems to stop the game loading thread and causes the game to use the fail-safe thread "Please insert disc", so the game wont load. Reversing the patch fixes the problem. I have a Radeon 9200 using DRI snapshots about 20051024. X Window System Version 6.8.99.901 (6.9.0 RC 1) (Minimal DRI build from X.org tr ee) Release Date: 18 October 2005 + cvs X Protocol Version 11, Revision 0, Release 6.8.99.901 Build Operating System: Linux 2.6.14-rc5 i686 [ELF] Current Operating System: Linux tesore 2.6.15-rc4-git1 #1 PREEMPT Fri Dec 2 17:0 3:32 MST 2005 i686 Build Date: 28 October 2005 Is this a DRI problem? Thanks, Jesse

3 5

Resent: [opengl] fix last wgl regression
by Raphael 22 Dec '05

22 Dec '05

Resent resync patch with little correction Regards, Raphael On Thursday 15 December 2005 23:59, Raphael wrote: > Hi, > > Thix patch should fix last wgl patch regression > anyway i don't understand why ATI drivers don't support older GLX 1.3 specs > (as 1.4 is already here). > > For glXGetFBConfigs i don't plan to support a compatibility code, > it should be too buggy (on pixel format selection) as was older opengl code > as we can't query visuals > > Changelog: > - fix wgl regression: test glx server version and extensions to use (and > not use glXQueryDrawable on older glx implementations) > > Regards, > Raphael

1 0

Poser label issue [Bug 2737]
by Vik Kumar 22 Dec '05

22 Dec '05

1 0

Need help fixing deadlock (GDI)
by Cihan Altinay 22 Dec '05

22 Dec '05

Hi, I have spent days finding the reason for PowerPoint 2000 causing a deadlock if a file is opened that contains a preview which itself contains a bitmap >90x90 pixels (ie. on the first slide). After inserting some more traces I feel I am pretty close but I'm stuck now. The problem is connected to GDI's StretchBlt (bitblt.c). It calls MFDRV_StretchBlt and then the trouble begins as can be seen from the output: <snip> trace:bitblt:StretchBlt --Start-- trace:gdi:GDI_GetObjPtr (0x3b0c): enter 1 trace:dc:DC_GetDCPtr trace:gdi:GDI_ReleaseObj (0x3b0c): leave 1 trace:gdi:GDI_GetObjPtr (0x3aec): enter 1 trace:dc:DC_GetDCPtr trace:gdi:GDI_GetObjPtr (0x3b0c): enter 2 trace:dc:DC_GetDCPtr trace:bitblt:StretchBlt 0x3aec 0,0 160x120 -> 0x3b0c 0,0 960x720 rop=cc0020 trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 trace:dc:DC_GetDCPtr trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 trace:gdi:GetObjectW 0x3af8 24 0x7fc2f760 trace:gdi:GDI_GetObjPtr (0x3af8): enter 3 trace:gdi:GDI_ReleaseObj (0x3af8): leave 3 trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 trace:dc:DC_GetDCPtr trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 trace:dc:DC_GetDCPtr trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 trace:dc:DC_GetDCPtr trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 trace:metafile:MFDRV_StretchBlt MF_StretchBltViaDIB->len = 20292 rop=cc0020 PixYPM=3780 Caps=96 trace:bitmap:GetDIBits trace:dc:CreateCompatibleDC --Checking lock-- hdc=0x3aec err:syslevel:_CheckNotSysLevel Holding lock 0x7fad49e0 level 3 </snip> Yes well... hdcDst and hdcSrc aren't freed yet from within StretchBlt. There is this comment "FIXME: there is a race condition here"... is that the cause? Btw. this might be the same problem as bug #3125. Can somebody give me a hint on how to tackle this? If you need more output please let me know. Thanks a lot, Cihan

1 0

_itow tests in ntdll/tests
by Paul Vriens 21 Dec '05

21 Dec '05

Hi, I was just diving into this as there is failure for months with this test on Winxp-SP2 and W2K3. We call _itow, like this: result = p_itow(ulong2str[0].value, NULL, 10); This however seems not be allowed anymore. Changing it to WCHAR buffer[LARGE_STRI_BUFFER_LENGTH + 1]; result = p_itow(ulong2str[0].value, buffer, 10); make the test succeed, but I don't know what the author wanted with these tests. Any ideas ? Cheers, Paul.

1 0

Poser label issue [Bug 2737]
by Vikram Kumar 21 Dec '05

21 Dec '05

1 0

Re: sound enabled but no driver checked
by Cihan Altinay 21 Dec '05

21 Dec '05

Robert Reif wrote: > Cihan Altinay wrote: > >> Quoting Robert Reif <reif(a)earthlink.net>: >> >> >> >>> Cihan Altinay wrote: >>> >>> >>> >>>> With a fresh wine prefix sound is enabled but I can't >>>> see which driver is used because none of them is checked >>>> in the new winecfg sound dialog. >>>> Did we forget to initialize the boxes on first run? >>>> >>>> Cheers, >>>> Cihan >>>> >>>> >>> >>> Use regedit to show HKCU/Software/wine/Drivers/Audio. >>> Chances are it's empty (no drivers checked) so sound is >>> disabled. It could be set to a driver that is not available >>> but winecfg checks for that and should give you an error. >>> >> >> >> Well... the key doesn't exist unless I run winecfg at least once >> and change something. In that case it's not really important because >> a user will probably do that anyway. >> The only minor issue would be that someone runs winecfg for the first >> time and is satisfied with the defaults (no driver checked -> sound off) >> so without any changes he dismisses winecfg. And in this case it seems >> one of the drivers is used by default (sound on). >> >> Cheers, >> Cihan >> >> >> >> > I have a patch to fix this. OSS is the default if there is no registry > key. Great! Will you submit it?

1 0

Re: has the LGPL licence fell through ? (forw)
by Joerg Mayer 21 Dec '05

21 Dec '05

as a simple reply isn't sent to the list.... ----- Forwarded message from Joerg Mayer <jmayer(a)loplof.de> ----- Date: Wed, 21 Dec 2005 09:22:11 +0100 From: Joerg Mayer <jmayer(a)loplof.de> To: Aric Cyr <Aric.Cyr(a)gmail.com> Subject: Re: has the LGPL licence fell through ? In-Reply-To: <loom.20051221T082013-24(a)post.gmane.org> On Wed, Dec 21, 2005 at 07:48:09AM +0000, Aric Cyr wrote: > Maybe I'll fire off an email to Turbolinux to see what they have to say, > although technically unless I purchase or receive their product I am not > directly entitled to the GPL/LGPL code from them. Anyone have a copy of Can you please let me know why you think that? ---------------------------- 2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) The modified work must itself be a software library. b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change. c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License. ... ------------------------------- So I guess if they are using some code of yours that you provided to them under LGPL, you are entiteld to request the source. In case this goes to court you'll need a copy, but for now it is sufficient to be sure that they are distributing a product based on your code which is covered by the LGPL. Again: It is *you* who granted them the right to use your code, and by putting it under LGPL you made sure that you are entitled to any changes they make to *the* code once they start distributing your code (or derivatives) to thrid parties. That way you can reqeust the changes even when the new product costs $10M. Ciao Joerg -- Joerg Mayer <jmayer(a)loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ----- End forwarded message ----- -- Joerg Mayer <jmayer(a)loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology.

2 1

Bug 3885
by Tom Spear 21 Dec '05

21 Dec '05

Hi, I was working on bug 3885 tonight, and am stuck now.. Could someone take a look and test a couple of things? I'm running 2.6 series kernel, and it keeps dieing into the debugger before the main window opens. I think that it will sart with builtin msvcrt with 2.4 series kernel, but not 2.6, but since I'm in the middle of another project, I cant reboot to find out. It will at least start under both series for sure with native msvcrt. Louis Lenders removed a trace line from wine and recompiled and it started, even with builtin, which is kinda weird, since he didnt run it with any traces. So it may be a combination of a bug in that trace, and a bug in the 2.6 kernel.. Once running the app, with either builtin or native msvcrt, it goes thru the first benchmark and then spits out an error dialog box when it goes to start the next one, regardless of which benchmarks the app is told to test.. IOW, you can tell it to run #1 and #2, and it will spit out the error before starting #2, and take you back to the main app window. Or you can tell it to run #1 and #3, and same happens, or you can tell it to run #2 and #3, and same happens, so its not something to do with the way wine is handling the benchmark itself. Louis also hard coded D3D_OK into wine in the right spot and managed to get the program to go thru all benchmarks from 1-16, so wine is mis-reporting something there. If someone could take a look and propose a fix, it would be appreciated, seems to me that the 2 fixes should be fairly trivial to come up with since those 1 line hacks worked to get around the aforementioned problems. If we can get it to start on 2.4 and 2.6 with builtin and get it to go all the way to mark 16 before it spits out an error, then that will be another bug closed, and I will file a separate one for mark 16.. Tom

2 1

[wined3d] Code questions
by Aric Cyr 21 Dec '05

21 Dec '05

I just have a couple wined3d code questions/comments that I'd like to clear up and possible submit patches if my understanding is correct. If I am misunderstanding the code please correct me. 1) basetexture.c:BindTexture() Just _before_ we call glBindTexture we call glTexParameteri and either set GL_TEXTURE_MAX_LEVEL or GL_TEXTURE_MIN_FILTER. The comment in the code is: "Always need to reset the number of mipmap levels when rebinding as it is a property of the active texture unit, and another texture may have set it to a different value" However, this doesn't make any sense to me and I believe it to be incorrect. glTexParameter affects the currently bound texture object. If the current and next texture to be bound have different mipmaps levels or parameters it should not be necessary to change these settings as all the state is encapsulated correctly in the OpenGL texture object, which should have been initialized correctly in Device::CreateTexture or BaseTexture::ApplyStateChanges. The reason the current code is bad is two-fold: 1) unneeded state changes on a performance critical path, as texture binding is very frequent and 2) changing the state of a _previous_ texture object, not the current one. The next time we go to use that texture object we will have to reapply all of it's state again, another waste of time. I spent a lot of the weekend debugging wined3d (trying to get anisotropic working in World of Warcraft) and just commenting out the block of code greatly cut down on d3d trace messages and makes the code easier to understand (and faster). 2) device.c::SetupTextureStates() Similar to my previous remark, there seems to be an incorrect state change here as well. glTexEnvf(TEXTURE_FILTER_CONTROL, LOAD_BIAS), glBlendColor() and then glTexEnvfv(TEXTURE_ENV, TEXTURE_ENV_COLOR) are called. All of these are called for each texture state update. However these are all global render states, not per-texture contrary to the comment in the code. Since these states are already being set in Device::SetRenderState() I'm pretty sure they don't need to be set here as well. Well that's all for now. Having started to really dig into wined3d, it seems that some effort in cleaning it up (coding style is way off) and stablizing it before it gets much more unwieldy is due. I'm also willing to help with such a task if there is a consensus that it should be done. Regards, Aric

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel