wine-bugs October 2016

wine-bugs@winehq.org

1 participants
7792 discussions

[Bug 33211] New: C&C: Red Alert 2 still runs very slowly and mouse cursor flickers
by wine-bugs＠winehq.org 22 Feb '25

22 Feb '25

http://bugs.winehq.org/show_bug.cgi?id=33211 Bug #: 33211 Summary: C&C: Red Alert 2 still runs very slowly and mouse cursor flickers Product: Wine Version: 1.5.25 Platform: x86 OS/Version: Mac OS X Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d AssignedTo: wine-bugs(a)winehq.org ReportedBy: brymaster(a)gmail.com Classification: Unclassified The game runs slowly, especially while moving the cursor in-game. I've tried various winetricks configs with: ddr=opengl/ddr=gdi, rtlm=readtex, orm=backbuffer as well as setting a flag in ra2.ini for [Video]VideoBackBuffer=no - nothing works. Even looked at a 'lag fix' here that does nothing: http://www.stuffhost.de/files/cnc/CnCPatcher.html >From looking at past related issues (http://bugs.winehq.org/show_bug.cgi?id=2784, http://bugs.winehq.org/show_bug.cgi?id=5526, http://bugs.winehq.org/show_bug.cgi?id=14438), I get the feeling that someone was trigger happy and 'CLOSED FIXED' these without actually testing - people are still reporting its a problem. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

2 27

[Bug 40738] New: Notepad open file dialog does not remember its location
by wine-bugs＠winehq.org 22 Feb '25

22 Feb '25

https://bugs.winehq.org/show_bug.cgi?id=40738 Bug ID: 40738 Summary: Notepad open file dialog does not remember its location Product: Wine Version: 1.9.11 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: gur.stavi(a)gmail.com Distribution: --- Reproduced in notepad when using File->Open... dialog. In Windows if dragging the open file dialog to a new location, on the next time it is opened it will be opened at the same location. In Wine it is always opened at the top left corner of the application. This is quite inconvenient on a big screen with maximized app. Note that when resizing the dialog, wine does remember the size on the next open so hopefully the position could be a slight extension to this. Regards, Gur -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

2 3

[Bug 39474] New: MSWT Kart 2004 does not work
by wine-bugs＠winehq.org 21 Feb '25

21 Feb '25

https://bugs.winehq.org/show_bug.cgi?id=39474 Bug ID: 39474 Summary: MSWT Kart 2004 does not work Product: Wine Version: 1.7.53 Hardware: x86-64 URL: http://www.gamershell.com/download_5628.shtml OS: Linux Status: NEW Keywords: download Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: 00cpxxx(a)gmail.com Distribution: Debian Download and install the game, after the intro videos the game will crash while loading bitmaps. The crash happens shortly after a BMP image is loaded. This is a continuation of bug 21012. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

2 15

[Bug 25872] New: dxdiag doesn't support /t option, needed by Guild Wars 'test system' button
by wine-bugs＠winehq.org 21 Feb '25

21 Feb '25

http://bugs.winehq.org/show_bug.cgi?id=25872 Summary: dxdiag doesn't support /t option, needed by Guild Wars 'test system' button Product: Wine Version: 1.3.12 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: programs AssignedTo: wine-bugs(a)winehq.org ReportedBy: dank(a)kegel.com This is the next problem after bug 25871. Guild wars installs nicely, but if you press 'test system', you see ... fixme:dxdiag:ProcessCommandLine /t unimplemented -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

2 14

[Bug 39057] New: Support for Indexed Vertex Blending
by wine-bugs＠winehq.org 21 Feb '25

21 Feb '25

https://bugs.winehq.org/show_bug.cgi?id=39057 Bug ID: 39057 Summary: Support for Indexed Vertex Blending Product: Wine Version: 1.7.47 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs(a)winehq.org Reporter: swswine(a)gmail.com Distribution: --- Created attachment 52025 --> https://bugs.winehq.org/attachment.cgi?id=52025 Patch to implement indexed vertex blending support Vertex blending support has been added recently (https://bugs.winehq.org/show_bug.cgi?id=6955 was closed). But indexed vertex blending is not supported yet. I've implemented rather straightforward patch to do it which works for me, it is attached. Though I am far not familiar with wined3d development and not quite sure that my patch is complete and does not have any caveats. A potential caveat with this patch is the following. Besides using indexes in vertex shaders, a big enough number of supported vertex blend matrices is required to really support this Direct3D feature. It was 4 in 1.7.47, I changed to 128 using the same framework developed in 1.7.47. It may potentially fail on some graphic cards due to large number of uniforms in vertex shader generated. Besides the transfer of those uniforms may probably be optimized not to call glUniformMatrix for every matrix when only one or few has changed. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

