March 2014 - Wine-Devel - list.winehq.org

Mass effect 2 - Bink movies freezes game

by Tomas Gustavsson

Hi! Have tried for a while to get Mass Effect 2 working through Wine and though it's very playable for me it has a large drawback, I have to disable all movie playbacks with the -nomoviestartup argument. If I don't, the game freezes up and I can hear the sound stuck in a loop - it does not unfreeze itself. By looking through AppDB it seems that there are a large group of people that doesn't have this problem. I assume it's either related to my processor (AMD A10-6700) or GPU (HD5770, Catalyst driver)? I have tried to several Wine versions but it didn't help. The interesting thing is that there are many Windows users with the exact problem. Here's a link http://answers.ea.com/t5/Mass-Effect-2/Can-t-run-ME2-without-nomoviestartup…. So though the game works rather well, an important part (and some locations in the game supposedly breaks when you use nomoviestartup) is lost when movies are turned off, at least for me. Is there any way to debug the bink movie playback functionality? Because I really would like to be able to play the game without losing the ability to watch the ingame movies. Best regards /Tomas Gustavsson

March 21, 2014

Add a program to Wine Programs menu

by Robson

Hello, I saw the post below with a way to add a program to Wine Programs menu: https://answers.launchpad.net/ubuntu/+source/wine/+question/148594 Suggestion: add a tab in the configuration interface of wine to add remove or edit program shortcuts. With that the User can easily and quickly organize your shortcuts to favorite programs. Thanks.

March 21, 2014

Re: Advice fixing #13683 (DirectX mouse overlay?)

by Matteo Bruni

2014-03-21 10:14 GMT+01:00 Stefan Dösinger <stefandoesinger(a)gmail.com>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am 2014-03-21 03:24, schrieb Christopher Thielen: >> apitrace is really neat, thanks for pointing it out. I ran it on >> Windows XP with the Ultima IX (GOG edition) and generated a trace - >> which shows the missing mouse cursor - then rebooted into Linux and >> ran the Windows version of apitrace's GUI using the same .trace >> file and it _did_ also show the mouse cursor, running under Wine. > It means one thing for sure: The cursor is not a user32 cursor. > Otherwise it would not show up in the captures. > > I have two theories: Either the game looks at the d3d capabilities > (CheckDeviceFormat, GetDeviceCaps, mostly IDirect3D9 methods) and > concludes that something is missing, enters a bad codepath and does > not draw the pointer. > > Or some function unrelated to d3d does not work and the game fails to > read the pointer from its resources. > > Since this is a glide application running through a glide wrapper the > second case is much more likely. (Unless my memory is completely broken) > > You can compile wined3d for Windows. The basic idea is to set > CFLAGS=-DUSE_WIN32_OPENGL and compile it with mingw on Windows, or > Cross-Compile it from Linux. I also have a hacky Visual Studio 2013 > based build setup, but you'll have a hard time generating a binary > that works on Windows XP with that. With a Win32 build of wined3d.dll > and our d3d9.dll you can run the game on Windows with our d3d code. If > the pointer shows up in that case this demonstrates that it is not a > d3d issue. If it does not, it shows that the issue is a capability > flag problem. > >> Also, I don't know apitrace that well, but is the per-frame >> 'texture' tab only showing textures utilized in that frame, not >> counting anything already in the framebuffer? I couldn't find the >> cursor texture after looking at about two dozen frames, but then >> again, I didn't find most textures using that method. > No idea :-( > I never used apitrace on D3D traces, I assume it works in the same fashion as on GL ones. The 'texture' tab shows the textures bound to the texture units at that point in time, each one of them might or might not be used by the draw call you're examining. You should check the shaders (or the state of the fixed function pipeline, if no shaders are bound) to know which of those textures are actually used by the draw you're looking into. What you can do at this point is to go through the draw calls of a frame, looking for the one which draws the cursor (I would do that just by looking at the framebuffer contents). Then run the game in Wine + apitrace and see if you can find the same draw in the GL trace. Either the draw is there, in which case you can look into why it doesn't draw anything, or the call is totally missing, which would support the hypothesis of the bad caps / wrong game codepath.

March 21, 2014

Re: GSoC 2014 proposal - Implement VBScript built-in functions

by Shuai Meng

