http://bugs.winehq.org/show_bug.cgi?id=12444
Summary: Serious Sam TFE lockups and input delays Product: Wine Version: 0.9.58. Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: zarquon@t-online.de
Serious Sam TFE will frequently freeze for a short time for no apparent reason, after which all user input is severely delayed (feels like the time of the freeze approximately). So you end up pressing a key or moving the mouse and one or three seconds later Sam moves. In between the freezes, the game is completely smooth with no hints of stress. Strangely enough, loading such a game will continue with the delayed input. Sometimes the game appears to catch up again (I think prolongued time in the console is what does the trick), but not for long. Resolution doesn't have anything to do with it, the same thing happens in 640x480 and besides I've played Far Cry and Prey on this machine (in my standard resolution of 1600x1200) without problems, so I doubt the machine is too weak. I tried using native dinput.dll and msvcrt.dll, but that didn't change anything. The game states it uses OpenGL for GeForce2 on my GeForce7900, could this be a problem? I also tried disabling sound or using other network devices, but to no avail either. Anything else I can try?
I'm aware of the native Linux ports, but these are highly beta and it doesn't look like they'll finally be finished one day. They only work in 640x480, you frequently fall out of the level and need console cheats to get back in, and other stuff doesn't work at all (like the end fight). I was hoping to finally be able to play the game as it was meant to be played...
http://bugs.winehq.org/show_bug.cgi?id=12444
--- Comment #1 from Andreas Dehmel zarquon@t-online.de 2008-04-21 14:04:18 --- This problem got a lot better in 0.9.60. It still lags in many situations, but in contrast to previous versions the lags are now in fractions of seconds rather than multiple seconds. It's still too much for a frantic twitch-shooter like Serious Sam, but this was a huge step in the right direction; the game is almost playable now.
http://bugs.winehq.org/show_bug.cgi?id=12444
Alexander Dorofeyev alexd4@inbox.lv changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alexd4@inbox.lv
--- Comment #2 from Alexander Dorofeyev alexd4@inbox.lv 2008-04-21 14:27:38 --- (In reply to comment #1)
This problem got a lot better in 0.9.60. It still lags in many situations, but in contrast to previous versions the lags are now in fractions of seconds rather than multiple seconds. It's still too much for a frantic twitch-shooter like Serious Sam, but this was a huge step in the right direction; the game is almost playable now.
git-bisect could help to understand the nature of the probmem, see
http://wiki.winehq.org/RegressionTesting
Of course, in this case nothing did regress, on the contrary it improved, but same git bisect approach can help to isolate fix that improved it (by reversing the logic and assuming improvement in speed is "regression". If you find the commit which introduced the change, then, perhaps, it will become more clear what is to blame for this lag.
http://bugs.winehq.org/show_bug.cgi?id=12444
--- Comment #3 from Andreas Dehmel zarquon@t-online.de 2008-04-23 16:12:41 --- I was afraid you'd ask that... OK, off I went and started bisecting between 0.9.58 and 0.9.60. Unfortunately, on my second bisect (4eaa424c795c9c5ed4a772898297e692a5a2b2b0), WINE refused to start with the error
wine client error:36: version mismatch 339/338. Your wine binary was not upgraded correctly, or you have an older one somewhere in your PATH. Or maybe the wrong wineserver is still running?
Version 0.9.58, which I also still have installed, behaves the same. Apparently something became incompatible (never seen this error before, and I do rather frequent version-hopping with WINE). I'd like to help, but keeping different installations of my environment (plus probably the actual game) is getting a bit much. Any suggestions how I can run older WINE versions after running 0.9.60?
http://bugs.winehq.org/show_bug.cgi?id=12444
--- Comment #4 from Alexander Dorofeyev alexd4@inbox.lv 2008-04-23 16:24:08 --- (In reply to comment #3)
I was afraid you'd ask that... OK, off I went and started bisecting between 0.9.58 and 0.9.60. Unfortunately, on my second bisect (4eaa424c795c9c5ed4a772898297e692a5a2b2b0), WINE refused to start with the error
wine client error:36: version mismatch 339/338. Your wine binary was not upgraded correctly, or you have an older one somewhere in your PATH. Or maybe the wrong wineserver is still running?
Version 0.9.58, which I also still have installed, behaves the same. Apparently something became incompatible (never seen this error before, and I do rather frequent version-hopping with WINE). I'd like to help, but keeping different installations of my environment (plus probably the actual game) is getting a bit much. Any suggestions how I can run older WINE versions after running 0.9.60?
Running many self-compiled versions of wine doesn't usually create any problems. I've lots of them, for example, in separate directories. Just make sure you run one version at a time. Errors like this normally appear if a wine process (started with another wine version) was still running (maybe a program minimized to systray or something like that). Make sure you close all programs and no wine processes remain in 'ps' output.
http://bugs.winehq.org/show_bug.cgi?id=12444
--- Comment #5 from Andreas Dehmel zarquon@t-online.de 2008-04-29 15:30:31 --- You were right, I had about 8 old instances of winemenubuilder running without noticing, must have happened during installation of another game several days ago. Once I killed those, the problem went away. But unfortunately, whenever I try it now, all WINE versions lag massively. I don't think it's related to the old WINE server I had running but lucky coincidence when it worked. I think the lags are connected to the graphical freezes that happen occasionally (afterwards, sync is usually shot to hell and stays like this for a while, then you may get lucky and after another freeze sync is back (or not), and so on). There's no console output worth mentioning either (no runs of FIXMEs or anything) and the effect is pretty much identical regardless whether I run the game in OpenGL or Direct3D mode. When I switched to Direct3D mode, I got a load of these messages, though:
fixme:d3d_shader:vshader_set_limits Unrecognized vertex shader version 0
Any further suggestions? Specific debug channels that might give vital clues? Because now that all versions appear to be broken pretty much the same I think further regression testing would be pointless.
http://bugs.winehq.org/show_bug.cgi?id=12444
--- Comment #6 from Lei Zhang thestig@google.com 2008-04-29 16:06:24 --- (In reply to comment #5)
You were right, I had about 8 old instances of winemenubuilder running without noticing, must have happened during installation of another game several days ago. Once I killed those, the problem went away.
FYI, that's probably bug 12707.
http://bugs.winehq.org/show_bug.cgi?id=12444
--- Comment #7 from Austin English austinenglish@gmail.com 2008-10-30 02:16:34 --- Is this still an issue in current (1.1.7 or newer) wine?
http://bugs.winehq.org/show_bug.cgi?id=12444
--- Comment #8 from Andreas Dehmel zarquon@t-online.de 2008-11-02 08:23:59 --- Just checked and yes, it's still there. "The Second Encounter" also suffers the same problem (at least on my machine), but it doesn't seem to create such a huge lag afterwards (at least that's my impression). It's really hard to nail this bug, it sometimes almost disappears and at other times it lags for a second or two. I think there's a demo version of the game, maybe you could try this for verification. It also happens during intros/demos, but of course you won't notice the lag following the freeze in this case.
http://bugs.winehq.org/show_bug.cgi?id=12444
--- Comment #9 from Andreas Dehmel zarquon@t-online.de 2009-02-03 14:44:01 --- On a hunch, I checked the general Serious Sam forums today and found some entries about Windows users experiencing the same kind of problems with the game. It turned out that all of them had multicore CPUs and for all of them the problem was solved by setting the process affinity of the game to one CPU. So I tried to do the same thing on Linux by starting WINE with taskset and hoping I'd nail everything required to one CPU (since running WINE always launches multiple processes, I wasn't certain I'd manage that). And that actually worked! I watched the demos and played a little, everything smooth as butter, no lags or freezes. So for the record: if you have a multicore CPU, start the game via e.g. taskset 0x00000001 $WINE_EXEC Bin/SeriousSam.exe and everything should be fine. Essentially you can close the bug now. I don't know whether other people will find this solution in the closed bugs section, though, I think this is one for a more generic WINE troubleshooting guide (if such a thing exists...), especially since it may also affect other older games.
http://bugs.winehq.org/show_bug.cgi?id=12444
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |INVALID
--- Comment #10 from Vitaliy Margolen vitaliy@kievinfo.com 2009-02-04 01:09:07 --- Invalid then - not a Wine bug if it also present on windows.
http://bugs.winehq.org/show_bug.cgi?id=12444
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #11 from Vitaliy Margolen vitaliy@kievinfo.com 2009-02-04 01:09:16 --- Closing invalid.
-
wine-bugs＠winehq.org