wine-devel July 2009

wine-devel@winehq.org

116 participants
249 discussions

win users please test DirectX9_AutoGenFilterType patch
by Joerg-Cyril.Hoehle＠t-systems.com 11 Jul '09

11 Jul '09

Dear users of MS-Windows with access to a compiler, please compile the following addition to the Wine testsuite and report results of running on MS-Windows to me by e-mail (preferred) or to this list. The goal is to get rid of bug http://bugs.winehq.org/show_bug.cgi?id=11167 For that I need test data from MS-Windows systems. Maybe some more || broken(D3DTEXF_POINT == fltt) are needed for the tests to pass on some MS-Windows systems/gfx-drivers with limited filter types. Once proper MS-Windows behaviour is known, the patch to Wine will follow. Currently Wine fails the test below. http://msdn.microsoft.com/en-us/library/bb174327(VS.85).aspx diff --git a/dlls/d3d9/tests/texture.c b/dlls/d3d9/tests/texture.c index 4d433b1..29864a8 100644 --- a/dlls/d3d9/tests/texture.c +++ b/dlls/d3d9/tests/texture.c @@ -197,6 +197,21 @@ static void test_mipmap_gen(IDirect3DDevice9 *device) D3DFMT_X8R8G8B8, D3DPOOL_MANAGED, &texture, 0); ok(hr == D3D_OK, "IDirect3DDevice9_CreateTexture failed(%08x)\n", hr); + if (texture) { + D3DTEXTUREFILTERTYPE fltt; + fltt = IDirect3DTexture9_GetAutoGenFilterType(texture); + ok(D3DTEXF_LINEAR == fltt, "GetAutoGenFilterType returned default %d\n", fltt); + hr = IDirect3DTexture9_SetAutoGenFilterType(texture, D3DTEXF_NONE); + ok(hr == D3DERR_INVALIDCALL, "SetAutoGenFilterType D3DTEXF_NONE returned %08x\n", hr); + hr = IDirect3DTexture9_SetAutoGenFilterType(texture, D3DTEXF_ANISOTROPIC); + ok(hr == D3D_OK, "SetAutoGenFilterType D3DTEXF_ANISOTROPIC returned %08x\n", hr); + fltt = IDirect3DTexture9_GetAutoGenFilterType(texture); + ok(D3DTEXF_ANISOTROPIC == fltt /*|| broken(D3DTEXF_POINT == fltt)*/, + "GetAutoGenFilterType returned %d\n", fltt); + hr = IDirect3DTexture9_SetAutoGenFilterType(texture, D3DTEXF_LINEAR); + ok(hr == D3D_OK, "SetAutoGenFilterType D3DTEXF_LINEAR returned %08x\n", hr); + /* IDirect3DTexture9_GenerateMipSubLevels ? */ + } levels = IDirect3DTexture9_GetLevelCount(texture); ok(levels == 1, "Got %d levels, expected 1\n", levels); Thanks for your help, Jörg Höhle

3 2

MaxVertexBlendMatrices issue
by Karl Vogel 11 Jul '09

11 Jul '09

Just tracked down a crash in the game Dark Age of Camelot (daoc) when pixelshaders are enabled. The game issues a GetDeviceCaps() and then checks if MaxVertexBlendMatrices >= 4, which on wine is set to zero on my videocard (Geforce 6800), whereas a windows box returns 4. I found this old post concerning MaxVertexBlendMatrices causing issues in another game (EQ): http://www.winehq.org/pipermail/wine-devel/2008-February/062432.html http://www.winehq.org/pipermail/wine-devel/2008-February/062437.html So I was wondering what the proper way to fix this would be? Should this be made overrideable by a registry setting for certain games? Or should the GL check be changed? Or is that software emulated vertex blending patch needed to correctly fix the issue? Bugzilla has 3 other games where the simple 'fix' of returning 4 makes the game work (Warhammer, EQ, Shin Megami Tensei Online): http://bugs.winehq.org/buglist.cgi?quicksearch=MaxVertexBlendMatrices -- For reference the daoc bug is http://bugs.winehq.org/show_bug.cgi?id=10832

1 0

GSoC mid-term evaluations due
by Kai Blin 11 Jul '09

11 Jul '09

Hi GSoC students and mentors, Just a little reminder that you need to fill out your GSoC surveys by monday. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

1 0

[2/2] msxml3: Register Missing Components
by Lady Bug 11 Jul '09

11 Jul '09

2 1

Re: [1/2](resend)advapi: break the core of LookupAccountNameW out into helper functions.
by Juan Lang 10 Jul '09

10 Jul '09