Thank you! I will. 2014-03-21 17:52 GMT+08:00 Jacek Caban <jacek(a)codeweavers.com>: > Hi Shuaimeng, > > On 03/20/14 12:33, 孟帅 wrote: >> Hi all! >> I'm Shuai Meng, a student from software school of Beihang University, >> China, GMT+08:00. I'm pursuing a master degree and now in grade one. >> You can call me shuaimeng, that's my nickname used in irc. Now I'm >> here to apply for GSoC to work for Wine. I'm familiar with C, and I >> can code with python as well. Besides, I know a little about html and >> vbscript. From May to August, I have plenty of free time. >> >> About one year ago I started my way to linux, it's not smooth for a >> person who had got used to windows then embrace linux. Soon I got a >> problem: QQ(the most popular IM software in China) doesn't support >> linux, but I really need it. Fortunately I knew wine through searching >> google, it helped me solve this problem.Since then I have become a >> wine user. >> >> In the past three months, I had focused on dlls/vbscript/global.c, >> searching MSDN for related documents[1]~[4]. Accordding those >> documents, I added more tests in dlls/vbscript/tests/api.vbs, then got >> some similar bugs and only reported one[5]. In order to fix them, I >> read wine source code in dlls/vbscript/global.c, again and again. >> Finally I finished a few draft patches[6] and I will send them to >> wine-patches later. >> >> As I have made so much effort in this module and gain a little >> experience, during GSoC this part will go on to occupy most of my >> attention. On the basis of difficulty to be implemented, I divide all >> the functions in dlls/vbscript/global.c into four groups as following: >> >> 1: Abs ScriptEngine ScriptEngineBuildVersion ScriptEngineMajorVersion >> IsArray IsDate IsNumeric IsObject Sgn TypeName VarType >> >> These are the easiest to implement, I will take about one week to >> finish the unimplemented. >> >> 2: FormatCurrency FormatDateTime FormatPercent Hour FormatNumber Join >> Minute Month Oct Rnd Second Space TimeValue Year >> >> The second group will occupy two weeks of the whole GSoC time. They >> are not as easy as the first group and there are more to be >> accomplished. Most of them are involved in time functions while a few >> is about strings. >> >> 3: Asc Ant Cos DateAdd DateDiff DatePart DateSerial Day Exp LBound Log >> Replace Sin Sqr String Tan TimeSerial UBound Weekday CBool CByte CCur >> CDate CDbl CInt CLng CSng CStr InStrRev Int Fix StrComp Timer >> >> These are more difficult. However a large part is conversion functions >> and they have been implemented or improved by me. You can find the >> details in attchment. Optimistically speaking, I need at least three >> weeks to complete all of them. When I finish that, this bug[7] will be >> fixed. >> >> 4: Array Date DateValue Escape Eval Filter GetLocale GetRef InputBox >> LoadPicture Now RGB SetLocale >> Split Time Unescape >> >> Here come the most difficult ones. I am not so sure whether I can fix >> or even understand them, but I will try my best. Maybe after I have >> finish the above three groups, I can gain a little confidence to face >> them. This group would cost me four weeks or even longer. If I have a >> good luck, maybe I can fix this bug[8]. >> >> To be prudent, I'll spare at least one week to do a review on all my >> codes. Write a summary as a guidence for my work to be continued after >> GSoC. >> >> Though I have a rough plan now, as a greenhand to wine, I hava too >> much to learn and I badly need advice from all of you. I hope I can >> make a proper schedule after communicating with my mentor. >> >> Any comment or advice is greatly appreciated. >> Thank you! > > I like the plan and schedule seems right, esp. about starting with > easier functions and move to harder ones as the project progresses. > Patches that you attached show that you already have an understanding of > the code involved (they will need some adjustments, but let's leave > that's for another thread). Make sure to submit application in GSoC > system. The deadline is today! > > Cheers, > Jacek

March 21, 2014

Re: GSoC 2014 proposal - Implement VBScript built-in functions

by Jacek Caban

