http://bugs.winehq.org/show_bug.cgi?id=26407
Summary: Shadowgrounds Survivor crashes after viewing the map
Product: Wine
Version: 1.3.15
Platform: x86
URL: http://www.gamershell.com/download_23192.shtml
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: gyebro69(a)gmail.com
Created an attachment (id=33629)
--> (http://bugs.winehq.org/attachment.cgi?id=33629)
terminal output
In the game the crash always occurs when I switch back to normal mode after
viewing the map (by pressing <Tab>).
Sometimes the game "survives" 2-3 switches between the two modes but eventually
it will crash.
How to reproduce the problem in the demo:
1. Choose only Physx and Windows Media Codecs when the installer asks for it
(native d3dx9_36.dll will be placed in the game directory).
2. Start the game either by survivor.exe or with the launcher.
3. Choose <New Game> from the menu. When you gain control over your character
press <Tab> to switch to map mode then press <Tab> again to get back to normal
mode. This might need to be repeated 2-3 times. Sooner or later the game will
crash.
If I don't use the map mode, the game seems to be stable (I've played for about
30-40 minutes).
I can reproduce the crash with Wine-1.0.1, too.
The crash happens even if I lower the gfx details to the minimum and with
disabled audio.
When starting the game with WINEDEBUG=warn+heap (is that the correct syntax?)
the crash doesn't occur.
Fedora 14 x86
Nvidia GeForce 250 / driver 260.19.36
--
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.
https://bugs.winehq.org/show_bug.cgi?id=56527
Bug ID: 56527
Summary: Final Fantasy XI Online: Opening movie triggers a
'GStreamer-Video-CRITICAL'.
Product: Wine
Version: 8.7
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winegstreamer
Assignee: wine-bugs(a)winehq.org
Reporter: chiitoo(a)gentoo.org
Regression SHA1: 992984f12c18183e477be9ba2668bf42567f4e0a
Distribution: Gentoo
After 992984f12c1 [1], the opening movie of Final Fantasy XI Online started
triggering a 'GStreamer-Video-CRITICAL' message.
The following is all that happens between launching the game and the movie
starting without any additional channels enabled (everything before the
GStreamer message is probably unrelated).
The movie does still play as it should, as far as I can tell.
----
0164:fixme:msctf:ThreadMgr_ActivateEx Unimplemented flags 0x4
0444:err:d3d:wined3d_fence_wait glClientWaitSync returned 0x911b.
0444:err:d3d:wined3d_context_gl_wait_command_fence Failed to wait for command
fence with id 0x7, ret 0x4.
0444:err:d3d:wined3d_fence_wait glClientWaitSync returned 0x911b.
0444:err:d3d:wined3d_context_gl_wait_command_fence Failed to wait for command
fence with id 0x8, ret 0x4.
044c:err:d3d:wined3d_fence_wait glClientWaitSync returned 0x911b.
044c:err:d3d:wined3d_context_gl_wait_command_fence Failed to wait for command
fence with id 0x3, ret 0x4.
044c:err:d3d:wined3d_fence_wait glClientWaitSync returned 0x911b.
044c:err:d3d:wined3d_context_gl_wait_command_fence Failed to wait for command
fence with id 0x4, ret 0x4.
044c:err:d3d:wined3d_fence_wait glClientWaitSync returned 0x911b.
044c:err:d3d:wined3d_context_gl_wait_command_fence Failed to wait for command
fence with id 0x5, ret 0x4.
044c:err:d3d:wined3d_fence_wait glClientWaitSync returned 0x911b.
044c:err:d3d:wined3d_context_gl_wait_command_fence Failed to wait for command
fence with id 0x6, ret 0x4.
0164:fixme:imm:ImmDisableTextFrameService Stub
0164:fixme:imm:NotifyIME NI_CLOSECANDIDATE
0164:fixme:msctf:ThreadMgr_ActivateEx Unimplemented flags 0x4
(wine:21435): GStreamer-Video-CRITICAL **: 02:43:35.753:
gst_video_info_from_caps: assertion 'gst_caps_is_fixed (caps)' failed
----
Thank you!
1.
https://source.winehq.org/git/wine.git/commitdiff/992984f12c18183e477be9ba2…
--
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.
https://bugs.winehq.org/show_bug.cgi?id=44625
Bug ID: 44625
Summary: Cybernoid 2 exits but x window drawing updates are
frozen
Product: Wine
Version: 3.2
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: dav75uk(a)yahoo.co.uk
Distribution: ---
You can get this game from
https://www.classic-retro-games.com/games/action/cybernoid-2--the-revenge-3…
When you quit the game, x windows no longer updates the screen - events are
being responded to though (you can click stuff then change to a terminal tty
and back and see the updates). The only way to get back to a sane system is
kill xwindows with ctrl alt backspace.
This is seen on opensuse 42.3 which uses xf86
--
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.
https://bugs.winehq.org/show_bug.cgi?id=56429
Bug ID: 56429
Summary: Latest Steam repeatedly restarts when starting game or
alt-tab, seems to be xinput2 related.
Product: Wine
Version: 9.4
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winex11.drv
Assignee: wine-bugs(a)winehq.org
Reporter: ikalvachev(a)gmail.com
Regression SHA1: 0f1322d2df4c5238c601a2865b6e65ad14bfa26a
Distribution: ---
Upgraded to latest wine-9.4 and Steam seemed to work fine.
Then Steam upgraded itself and I couldn't launch games anymore.
When starting a game from withing steam library, the game launch begins
normally. However steam window disappears and the console log bursts messages
until a new window is opened. However this restart kills the started game.
I could reproduce the issue if I simply press ALT+TAB in Steam, however it
doesn't trigger if I change focus with the mouse.
There are not crash reports winedbg starting. It restarts on its own.
I did a bisect and landed on:
---
0f1322d2df4c5238c601a2865b6e65ad14bfa26a
winex11: Support XInput2 events on individual windows.
---
Looking back into the log, before steam window opens,
I can see a couple messages like:
---
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 131 (XInputExtension)
Minor opcode of failed request: 46 ()
Resource id in failed request: 0x80020e
Serial number of failed request: 469
Current serial number in output stream: 491
---
These seems harmless, they appear before steam window is shown.
The following message appears when I trigger the issue with alt+tab:
---
06f8:fixme:winsock:setsockopt Ignoring SO_RANDOMIZE_PORT
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 10 (X_UnmapWindow)
Resource id in failed request: 0x2e00003
Serial number of failed request: 1098
Current serial number in output stream: 1099
06a0:fixme:kernelbase:AppPolicyGetProcessTerminationMethod FFFFFFFA, 0031FECC
0610:fixme:kernelbase:AppPolicyGetProcessTerminationMethod FFFFFFFA, 0031FECC
0024:fixme:file:GetLongPathNameW UNC pathname L"\\\\?\\C:\\Program
Files\\Steam\\bin\\cef\\cef.win7\\steamwebhelper.exe"
0024:fixme:file:GetLongPathNameW UNC pathname L"\\\\?\\C:\\Program
Files\\Steam\\bin\\cef\\cef.win7\\steamwebhelper.exe"
---
The issue happens only with the latest Steam client
Restarts:
---
Steam Beta Branch: Stable Client
Steam Version 1709846872
Steam Client Build Date: Wed, Mar 6 10:31 PM UTC -08:00
Steam Web Build Date: Thu, Mar 7 11:17 PM UTC -08:00
Steam API Version: SteamClient021
---
Since I keep snapshots of previous wine prefixes, I found out that this is the
steam that
Works:
---
Steam Beta Branch: Stable Client
Steam Version 1705108172
Steam Client Build Date: Sat, Jan 13 2:54 AM UTC -08:00
Steam Web Build Date: Fri, Jan 12 7:02 PM UTC -08:00
Steam API Version: SteamClient021
--
I'm using slackware-current
X.Org X Server 1.21.1.11
Running `xinput --version` returns:
---
xinput version 1.6.4
XI version on server: 2.4
---
--
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.
http://bugs.winehq.org/show_bug.cgi?id=31665
Bug #: 31665
Summary: Femap unexpected crash on rebuild database (or any
command that involves it i.e. import)
Product: Wine
Version: 1.5.12
Platform: x86-64
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: dark.schneider(a)iol.it
Classification: Unclassified
Created attachment 41633
--> http://bugs.winehq.org/attachment.cgi?id=41633
Backtrace of crash triggered by file->rebuild in femap 10.3 with wine 1.5.12
1) wine femap.exe
2) file->rebuild...
3) answer yes.
The crash happen with any action that implies a rebuild database by femap. I.e.
if you import a "large" bdf, lunching a rebuild is just a fast way to check if
the bug is present or not.
Wine version I tested without the bug (those are working):
1.0.1
1.1.29
1.3.6
Wine versions i tested with the bug (crash with similar backtrace to one
attached):
1.4.1-2 (from debian repo)
1.5.6-2 (from debian repo)
1.5.12
I have tested with both femap 10.2 and femap 10.3 and they share the same
problem with no difference (i.e. probably the code on their side did not
changed and if someone has an older version around it may show the same bug). I
have not tested Femap 10.3.1, but may show the same problem.
All of this is related to 32 bit version of femap and wine running on a AMD 64
bit system. I have no chance to test 32 bit on 32 bit.
The bug persist on another system with ati/amd video driver, tested with both
open source and closed opposed by this system that has closed source nvidia
blob. Due to this bug seems unrelated to the video rendering (e.g. the problem
with femap not redrawing automatically the gl window looks unrelated, if needed
I can post another bug for that, but it's minor glitch)
Best Regards,
Gabriele Dini Ciacci
P.S.
Unrelated practical thing that make it desirable to have a recent version of
wine working: With 1.5.6-2 and 1.5.12 the program is much faster (especially on
start-up and actually faster than on windows)
--
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.
https://bugs.winehq.org/show_bug.cgi?id=44863
Bug ID: 44863
Summary: Performance regression in Prince of Persia 3D
Product: Wine
Version: unspecified
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: directx-d3d
Assignee: wine-bugs(a)winehq.org
Reporter: stefan(a)codeweavers.com
Distribution: ---
Prince of Persia 3D's performance went from perfectly smooth to about 0.5 fps.
I suspect 0b92a6fba7a6e60c6ff1a3729a3b21019c2df0ce is to blame, but I have not
run a regression test yet.
The problem is that the game creates a rather large (2MB)
D3DVBCAPS_SYSTEMMEMORY, maps it (the entire buffer due to API limitations),
writes a handful of vertices and draws a handful of vertices. Currently wined3d
uploads the entire 2MB, evicts the sysmem copy and downloads it from the GPU
every map / unmap / draw cycle.
The most obvious performance fix is not to create a VBO. Doing this restores
the performance, but questions remain.
On startup, the game writes "NetImmerse D3DDriver Info: Hardware supports
system memory textures" and "NetImmerse D3DDriver Info: No AGP support
detected". The first info seems wrong, so it is possible that the game enters a
codepath it does not choose on Windows.
Not creating a VBO is not an option on Core Contexts, so I investigated what's
going wrong with the PBO codepath on. First of all, evicting the sysmem copy
seems like a bad choice. It happens because ddraw buffers are not marked
dynamic. We may want to chance this. The game uses d3d3, so there's no
DDLOCK_DISCARDCONTENTS. The game passes DDLOCK_WAIT | DDLOCK_WRITEONLY to
IDirect3DVertexBuffer::Lock.
Commenting out the eviction call improves performance quite a bit, but it is
still noticeably slow. wined3d_buffer_map maps through heap_memory instead of
glMapBuffer because of the "(flags & WINED3D_MAP_WRITE) && !(flags &
(WINED3D_MAP_NOOVERWRITE | WINED3D_MAP_DISCARD))" condition.
Removing this condition uses glMapBuffer, but does not improve performance. It
seems the large glMapBuffer is still slow, at least on OSX with legacy
contexts.
So there are a few questions that need to be answered:
*) Is the game using a broken codepath?
*) Write tests for sysmem buffers
*) Consider making all d3d3 buffers dynamic
*) Test if the glMapBuffer path is fast on Linux
*) Investigate if Core Contexts + GL_ARB_buffer_storage help on OSX.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=45358
Bug ID: 45358
Summary: AC Syndicate is completely broken
Product: Wine-staging
Version: 3.10
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: berillions(a)gmail.com
CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com
Distribution: Debian
Created attachment 61658
--> https://bugs.winehq.org/attachment.cgi?id=61658
Graphic rendering completely broken
Hello,
With wine-3.10, it's possible to launch the game without crash.
Now, there is a very big issue with graphic rendering with wined3d. (see
screenshot)
In the output console, i have a lot of message about :
- "d3d_shader:shader_sm4_read_instruction_modifier Unhandled modifier
0xXXXXXXXX" - "err:d3d:wined3d_debug_callback 0x35451990:
"GL_INVALID_OPERATION in glGetUniformLocation(program not linked)""
- "fixme:d3d_shader:shader_glsl_dump_program_source ..."
- "fixme:d3d:context_bind_shader_resources Shader 0x34e90740 needs 34 samplers,
but only 32 are supported."
For Wine dev who want to reproduce the issue, you need wine-staging to avoid
the issue with UPlay (bug #35902) + Wine AND the issue with AC Syndicate +
Uplay with online mode (bug #45312)
Google drive link for the log :
https://drive.google.com/open?id=15Q2gY9uk_JohSwqlhwix9HK8BgUWCY5E
--
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.
https://bugs.winehq.org/show_bug.cgi?id=44009
Bug ID: 44009
Summary: Syberia Gog version: crash after cinematics
Product: Wine
Version: 2.20
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: legluondunet(a)free.fr
Distribution: ---
Created attachment 59671
--> https://bugs.winehq.org/attachment.cgi?id=59671
Syberia Gog wine 2.20 backtrace
Hello,
I just acquire the Syberia Gog version and it is impossible for me to play this
game on Linux with Wine. Happily the game was free.
How to reproduce:
Install Syberia Gog version
Launch the game, you can see cinematics but just when the menu appear the game
crash.
I joined you the terminal log/backtrace.
Config:
Ubuntu 17.10
Nvidia 384.90
--
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.
http://bugs.winehq.org/show_bug.cgi?id=25009
Summary: Password Memory 2010 - Titlebar color rendering error
Product: Wine
Version: 1.3.6
Platform: x86-64
OS/Version: Linux
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: rsflynn(a)gmail.com
Created an attachment (id=31694)
--> (http://bugs.winehq.org/attachment.cgi?id=31694)
Password Memory 2010 Screenshot
Password Memory 2010 v3.0.3
Download URL:
http://download.cnet.com/Password-Memory-2010/3000-18501_4-10770367.html
Titlebar is not rendered correctly. Half the title bar is in the application
default blue, the other half is black.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=55513
Bug ID: 55513
Summary: Paint.NET 3.5.11 runs unstable on Wine 8.x devel
releases
Product: Wine
Version: 8.15
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gdiplus
Assignee: wine-bugs(a)winehq.org
Reporter: kle(a)bluewin.ch
Distribution: ---
Created attachment 75077
--> https://bugs.winehq.org/attachment.cgi?id=75077Paint.NET 3.5.11 crash report
There seems to be a regression regarding the built-in gdiplus.dll in more
recent Wine 8.x devel builds.
Unfortunately Paint.NET 3.5.11 no longer runs stable. This behavior was
previously known only when the native gdiplus.dll file was used. It didn't
happened with the built-in one.
It looks that this instability is related to a speed improvement of the
built-in gdiplus.dll.
In older Wine versions Paint.NET 3.5.11 was lagging when a line was painted but
it worked stable. This lag was not present with a native gdiplus.dll file but
Paint.NET crashed randomly when the native variant was used. Now Paint.NET also
crashes with the built-in gdiplus.dll variant while there is no longer any lag
present.
More information about that Paint.NET 3.5.11 lag issue can be found in my old
bug 51561.
So in summary, Paint.NET 3.5.11 works in recent Wine 8.x devel releases faster
but less stable. I think this regression was in introduced somewhere in the
Wine 8.1x branch. It is confirmed for Wine 8.14 and 8.15.
Final note, it is currently not possible to install Paint.NET 3.5.11 into a
fresh Wine devel prefix. The installation will fail. A workaround is to install
Paint.NET 3.5.11 under Wine stable and then copy over the whole prefix to a
Wine devel installation. I can confirm that this works fine for Wine 8.0.2 and
Wine 8.15.
--
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.