2 133

[Bug 32572] New: Alpha Polaris doesn't play well with built-in d3dx9 libraries
by wine-bugs＠winehq.org 21 Feb '25

21 Feb '25

http://bugs.winehq.org/show_bug.cgi?id=32572 Bug #: 32572 Summary: Alpha Polaris doesn't play well with built-in d3dx9 libraries Product: Wine Version: 1.5.20 Platform: x86 URL: http://www.gamershell.com/download_75822.shtml OS/Version: Linux Status: NEW Keywords: download Severity: minor Priority: P2 Component: directx-d3dx9 AssignedTo: wine-bugs(a)winehq.org ReportedBy: gyebro69(a)gmail.com CC: wine-bugs(a)winehq.org Classification: Unclassified Created attachment 42985 --> http://bugs.winehq.org/attachment.cgi?id=42985 terminal output The game comes with native d3dx9_34.dll installed in the game directory, the reported problems happen only when you set it to built-in. wine-1.5.20-57-gdabde6a or newer is needed to test this bug (a follow-up to bug #27627). The game starts and loads to the menu fine with the built-in d3dx9_34 but you will face several issues throughout the game. Install the demo then start it with AlphaPolaris.exe. Click <OK> in the launcher and get in the game. Start a new game from the menu, skip the intro video. Here are some issues I noticed with built-in d3dx: - anytime you press a key (either in the menu or in mid-game) a black bar appears in the upper left corner. An error message from the game engine (Wintermute) is hiding behind those black bars, as I've seen those in the game from bug #29495. "Script runtime error. View log for details". - the game begins with a conversation but dialogues/subtitles are displayed so fast that you can hardly read them. Probably due to this, most of the audio (speech) is missing from the game. - when the opening conversation ends you should see the main character standing in front of his bed. With built-in d3dx the character is missing (invisible). - the game tends to crash on exit as can be seen in the attached log file. All those issues are non-existent when d3dx9_34=native. Saved games that were created with built-in d3dx9_34 are also affected. If you load a saved game created with built-in, those issues are present, even if the game was started with native. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

2 17

[Bug 19153] New: DX3 game does not recognize graphics capabilities
by wine-bugs＠winehq.org 21 Feb '25

21 Feb '25

http://bugs.winehq.org/show_bug.cgi?id=19153 Summary: DX3 game does not recognize graphics capabilities Product: Wine Version: 1.1.24 Platform: PC URL: http://appdb.winehq.org/objectManager.php?sClass=versi on&iId=9396 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-ddraw AssignedTo: wine-bugs(a)winehq.org ReportedBy: bobbyg(a)gmx.net Resident Evil 1 does not start giving the error "Failed to initialize the Graphics Hardware Device.(3)". It's a DirectX 3 game using immediate mode. After some debugging I found that it relies on 3 (three) entries returned by EnumDevices whereas wine returns only the Direct3D HAL entry in this case (d3dversion == 1). Removing the if-clause in ddraw/direct3d.c and duplicating the HAL entry solves the problem and the game actually runs almost perfectly (Garbage -> Platinum). I checked a Windows installation which returns "HAL", "RGB Emulation" and "Ramp Emulation" but the comments in the file suggest that not all games are happy about that. So how to fix this properly? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

2 50

[Bug 27002] New: Shadow Company: Left for Dead fails with "No usable 3D Devices installed".
by wine-bugs＠winehq.org 21 Feb '25

21 Feb '25