Hi Shuaimeng, On 03/20/14 12:33, 孟帅 wrote: > Hi all! > I'm Shuai Meng, a student from software school of Beihang University, > China, GMT+08:00. I'm pursuing a master degree and now in grade one. > You can call me shuaimeng, that's my nickname used in irc. Now I'm > here to apply for GSoC to work for Wine. I'm familiar with C, and I > can code with python as well. Besides, I know a little about html and > vbscript. From May to August, I have plenty of free time. > > About one year ago I started my way to linux, it's not smooth for a > person who had got used to windows then embrace linux. Soon I got a > problem: QQ(the most popular IM software in China) doesn't support > linux, but I really need it. Fortunately I knew wine through searching > google, it helped me solve this problem.Since then I have become a > wine user. > > In the past three months, I had focused on dlls/vbscript/global.c, > searching MSDN for related documents[1]~[4]. Accordding those > documents, I added more tests in dlls/vbscript/tests/api.vbs, then got > some similar bugs and only reported one[5]. In order to fix them, I > read wine source code in dlls/vbscript/global.c, again and again. > Finally I finished a few draft patches[6] and I will send them to > wine-patches later. > > As I have made so much effort in this module and gain a little > experience, during GSoC this part will go on to occupy most of my > attention. On the basis of difficulty to be implemented, I divide all > the functions in dlls/vbscript/global.c into four groups as following: > > 1: Abs ScriptEngine ScriptEngineBuildVersion ScriptEngineMajorVersion > IsArray IsDate IsNumeric IsObject Sgn TypeName VarType > > These are the easiest to implement, I will take about one week to > finish the unimplemented. > > 2: FormatCurrency FormatDateTime FormatPercent Hour FormatNumber Join > Minute Month Oct Rnd Second Space TimeValue Year > > The second group will occupy two weeks of the whole GSoC time. They > are not as easy as the first group and there are more to be > accomplished. Most of them are involved in time functions while a few > is about strings. > > 3: Asc Ant Cos DateAdd DateDiff DatePart DateSerial Day Exp LBound Log > Replace Sin Sqr String Tan TimeSerial UBound Weekday CBool CByte CCur > CDate CDbl CInt CLng CSng CStr InStrRev Int Fix StrComp Timer > > These are more difficult. However a large part is conversion functions > and they have been implemented or improved by me. You can find the > details in attchment. Optimistically speaking, I need at least three > weeks to complete all of them. When I finish that, this bug[7] will be > fixed. > > 4: Array Date DateValue Escape Eval Filter GetLocale GetRef InputBox > LoadPicture Now RGB SetLocale > Split Time Unescape > > Here come the most difficult ones. I am not so sure whether I can fix > or even understand them, but I will try my best. Maybe after I have > finish the above three groups, I can gain a little confidence to face > them. This group would cost me four weeks or even longer. If I have a > good luck, maybe I can fix this bug[8]. > > To be prudent, I'll spare at least one week to do a review on all my > codes. Write a summary as a guidence for my work to be continued after > GSoC. > > Though I have a rough plan now, as a greenhand to wine, I hava too > much to learn and I badly need advice from all of you. I hope I can > make a proper schedule after communicating with my mentor. > > Any comment or advice is greatly appreciated. > Thank you! I like the plan and schedule seems right, esp. about starting with easier functions and move to harder ones as the project progresses. Patches that you attached show that you already have an understanding of the code involved (they will need some adjustments, but let's leave that's for another thread). Make sure to submit application in GSoC system. The deadline is today! Cheers, Jacek

March 21, 2014

Regarding GSoC

by Ashwani Agarwal

Hello, I've submitted my proposal for GSoC 2014 on Tools - Winetest Graphical User Interface. Can someone review it, so if there is any changes to make, can be done. and also can I know who is the potential mentor for this project? So I can contact him and proceed further.

March 21, 2014