Hi Aric, it strikes me that this could be broken up a bit further. This'd make it rather easier to review. For example, --- a/dlls/advapi32/advapi32_misc.h +++ b/dlls/advapi32/advapi32_misc.h @@ -24,4 +24,15 @@ const char * debugstr_sid(PSID sid); BOOL ADVAPI_IsLocalComputer(LPCWSTR ServerName); BOOL ADVAPI_GetComputerSid(PSID sid); +BOOL lookup_local_wellknown_name(LPCWSTR lpAccountName, DWORD ccAccountName, + PSID Sid, LPDWORD cbSid, + LPWSTR ReferencedDomainName, + LPDWORD cchReferencedDomainName, + PSID_NAME_USE peUse, BOOL *ret); +BOOL lookup_local_user_name(LPCWSTR lpAccountName, DWORD ccAccountName, + PSID Sid, LPDWORD cbSid, + LPWSTR ReferencedDomainName, + LPDWORD cchReferencedDomainName, + PSID_NAME_USE peUse, BOOL *ret); In the initial patch, these aren't referenced outside of security.c, so leaving them static there would make the changes smaller. A subsequent patch that does reference them from lsa.c could make them non-static. +static inline WCHAR *strnrchrW(const WCHAR *str, WCHAR ch, DWORD *len) It's not clear to me what this function does from its name, and you didn't document it. There's no corresponding strnrchr libc function, so that doesn't help either. It appears from reading it that you made a function like strrchrW that returns the location of the found ch in str, like strrchrW does, but also sets *len to the position at which it's found? If that's correct, you could accomplish the same thing by calling strrchrW and doing pointer arithmetic with its return value. These suggestions notwithstanding, it seems like introducing this helper function is one change, and deserving of its own patch. + +/* + * Helper function for LookupAccountNameW and LookupNames2 in lsa.c The second part of that comment, that it's a helper for LookupNames2, isn't correct in this first patch. It becomes true later, but the comment should be changed then, not in the first patch. (Minor nit: mentioning the file LookupNames2 is in seems superfluous.) + * returns TRUE if the AccountName is handled (even if with an error). + * returns FALSE if not. + */ + +BOOL lookup_local_wellknown_name(LPCWSTR lpAccountName, DWORD ccAccountName, + PSID Sid, LPDWORD cbSid, + LPWSTR ReferencedDomainName, + LPDWORD cchReferencedDomainName, + PSID_NAME_USE peUse, BOOL *ret) The use of two BOOLs is confusing to me. For one thing, it makes the patch larger: - ret = CreateWellKnownSid(ACCOUNT_SIDS[i].type, NULL, pSid, &sidLen); + *ret = CreateWellKnownSid(ACCOUNT_SIDS[i].type, NULL, pSid, &sidLen); This change could be avoided if you returned the old meaning of ret, and used the BOOL * parameter to indicate whether the AccountName is handled. Finally, I'd suggest that breaking out looking up well known names could be separate from breaking out looking up local names. Hope that helps, --Juan

1 0

Re: winemine: Add ellipses for menu entries that open new dialog windows (DE)
by Paul Vriens 10 Jul '09

10 Jul '09

Detlef Riekenberg wrote: > There are more winemine translations without the ellipses. > Can the changes all in one Patch? > > There are non UTF8 - resources with special characters. > Should they change to UTF8 first? > > > > > ------------------------------------------------------------------------ > > Hi Detlef, There is patch in the queue that actually gets rid of some ellipses as there was a discussion about this on wine-devel. -- Cheers, Paul.

1 0

Warnings on the translation page
by Paul Vriens 10 Jul '09

10 Jul '09

Hi, I found an anomaly on the translations page. Whenever the Makefile shows a generic rc file (last one added for RC_SRCS) the language before that shows warnings on the page. Example: http://source.winehq.org/transl/lang.php?lang=004%3A01 zh (Chinese (Traditional)) shows up most of the warning as the entries in the Makefile are sorted. Not sure yet, if this is an issue with wrc or transl. -- Cheers, Paul.

2 4

Wine very very slow in Chinese language of Linux
by axel_xia＠sohu.com 10 Jul '09

10 Jul '09

Dear Madam / Sir, How are you? I am writing email to you for the issue probably caused by Chinese fonts. When using WINE in Chinese environment Linux, the WINE works very very slow even opening windows / clicking buttons.... I search the problem in google, found lots of users have same issue regardless Fedora or Ubuntu or other distributed Linux OS. Someone presented the resolution by changing Chinese fonts configuration because they think WINE is always searching suitable GKB font sets (which sometimes are not exisiting in Linux OS), someone said it was related to X11 (not compatiable or some linux OS not using X11)..., and others guess the issue related to other reason..... So, dear Madam / Sir, could you please help the WINE fans who are using Linux in Chinese environment to figure out this kind of issue? Or is that possible to put the fixed WINE into Yum or someother software database? Hopefully, the user of different distributed Linux can be of no issue when WINE M$ software in Chinese? Thanks and best regards! Yours sincerely, Axel

1 0

Re: wined3d: Fix some checkGLcalls.
by Henri Verbeet 10 Jul '09

10 Jul '09

Most of those looked good enough to me to begin with, but I guess it doesn't hurt.

1 0

Re: Check if WINED3DRS_VERTEXBLEND is dirty in transform_world
by Henri Verbeet 09 Jul '09

09 Jul '09

2009/7/5 Lisa Denia <eiffel56(a)gmail.com>: > This fixes the flickering cursor mentioned in Bug > #14375(http://bugs.winehq.org/show_bug.cgi?id=14375). > The cursor flickers because the scene gets rendered twice a draw, which is > known and expected. The cursor is not one of that usual animated 2d things, > but a 3d object. So, in every draw, the scene gets rendered, the cursor gets > rendered, and the scene gets rendered again. The attached patch checks for > that special case. > It's not entirely clear to me why this should work.

2 1

← Newer
1
...
13
14
15
16
17
18
19
...
25
Older →

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 July 2009