http://bugs.winehq.org/show_bug.cgi?id=27002 Summary: Shadow Company: Left for Dead fails with "No usable 3D Devices installed". Product: Wine Version: 1.3.18 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: cfiend(a)talent.edu.pl Shadow Company: Left for Dead shows a messagebox with text "No usable 3D Devices installed. Exiting." on startup. Googling for more information suggests that it needs a Glide wrapper to work. However, I failed to get the game working with either OpenGlide, dgVoodoo and Zeckensack's Glide Wrapper. Tried putting dll files in game dir, in windows/system32 dir, setting overrides in winecfg, running on a virtual desktop and many different combinations of the above on two machines: one equipped with Intel graphics card, the other with rather old (~5 years) NVidia GeForce graphics card running binary blob drivers. Wine console output spews a few fixmes about EnumDisplayDevicesW stub. Attaching log below. Failure occurs in full version as well as in demo version of the game. Link to demo version: http://www.fileplanet.com/10258/download/Shadow-Company-Demo I'll gladly provide additional information on request. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

2 25

[Bug 24308] New: Fullscreen fails for MechWarrior 4 games (Only one D3D device per DirectDraw object)
by wine-bugs＠winehq.org 21 Feb '25

21 Feb '25

http://bugs.winehq.org/show_bug.cgi?id=24308 Summary: Fullscreen fails for MechWarrior 4 games (Only one D3D device per DirectDraw object) Product: Wine Version: 1.3.2 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-ddraw AssignedTo: wine-bugs(a)winehq.org ReportedBy: georg298(a)gmx.de For all MechWarrior 4 games, fullscreen fails with message fixme:ddraw:d3d7_CreateDevice Only one Direct3D device per DirectDraw object supported. Obviously, the game falls back to window'ed mode, as static HRESULT WINAPI d3d7_CreateDevice(IDirect3D7 *iface, REFCLSID riid, IDirectDrawSurface7 *surface, IDirect3DDevice7 **device) returns DDERR_INVALIDPARAMS changing this behaviour (returning D3D_OK instead): if (ddraw->d3ddevice) { FIXME("Only one Direct3D device per DirectDraw object supported.\n"); LeaveCriticalSection(&ddraw_cs); return D3D_OK; // return DDERR_INVALIDPARAMS; } makes fullscreen work for these games. Probably it's not "legal" to return D3D_OK in this case, but maybe there is a real solution for this problem? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

2 26

[Bug 10522] New: endless WM_PAINT loop bug (update regions, queue paint count)
by wine-bugs＠winehq.org 17 Feb '25

17 Feb '25

http://bugs.winehq.org/show_bug.cgi?id=10522 Summary: endless WM_PAINT loop bug (update regions, queue paint count) Product: Wine Version: CVS/GIT Platform: PC URL: http://www.microsoft.com/whdc/devtools/debugging/install x86.mspx OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: wine-user AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Created an attachment (id=9265) --> (http://bugs.winehq.org/attachment.cgi?id=9265) trace with WINEDEBUG=+tid,+message,+win,+server Hello, I've seen this bug a while ago in other apps but ignored it because it was not easily to reproduce. Well until recently when I tested some stuff with windbg from "Debugging Tools for Windows" (Microsoft). I used debugging tools version 6.8.4.0 and recent GIT (wine-0.9.49-302-g58b85bb). Immediately when a child window was opened using toolbar (register, locals, .. whatever), windbg would become unresponsive, eating most CPU. Happens in both GUI modes - "floating/docking toolwindow" and "MDI emulation. Though "MDI emulation" is more obvious, it actually shows the endless refreshing (window caption). Attached is WINEDEBUG=+tid,+message,+win,+server log. Additionally I added a trace message which prints the current queue paint count (when incremented or fetched) which makes some things easier to spot. Printed as "inc_queue_paint_count: %d" and "get_message_paint_count: %d". The window hierarchy is as follows: --- snip --- *root*=0x10020 Shell_TrayWnd=0x10022 WinDbgFrameClass=0x10024 DockClass=0x10026 ToolbarWindow32=0x10028 msctls_statusbar32=0x1002a tooltips_class32=0x1002e WinBaseClass=0x10030 ToolbarWindow32=0x10032 SysListView32=0x10034 SysHeader32=0x10036 RichEdit20W=0x10038 --- snip --- After the child windows are created the queue paint count never drops to zero, resulting in endless WM_PAINT processing. Maybe some update (region) code path missed or flags problem? I played a bit with ignoring null region updates and it seemed to help a bit (preventing endless WM_PAINT loop) though other stuff wasn't drawn properly then. Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 41

← Newer
1
2
3
4
5
6
7
...
780
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-bugs October 2016