Re: Advice fixing #13683 (DirectX mouse overlay?)

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-03-21 03:24, schrieb Christopher Thielen: > apitrace is really neat, thanks for pointing it out. I ran it on > Windows XP with the Ultima IX (GOG edition) and generated a trace - > which shows the missing mouse cursor - then rebooted into Linux and > ran the Windows version of apitrace's GUI using the same .trace > file and it _did_ also show the mouse cursor, running under Wine. It means one thing for sure: The cursor is not a user32 cursor. Otherwise it would not show up in the captures. I have two theories: Either the game looks at the d3d capabilities (CheckDeviceFormat, GetDeviceCaps, mostly IDirect3D9 methods) and concludes that something is missing, enters a bad codepath and does not draw the pointer. Or some function unrelated to d3d does not work and the game fails to read the pointer from its resources. Since this is a glide application running through a glide wrapper the second case is much more likely. (Unless my memory is completely broken) You can compile wined3d for Windows. The basic idea is to set CFLAGS=-DUSE_WIN32_OPENGL and compile it with mingw on Windows, or Cross-Compile it from Linux. I also have a hacky Visual Studio 2013 based build setup, but you'll have a hard time generating a binary that works on Windows XP with that. With a Win32 build of wined3d.dll and our d3d9.dll you can run the game on Windows with our d3d code. If the pointer shows up in that case this demonstrates that it is not a d3d issue. If it does not, it shows that the issue is a capability flag problem. > Also, I don't know apitrace that well, but is the per-frame > 'texture' tab only showing textures utilized in that frame, not > counting anything already in the framebuffer? I couldn't find the > cursor texture after looking at about two dozen frames, but then > again, I didn't find most textures using that method. No idea :-( > I did run an apitrace of Ultima IX (GOG edition) on Linux for kicks > but I don't think it'll help much. There is a factor of about 4x as > many calls per frame when running under Wine FYI, but I'm assuming > the Wine D3D folks are already aware of that sort of issue. Did you run the Linux apitrace? In this case you'll see OpenGL calls instead of d3d calls. Or did you use the Windows apitrace version inside Wine? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTLALzAAoJEN0/YqbEcdMw+MwP/i4WI7mGcAY6mWTgo/e1bONl ZiU/ArT5oE4G4LIbZOubGblk4zw6D/v4/g3b8JRICXdjGmtb/1GDk7ZnryZG8Jki 9kQe0Mbbo4IU29oT0c1LHvoUUlo/k0zWUQo6zO/EuBw2IHAxpuVAVS8+wt+Is1vy n9r4hg0+Z0nUXokfeVfABZBL5SoIqBfEJJlcVkbcMi5u8GC1ECSlnBRt32ruq1AM 80bfKazsWcjUd8BseNGHf5YBbWynI9gqB/uKUxyeqiyEst7Os5gq/56pqbTbAGeV ZX9ssKC+EEdPR1fbHxOXsTpjA+NmNkpaKcEUwTqyHHGlYe6rtAxCiGxYSh9U/8UO c+0gmS+X9927HqVEgaSsNrYgSTsKQJst/EKsHswPn0EzBh56S0WLFlob26o5+Zct 9jelDv9JlRWe3isZiWgUkyFTqF2XAkN3sFUaMfMhi+I9Ubhhmq22Uw/70FvkTPkT ycDG/sK6udr1CgR3Fvnvf/72T4+mXr7eZGegQU85uBeS0ElzZlNMKz2AuiLc8wC7 VtntG0Q2EB7m4bx9mf3BJOGPv2nZXB8QDevw6pH6YoQGCurELro2354CZDj/XG32 bV5ILnpZzuAZnpzJBQWVH7ejLlWI3k5jbPiyj8NundU1Tm/BUX12xbd7VraVxCY2 sEtMFuun1519NcUk+JTc =21NT -----END PGP SIGNATURE-----

March 21, 2014

Re: wintab: Incorrectly classifying cursor as stylus instead of eraser

by Michael Stefaniuc

