Re: mpr: Changes comparison of dwScope in WNetOpenEnum function
Hi Konstantin, - providerTable->table[index].dwEnumScopes & dwScope) + providerTable->table[index].dwEnumScopes & WNNC_ENUM_GLOBAL) This change looks correct, but it should be changed in the next block as well: ret = providerTable->table[index].openEnum( dwScope, dwType, dwUsage, lpNet, &handle); It also looks incorrect in _enumerateGlobalPassthroughW: ret = providerTable->table[enumerator->providerIndex]. openEnum(enumerator->dwScope, enumerator->dwType, enumerator->dwUsage, enumerator->lpNet, &enumerator->handle); In fact, all of these usages of dwScope look to confuse the two meanings. (D'oh.) --Juan
Re: CryptAcquireContext Failure, default/Type 024 requested
Sweet! Thanks! I'll see what I can do and probably end up asking some more specific questions later ;) Rob On 9/24/07, Juan Lang <[EMAIL PROTECTED]> wrote: > > I found the wincrypt.h #define line that says what type 024 > > is: #define PROV_RSA_AES 24. > > In that case, it should be straightforward enough to add an AES > implementation to Wine's rsaenh.dll. There's free (as in speech) > source available for it. Take a look at rsaenh.c and implglue.c in > dlls/rsaenh; you'd want to add it as a new block cipher. > > --Juan >
Re: shdocvw: Added WebBrowser::FullScreen property implementation.
On 23/09/2007, Jacek Caban <[EMAIL PROTECTED]> wrote: > --- > dlls/shdocvw/shdocvw.h |1 + > dlls/shdocvw/tests/webbrowser.c | 23 +++ > dlls/shdocvw/webbrowser.c | 15 +++ > 3 files changed, 35 insertions(+), 4 deletions(-) > +hres = IWebBrowser2_get_FullScreen(wb, &b); > +ok(hres == S_OK, "get_FullScreen failed: %08x\n", hres); > +ok(b == VARIANT_TRUE, "b=%x\n", b); > + > +hres = IWebBrowser2_put_FullScreen(wb, VARIANT_FALSE); > +ok(hres == S_OK, "put_FullScreen failed: %08x\n", hres); > + > IWebBrowser2_Release(wb); This last call to put_FullScreen is missing a get_FullScreen check. Everything else looks ok. - Reece
Re: [OT] Freemail Terms Of Use [was: Wine autorunner]
On 23/09/2007, Stefan Dösinger <[EMAIL PROTECTED]> wrote: > Am Sonntag, 23. September 2007 01:42:46 schrieb Computer Dude: > _ > > Connect to the next generation of MSN Messenger > > http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source= > >wlmailtagline > This is OT regarding this patch, but most people use freemailers, including > hotmail / msn. Some service providers tried to establish some > all-your-copyright-belong-to-us terms of service. Should we take care about > that in any way? Either by making sure that patches aren't sent from such > services, or to make sure that such conditions do not hold up in court? > > I am using gmx myself, and I haven't checked the TOS for changes since years, > and I only gave them a 5 secound look when signing up, so I should start with > checking that myself(I send most patches from my CW address though) Reading the current GoogleMail terms of usage, there is this: "Your Intellectual Property Rights. Google does not claim any ownership in any of the content, including any text, data, information, images, photographs, music, sound, video, or other material, that you upload, transmit or store in your Google Mail account. We will not use any of your content for any purpose except to provide you with the Service." so there is no problem there. Also, the hotmail legal statement has this: "8. Your Materials. You may be able to submit materials for use in connection with the service. Except for material that we license to you, we do not claim ownership of the materials you post or otherwise provide to us related to the service (called a "submission"). However, by posting or otherwise providing your submission, you are granting to the public free permission to: * use, copy, distribute, display, publish and modify your submission, each in connection with the service; * publish your name in connection with your submission; and * grant these permissions to other persons. This section only applies to legally permissible content and only to the extent that use and publishing of the legally permissible content does not breach the law. We will not pay you for your submission. We may refuse to publish, and may remove your submission from the service at any time. For every submission you make, you must have all rights necessary for you to grant the permissions in this section." So you should also be fine there as well, although I do find it interesting that according to this (if I have read it correctly), anything that you send via hotmail is freely usable by the public! - Reece
Re: CryptAcquireContext Failure, default/Type 024 requested
> I found the wincrypt.h #define line that says what type 024 > is: #define PROV_RSA_AES 24. In that case, it should be straightforward enough to add an AES implementation to Wine's rsaenh.dll. There's free (as in speech) source available for it. Take a look at rsaenh.c and implglue.c in dlls/rsaenh; you'd want to add it as a new block cipher. --Juan
Re: wtsapi32: add stub for WTSRegisterSessionNotification
Anything wrong with these simple stubs? http://www.winehq.org/pipermail/wine-patches/2007-September/043944.html and http://www.winehq.org/pipermail/wine-patches/2007-September/043945.html ? - Yahoo! Answers - Get better answers from someone who knows. Tryit now.
Re: mlang: fix memory leaks in error path (found by Smatch).
Tijl Coosemans wrote: > On Monday 24 September 2007 14:20:51 Lionel_Debroux wrote: >> ConvertINetString leaks some heap memory in an error path. Found in >> Michael Stefaniuc's list of Wine potential bugs detected by Smatch. >> >> 2007-09-24 Lionel Debroux <[EMAIL PROTECTED]> >>* dlls/mlang/mlang.c: >>mlang: fix memory leaks in error path (found by Smatch). >> >> diff --git a/dlls/mlang/mlang.c b/dlls/mlang/mlang.c >> index eb14ad0..c6274c5 100644 >> --- a/dlls/mlang/mlang.c >> +++ b/dlls/mlang/mlang.c >> @@ -635,9 +635,10 @@ HRESULT WINAPI ConvertINetString( >> pDstStrW = HeapAlloc(GetProcessHeap(), 0, cDstSizeW * >> sizeof(WCHAR)); >> hr = ConvertINetMultiByteToUnicode(pdwMode, dwSrcEncoding, pSrcStr, >> pcSrcSize, pDstStrW, &cDstSizeW); >> if (hr != S_OK) >> -return hr; >> +goto cleanup; >> >> hr = ConvertINetUnicodeToMultiByte(pdwMode, dwDstEncoding, >> pDstStrW, &cDstSizeW, pDstStr, pcDstSize); >> +cleanup: >> HeapFree(GetProcessHeap(), 0, pDstStrW); >> return hr; >> } > > This is a bikeshed issue really, but I wonder what Wine's policy on > gotos like this is. Imo, it's better to add the HeapFree call to the if > block and let the compiler work it out. It really depends on the code. If you have a lot of error paths with a lot of cleanup to do in them then gotos are way cleaner and easier to read. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network EngineerFax.: +49-711-96437-111 Reg. Adresse: Red Hat GmbH, Hauptstätter Strasse 58, 70178 Stuttgart Handelsregister: Amtsgericht Stuttgart HRB 153243 Geschäftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Werner Knoblich
Re: Would like to contribute to wine
> > Correct but we don't have it in Wine. If we added the Drv functions, > > while I have the parts of the DIB engine unimplemented, I could > > forward back to the driver alot easier. There is maybe another way, > > but having Drv functions make sense in my mind. > > That would be perfect (IMHO), when our Drivers (winex11, wineps) use > DDI as API. > I dont know our Driver-Code in this Area good enough, but I expect that > this big change need a lot of testing. > > > > > Also, I wonder how your Eng* functions would integrate with the dib > > > > engine I'm writing > > > > > > The main Problem with the Rendering-API in Wine > > > (between GDI and our Drivers: winex11, wineps, mfdrv, enhmfdrv) > > > is more like win3x and far away from DDI (Device Driver Interface). > > > > > > > Do the Eng functions have to be based on DDI? Or can we use it with my > > DIB engine? > > The DIB-Engine on Windows are the main Part behind Eng* and Friends and > MS defined DDI as API for that. > I had no time yet to look in your DIB-Engine. Moving to DDI could mean huge changes. The DDI is documented (for a part on msdn) but for the rest I think in driver docs. Transgaming for instance also used the DDI for their DirectX support but at some stage they didn't continue with it because of changes in licensing. So I would watch out with it. Second if you are interested in this area, I would say skip DDI and start doing things the Vista-way. I'm not sure how DDI works there but in the end everything is layered on top of directx. (of course not the standard ddraw/d3d functions) I would check how Vista is doing things. Roderick -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kanns mit allen: http://www.gmx.net/de/go/multimessenger
Re: Does MWM_DECOR_BORDER really cause window to have caption?
> > Anyway, what is the purpose of setting MWM_DECOR_BORDER to borderless > > window (style is WS_CLIPSIBLINGS only)? KDE, XFCE, fluxbox work OK > > without it. > > If you mean the following line in > dlls/winex11.drv/window.c,X11DRV_set_wm_hints() > > else if (!(style & (WS_CHILD|WS_POPUP))) mwm_hints.decorations |= > MWM_DECOR_BORDER; > > then you can always send a patch with an explanation why it's needed. Of course, I can send a patch, which just removes this line with some explanations (referring to winamp), but I'm afraid it may break something. Since original patch introduced this code, there is an application which depends on this. But that original patch does not contain any hint, so I ask the list in hope somebody might know the reason. -- Kirill
Re: mlang: fix memory leaks in error path (found by Smatch).
"Tijl Coosemans" <[EMAIL PROTECTED]> wrote: > > hr = ConvertINetMultiByteToUnicode(pdwMode, dwSrcEncoding, > > pSrcStr, pcSrcSize, pDstStrW, &cDstSizeW); > > if (hr != S_OK) > > -return hr; > > +goto cleanup; > > > > hr = ConvertINetUnicodeToMultiByte(pdwMode, dwDstEncoding, > > pDstStrW, &cDstSizeW, pDstStr, pcDstSize); > > +cleanup: > > HeapFree(GetProcessHeap(), 0, pDstStrW); > > return hr; > > } > > This is a bikeshed issue really, but I wonder what Wine's policy on > gotos like this is. Imo, it's better to add the HeapFree call to the if > block and let the compiler work it out. In this particular case goto should be avoided IMO by rewriting code snippet like below: if (hr == S_OK) hr = ConvertINetUnicodeToMultiByte(...); -- Dmitry.
Re: mlang: fix memory leaks in error paths (found by Smatch).
Lionel_Debroux wrote:
> EnumRfc1766_create leaks some heap memory in two error paths. Found in
> Michael Stefaniuc's list of Wine potential bugs detected by Smatch.
>
> 2007-09-24 Lionel Debroux <[EMAIL PROTECTED]>
>* dlls/mlang/mlang.c:
>mlang: fix memory leaks in error paths (found by Smatch).
>
>
>
>
>
>>From 394f63633148d76fa322b726218e8a824e5a3930 Mon Sep 17 00:00:00 2001
> From: Lionel Debroux <[EMAIL PROTECTED]>
> Date: Mon, 24 Sep 2007 14:12:10 +0200
> Subject: mlang: fix memory leaks in error paths (found by Smatch).
>
> ---
> dlls/mlang/mlang.c | 13 +++--
> 1 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/dlls/mlang/mlang.c b/dlls/mlang/mlang.c
> index b5b8e0d..eb14ad0 100644
> --- a/dlls/mlang/mlang.c
> +++ b/dlls/mlang/mlang.c
> @@ -1885,7 +1885,11 @@ static HRESULT EnumRfc1766_create(MLang_impl* mlang,
> LANGID LangId,
> data.total = 0;
> data.allocated = 32;
> data.info = HeapAlloc(GetProcessHeap(), 0, data.allocated *
> sizeof(RFC1766INFO));
> -if (!data.info) return S_FALSE;
> +if (!data.info)
> +{
> +HeapFree(rfc);
> +return S_FALSE;
> +}
>
> TlsSetValue(MLANG_tls_index, &data);
> EnumSystemLocalesW(enum_locales_proc, 0/*LOCALE_SUPPORTED*/);
> @@ -1893,7 +1897,12 @@ static HRESULT EnumRfc1766_create(MLang_impl* mlang,
> LANGID LangId,
>
> TRACE("enumerated %d rfc1766 structures\n", data.total);
>
> -if (!data.total) return FALSE;
> +if (!data.total)
> +{
> +HeapFree(data.info);
> +HeapFree(rfc);
> +return FALSE;
> +}
>
> rfc->info = data.info;
> rfc->total = data.total;
Err, screw that. The two first parameters "GetProcessHeap(), 0, " of the
three HeapFree calls are missing...
I did not forget to launch a make process to check my modifications were
correct, though. What happened was that everything was recompiled, and
by the time the compiler complained, I had already sent the mails by
mistake...
Sorry.
Lionel Debroux.
Re: pdh: add tests for XP variant of api call
On Monday 24 September 2007 14:20:12 Jeff Latimer wrote: > > All tests succeed here on 2003 without your patch. > That means that they must be XP specific. I noticed some vista specfic > bugs bugs being reported. The failures on Vista are at least in part different from XPs because of insufficient privileges. > From this we should write tests to accept all values. It would seem > that the wine dll still needs to implement the API accurately, so you > are saying, code the API correctly but make the tests generic? Quote from MSDN on PdhLookupPerfNameByIndex: PDH_INVALID_ARGUMENT A parameter is not valid or is incorrectly formatted. For example, on some releases you could receive this error if the specified size on input is greater than zero but less than the required size. So we should accept this return value too. Our implemention is fine as-is because it still passes the test. Note that there is another problem with the tests which is that performance counter names are localized but the tests assume that the current locale is English. I intend to fix this in my next batch of patches. -Hans
Re: Does MWM_DECOR_BORDER really cause window to have caption?
"Kirill K. Smirnov" <[EMAIL PROTECTED]> wrote: >> There is a distinct MWM hint to add a caption to a window: MWM_DECOR_TITLE. >> If this is proved to be a KDE/XFCE bug it should be reported to an >> appropriate bug tracking system. > > It's better to write pure X11 app to demonstate it, but I am not familiar > with > it :-( You can always take a simple X11 application as a base (I usually take xev.c from X11 sources :-) ) and add the code from winex11.drv. > Anyway, what is the purpose of setting MWM_DECOR_BORDER to borderless window > (style is WS_CLIPSIBLINGS only)? KDE, XFCE, fluxbox work OK without it. If you mean the following line in dlls/winex11.drv/window.c,X11DRV_set_wm_hints() else if (!(style & (WS_CHILD|WS_POPUP))) mwm_hints.decorations |= MWM_DECOR_BORDER; then you can always send a patch with an explanation why it's needed. -- Dmitry.
Re: The Spouse Test
On 9/24/07, Stephan Rose <[EMAIL PROTECTED]> wrote: > That reminds me, one of the things I personally would love to see Wine > support is Solidworks. It's about the only thing at work I still need to > boot into Windows for occasionally. Same here. > Solidworks actually installs now, it didn't earlier this year. And > actually, the most recent version of wine even allows it to run about 5 > seconds longer than the previous version, which is a definite > improvement. =) Which version(s) are you using? Could you please update the AppDB? --tim
Re: mlang: fix memory leaks in error path (found by Smatch).
On Monday 24 September 2007 14:20:51 Lionel_Debroux wrote: > ConvertINetString leaks some heap memory in an error path. Found in > Michael Stefaniuc's list of Wine potential bugs detected by Smatch. > > 2007-09-24 Lionel Debroux <[EMAIL PROTECTED]> >* dlls/mlang/mlang.c: >mlang: fix memory leaks in error path (found by Smatch). > > diff --git a/dlls/mlang/mlang.c b/dlls/mlang/mlang.c > index eb14ad0..c6274c5 100644 > --- a/dlls/mlang/mlang.c > +++ b/dlls/mlang/mlang.c > @@ -635,9 +635,10 @@ HRESULT WINAPI ConvertINetString( > pDstStrW = HeapAlloc(GetProcessHeap(), 0, cDstSizeW * sizeof(WCHAR)); > hr = ConvertINetMultiByteToUnicode(pdwMode, dwSrcEncoding, pSrcStr, > pcSrcSize, pDstStrW, &cDstSizeW); > if (hr != S_OK) > - return hr; > + goto cleanup; > > hr = ConvertINetUnicodeToMultiByte(pdwMode, dwDstEncoding, pDstStrW, > &cDstSizeW, pDstStr, pcDstSize); > +cleanup: > HeapFree(GetProcessHeap(), 0, pDstStrW); > return hr; > } This is a bikeshed issue really, but I wonder what Wine's policy on gotos like this is. Imo, it's better to add the HeapFree call to the if block and let the compiler work it out.
Re: Does MWM_DECOR_BORDER really cause window to have caption?
> "Kirill K. Smirnov" <[EMAIL PROTECTED]> wrote: > > I'm trying to get winamp playlist window to be painted correctly (bug > > #8300). The problem is: > > 0) wine version is git-current. > > 1) winamp playlist window style is WS_CLIPSIBLINGS > > 2) winex11 driver converts it to MWM_DECOR_BORDER hint. (window.c:599) > > 3) This hint behaviour is WM-dependent: > > a) KDE - caption is painted; > > b) XFCE - ditto; > > c) fluxbox - correct (no caption). > > > > This situation confuses a little. I believe DECOR_BORDER does not add a > > caption to window, but it does under great WM such as KDE. Is this > > behaviour correct? If KDE/XFCE is a culprit, should we add a workaround > > into wine? > > There is a distinct MWM hint to add a caption to a window: MWM_DECOR_TITLE. > If this is proved to be a KDE/XFCE bug it should be reported to an > appropriate bug tracking system. It's better to write pure X11 app to demonstate it, but I am not familiar with it :-( Anyway, what is the purpose of setting MWM_DECOR_BORDER to borderless window (style is WS_CLIPSIBLINGS only)? KDE, XFCE, fluxbox work OK without it. -- Kirill
Re: The Spouse Test
On Sun, 2007-09-23 at 00:44 -0700, Dan Kegel wrote: > When will Wine be good enough for the average person to use? > One test is, "Is it good enough to let your spouse migrate to Linux > from Windows?". > My wife's must-have app list is roughly > > Microsoft Office '97 > Adobe Photoshop Elements 1 > Ulead PhotoImpact > Macromedia Dreamweaver 8 > Musicmatch Jukebox 8 > FamilyTreeMaker 2006 > > And you know what? All of those basically work > except for Photoshop Elements. They need some > cosmetic work, and a native DLL or two, and probably a few > obscure bugfixes, but I think that's it. > (I didn't test Office '97, since I expect she'll be using Crossover > for that, as Codeweavers tests that app pretty well.) > > It's possible that by this time next year Wine will pass this test for me. > - Dan That reminds me, one of the things I personally would love to see Wine support is Solidworks. It's about the only thing at work I still need to boot into Windows for occasionally. Solidworks actually installs now, it didn't earlier this year. And actually, the most recent version of wine even allows it to run about 5 seconds longer than the previous version, which is a definite improvement. =) Stephan
Re: pdh: add tests for XP variant of api call
Hans Leidekker wrote: > On Monday 24 September 2007 12:13:50 Jeff Latimer wrote: > > All tests succeed here on 2003 without your patch. That means that they must be XP specific. I noticed some vista specfic bugs bugs being reported. > Even if APIs return > different values on different versions of Windows we should not add version > checks. Instead we should accept all possible return values or remove the > test altogether when it's clear that you cannot depend on specific return > values. > From this we should write tests to accept all values. It would seem that the wine dll still needs to implement the API accurately, so you are saying, code the API correctly but make the tests generic? Jeff
Re: pdh: add tests for XP variant of api call
On Monday 24 September 2007 12:13:50 Jeff Latimer wrote: > This patch adds the variations to the api that XP implements. My > assumption is that these changes will, mostly, be reflected in 2003 and > Vista. I can't check them so if someone could give them a run and let > know, that would be fine. I will get on with adding the variations to pdh.c All tests succeed here on 2003 without your patch. Even if APIs return different values on different versions of Windows we should not add version checks. Instead we should accept all possible return values or remove the test altogether when it's clear that you cannot depend on specific return values. -Hans
Re: pdh: add tests for XP variant of api call
Hans Leidekker wrote:
> On Monday 24 September 2007 12:13:50 Jeff Latimer wrote:
>
>> I will get on with adding the variations to pdh.c
>>
> To prevent you doing any duplicate work, I have implementations
> of PdhCalculateCounterFromRawValue, PdhCollectQueryDataEx and
> PdhValidatePath{,Ex} in my tree, along with a range of tests
That sounds good, I'll confine myself to implementing code for these tests.
Jeff
Re: pdh: add tests for XP variant of api call
On Monday 24 September 2007 12:13:50 Jeff Latimer wrote:
> This patch adds the variations to the api that XP implements. My
> assumption is that these changes will, mostly, be reflected in 2003 and
> Vista. I can't check them so if someone could give them a run and let
> know, that would be fine. I will get on with adding the variations to pdh.c
To prevent you doing any duplicate work, I have implementations
of PdhCalculateCounterFromRawValue, PdhCollectQueryDataEx and
PdhValidatePath{,Ex} in my tree, along with a range of tests.
-Hans
Re: Would like to contribute to wine
On So, 2007-09-23 at 17:15 -0600, Jesse Allen wrote: > Correct but we don't have it in Wine. If we added the Drv functions, > while I have the parts of the DIB engine unimplemented, I could > forward back to the driver alot easier. There is maybe another way, > but having Drv functions make sense in my mind. That would be perfect (IMHO), when our Drivers (winex11, wineps) use DDI as API. I dont know our Driver-Code in this Area good enough, but I expect that this big change need a lot of testing. > > > Also, I wonder how your Eng* functions would integrate with the dib > > > engine I'm writing > > > > The main Problem with the Rendering-API in Wine > > (between GDI and our Drivers: winex11, wineps, mfdrv, enhmfdrv) > > is more like win3x and far away from DDI (Device Driver Interface). > > > > Do the Eng functions have to be based on DDI? Or can we use it with my > DIB engine? The DIB-Engine on Windows are the main Part behind Eng* and Friends and MS defined DDI as API for that. I had no time yet to look in your DIB-Engine. -- By by ... Detlef
Re: Does MWM_DECOR_BORDER really cause window to have caption?
"Kirill K. Smirnov" <[EMAIL PROTECTED]> wrote: > I'm trying to get winamp playlist window to be painted correctly (bug #8300). > The problem is: > 0) wine version is git-current. > 1) winamp playlist window style is WS_CLIPSIBLINGS > 2) winex11 driver converts it to MWM_DECOR_BORDER hint. (window.c:599) > 3) This hint behaviour is WM-dependent: > a) KDE - caption is painted; > b) XFCE - ditto; > c) fluxbox - correct (no caption). > > This situation confuses a little. I believe DECOR_BORDER does not add a > caption to window, but it does under great WM such as KDE. Is this behaviour > correct? If KDE/XFCE is a culprit, should we add a workaround into wine? There is a distinct MWM hint to add a caption to a window: MWM_DECOR_TITLE. If this is proved to be a KDE/XFCE bug it should be reported to an appropriate bug tracking system. -- Dmitry.
Re: Is ICU no longer a dependency of Wine?
Scott Ritchie schreef: > I stumbled across this patch while browsing recent commits: > > http://www.winehq.org/pipermail/wine-cvs/2007-September/036309.html > > Am I correct to say that we no longer need libicu when compiling Wine? > > > By the way, it would be nice if someone shot off an email to wine-devel > whenever the build dependencies change (either removing or adding a lib) > -- it makes it a lot easier on we package maintainers. > Yes. Next time I'll send a message to wine-devel if I change a build dependency. Cheers, Maarten
Does MWM_DECOR_BORDER really cause window to have caption?
Hi, I'm trying to get winamp playlist window to be painted correctly (bug #8300). The problem is: 0) wine version is git-current. 1) winamp playlist window style is WS_CLIPSIBLINGS 2) winex11 driver converts it to MWM_DECOR_BORDER hint. (window.c:599) 3) This hint behaviour is WM-dependent: a) KDE - caption is painted; b) XFCE - ditto; c) fluxbox - correct (no caption). This situation confuses a little. I believe DECOR_BORDER does not add a caption to window, but it does under great WM such as KDE. Is this behaviour correct? If KDE/XFCE is a culprit, should we add a workaround into wine? Thanks for attention -- Kirill
Re: [2/5] WineD3D: Recompile glsl pixelshaders if the sampler format changes
Am Sonntag, 23. September 2007 22:23:06 schrieb Vitaliy Margolen: > Stefan Dösinger wrote: > > > > This patch causes noticeable slowdown in Counter Strike Source stress test > in the first part of it (rotating panels). Testing in dxlevel 80, 1024x768 > fbo, cl_monitors 0. I'm getting ~33 fps in that area before patch and > around 7 fps with this patch. > > Vitaliy. Vitaliy did some more testing on IRC, and it turned out that hl2 switches between D3DFMT_V8U8 and D3DFMT_X8R8G8B8 bump maps. I don't know what hl2 intends with a X8R8G8B8 bump map. I think the best thing to do is to ignore the blue channel difference in V8U8 and put it into the D3DFMT_UNKNOWN conversion group until we find a game that depends on blue = 1.0 If we find a game that runs into problems because of constant recompiling which cannot be avoided, we should keep multiple gl shaders, for each possible setting. I don't want to do this until we need it because managing multiple shaders means overhead too. signature.asc Description: This is a digitally signed message part.
Re: strange pixel format
Am Sonntag, 23. September 2007 05:20:06 schrieb Jose Osvaldo: > The No-CD crack for "The Sims" calls to "IDirectDrawImpl_CreateSurface" > (ddls/ddraw.c) which calls to "IDirectDrawImpl_CreateNewSurface". Is this behavior added by the nocd crack? > The abnormal value is this: > > dwFlags = 0x > dwSize = 32 > dwFourCC = 0x > u1 = 0x > u2 = 0x > u3 = 0x > u4 = 0x > u5 = 0x > > I do not know what is the expected behaviour in real Windows. The original > executable file crashes with other error, but I think that is caused by the > anticopy protection. Can check the full surface description the game passes? Perhaps there are some settings in there that should implicitly provie a pixel format signature.asc Description: This is a digitally signed message part.