On 03/21/2014 10:04 AM, Eriks Dobelis wrote: > To be able to prioritize we have to change current functions into smth > like this: > > get_cursor_type(cursor) { //new function > can we determine type based on cursor.device? Yes -> return > CSR_TYPE_PEN; > can we determine type based on cursor.name? Yes -> return > CSR_TYPE_ERASER; > return CSR_TYPE_OTHER; > } > > and rewriting is_stylus and is_eraser into more simple functions like > is_stylus(cursor) { > return get_cursor_type(cursor) == CSR_TYPE_PEN; > } In that case you could actually get rid of the is_* functions; "get_cursor_type(cursor) == CSR_TYPE_PEN" is as readable. bye michael > > > On 2014.03.21. 10:54, Alexandre Julliard wrote: >> Eriks Dobelis <eriks.dobelis(a)biti.lv> writes: >> >>> The alternative - just to switch order of checks in >>> X11DRV_LoadTabletInfo. There is a code fragment: >>> /* prefer finding TYPE_PEN(most capable) */ >>> if (is_stylus(target->name, device_type)) >>> cursor.TYPE = CSR_TYPE_PEN; >>> else if (is_eraser(target->name, device_type)) >>> cursor.TYPE = CSR_TYPE_ERASER; >>> else >>> cursor.TYPE = CSR_TYPE_OTHER; >>> >>> I would need to switch order and check for ERASER first. Problems >>> would arise if for some device name would be "Pen & Eraser", and type >>> would be "STYLUS" , and then it would be detected as eraser. In the >>> proposed patch this problem would not arise as only device is checked >>> for ERASER. For my specific case both approaches work. Which one you >>> consider as better? >> Maybe a better way would be to restructure the checks, and give priority >> to the type over the name or something like that. The thing is that we >> don't want to have an is_stylus function that also checks for erasers, >> and then an is_eraser function with slightly different checks. >> > > > -- Michael Stefaniuc Tel.: +49-711-96437-199 Supervisor, APAC/EMEA IT Network Fax.: +49-711-96437-111 -------------------------------------------------------------------- Reg. Adresse: Red Hat GmbH, Werner-von-Siemens-Ring 14, 85630 Grasbrunn Handelsregister: Amtsgericht Muenchen HRB 153243 Geschäftsführer: Mark Hegarty, Charlie Peters, Michael Cunningham, Charles Cachera

March 21, 2014

Re: wintab: Incorrectly classifying cursor as stylus instead of eraser

by Eriks Dobelis

To be able to prioritize we have to change current functions into smth like this: get_cursor_type(cursor) { //new function can we determine type based on cursor.device? Yes -> return CSR_TYPE_PEN; can we determine type based on cursor.name? Yes -> return CSR_TYPE_ERASER; return CSR_TYPE_OTHER; } and rewriting is_stylus and is_eraser into more simple functions like is_stylus(cursor) { return get_cursor_type(cursor) == CSR_TYPE_PEN; } On 2014.03.21. 10:54, Alexandre Julliard wrote: > Eriks Dobelis <eriks.dobelis(a)biti.lv> writes: > >> The alternative - just to switch order of checks in >> X11DRV_LoadTabletInfo. There is a code fragment: >> /* prefer finding TYPE_PEN(most capable) */ >> if (is_stylus(target->name, device_type)) >> cursor.TYPE = CSR_TYPE_PEN; >> else if (is_eraser(target->name, device_type)) >> cursor.TYPE = CSR_TYPE_ERASER; >> else >> cursor.TYPE = CSR_TYPE_OTHER; >> >> I would need to switch order and check for ERASER first. Problems >> would arise if for some device name would be "Pen & Eraser", and type >> would be "STYLUS" , and then it would be detected as eraser. In the >> proposed patch this problem would not arise as only device is checked >> for ERASER. For my specific case both approaches work. Which one you >> consider as better? > Maybe a better way would be to restructure the checks, and give priority > to the type over the name or something like that. The thing is that we > don't want to have an is_stylus function that also checks for erasers, > and then an is_eraser function with slightly different checks. >

March 21, 2014

Re: wintab: Incorrectly classifying cursor as stylus instead of eraser

by Alexandre Julliard

Eriks Dobelis <eriks.dobelis(a)biti.lv> writes: > The alternative - just to switch order of checks in > X11DRV_LoadTabletInfo. There is a code fragment: > /* prefer finding TYPE_PEN(most capable) */ > if (is_stylus(target->name, device_type)) > cursor.TYPE = CSR_TYPE_PEN; > else if (is_eraser(target->name, device_type)) > cursor.TYPE = CSR_TYPE_ERASER; > else > cursor.TYPE = CSR_TYPE_OTHER; > > I would need to switch order and check for ERASER first. Problems > would arise if for some device name would be "Pen & Eraser", and type > would be "STYLUS" , and then it would be detected as eraser. In the > proposed patch this problem would not arise as only device is checked > for ERASER. For my specific case both approaches work. Which one you > consider as better? Maybe a better way would be to restructure the checks, and give priority to the type over the name or something like that. The thing is that we don't want to have an is_stylus function that also checks for erasers, and then an is_eraser function with slightly different checks. -- Alexandre Julliard julliard(a)winehq.org

March 21, 2014