http://bugs.winehq.org/show_bug.cgi?id=16889
Summary: Very bad performance in Monolith games (NOLF, F.E.A.R.) Product: Wine Version: 1.1.12 Platform: PC-x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d AssignedTo: wine-bugs@winehq.org ReportedBy: zarquon@t-online.de
Many Monolith games show very bad performance (at least in some levels). The most extreme one is naturally F.E.A.R. (although AFAIK I have everything set to medium and optimized my WINE settings according to AppDB, e.g. hardware shaders and offscreen rendering to FBO), but since I also encountered rather hefty performance problems in the much older "No one lives forever" series I think the bottleneck is probably code typically used in many Monolith games, isolating which may be much simpler in older games like NOLF, as opposed to pretty cutting edge stuff like F.E.A.R. I have an x86_64 dual core Linux system with 4 GB of main memory and an Nvidia GF7900GS with 512MB RAM, which can run even Prey under Wine like a charm. In F.E.A.R. OTOH, frame rates dropped to something like 4 FPS on the most extreme occasions, despite medium settings. When I monitored my graphics card's temperatures during one session, it looked like it wasn't really doing much, so the bottleneck has to be somewhere in the emulation layer.
Looks like you can download a demo version of NOLF here: http://www.fileplanet.com/49582/40000/fileinfo/No-One-Lives-Forever-Demo
and NOLF2 would be here: http://www.gamespot.com/pc/action/noonelivesforever2asihw/download_2880459.h...
http://bugs.winehq.org/show_bug.cgi?id=16889
--- Comment #1 from joaopa jeremielapuree@yahoo.fr 2009-01-11 11:30:58 --- I do not know about FEAR, but the bottleneck with the NOLF series is that the console is spammed. To have an acceptable framerate: WINEDEBUG=-all wine xxxxx.exe
In every case, if you care about performance, you must use WINEDEBUG=-all
http://bugs.winehq.org/show_bug.cgi?id=16889
--- Comment #2 from Andreas Dehmel zarquon@t-online.de 2009-01-13 16:22:38 --- Thanks for the hint. I did try to redirect all output (stdout/stderr) to /dev/null initially, but that didn't appear to make any difference whatsoever when it should have made at least a little (albeit of course not as much as disabling warnings altogether).
I did try it with NOLF now; it still felt a bit more chuggy than I'd expect for such an old game and I didn't have savegames for the worst levels handy, but it seemed better than I remembered. F.E.A.R. was much improved! The bit which dropped to 4 FPS before now felt about 3 times faster. It still does stutter quite a bit when you turn around (I think this may be texture management issues where the machine goes into texture thrashing when it really shouldn't with 512MB of video memory and medium graphics settings), but it's considerably better, so thanks for the hint. Nevertheless, I feel there's still a lot of room for improvement, so I think this bug should be left open for the time being, maybe F.E.A.R.-specific rather than Monolith in general. BTW, considering how much of an impact this had: is there a way to disable warnings at compile-time? Because the amount of warnings seems massive enough that even the conditional jumps involved in handling this at runtime may make a little difference.
Unfortunately there's no mention of this on the game's AppDB page. I know it's really a generic WINE performance guideline, but when you have other current games like Prey running fine you (or I, at least ;-) ) tend not to look under generic performance hints for solutions. It should be added to AppDB page(s), at least until D3D is sufficiently improved (there's already a box with performance hints for F.E.A.R. anyway).
http://bugs.winehq.org/show_bug.cgi?id=16889
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #3 from joaopa jeremielapuree@yahoo.fr 2009-01-26 09:01:54 --- I have a geforce 7600go with driver 180.22 and a dual-core 1,6Ghz.
With NOLF2 demo, I obtain in the movie about 180 fps, and ingame about 110fps. Seems to be very good for me: WINEDEBUG=-all,+fps wine NOLF2.exe gave me:
trace:fps:IWineD3DSwapChainImpl_Present 0xed1808 @ approx 113.85fps trace:fps:X11DRV_SwapBuffers @ approx 112.59fps, total 164.16fps trace:fps:IWineD3DSwapChainImpl_Present 0xed1808 @ approx 112.59fps trace:fps:X11DRV_SwapBuffers @ approx 115.10fps, total 163.72fps trace:fps:IWineD3DSwapChainImpl_Present 0xed1808 @ approx 115.10fps trace:fps:X11DRV_SwapBuffers @ approx 112.59fps, total 163.27fps trace:fps:IWineD3DSwapChainImpl_Present 0xed1808 @ approx 112.59fps trace:fps:X11DRV_SwapBuffers @ approx 128.32fps, total 162.96fps trace:fps:IWineD3DSwapChainImpl_Present 0xed1808 @ approx 128.32fps trace:fps:X11DRV_SwapBuffers @ approx 133.73fps, total 162.70fps trace:fps:IWineD3DSwapChainImpl_Present 0xed1808 @ approx 133.73fps
Maybe a problem of configuration for you.
http://bugs.winehq.org/show_bug.cgi?id=16889
--- Comment #4 from Andreas Dehmel zarquon@t-online.de 2009-02-03 15:06:51 --- I just checked and for me the ingame FPS in NOLF2 range from about 80 to 150 fps in the levels I tested (at 1600x1200 resolution). From experience, this can change a lot depending on the level, though. The really big problem are the juddering controls, however, is that the same for you? Turning often doesn't work, I really have to jank the mouse in the direction I want to face. That doesn't appear to affect FPS, though (and it's a different bug, of course).
http://bugs.winehq.org/show_bug.cgi?id=16889
--- Comment #5 from Andreas Dehmel zarquon@t-online.de 2009-02-03 15:12:49 --- Re. F.E.A.R.: I found that disabling debug output appears to improve things much more for "Extraction Point" (first expansion pack) than the main game. Oddly enough, saving games also takes _much_ longer in the main game (can be in excess of 10 seconds) than in EP (rarely above 1s).
http://bugs.winehq.org/show_bug.cgi?id=16889
--- Comment #6 from joaopa jeremielapuree@yahoo.fr 2009-02-03 15:31:08 --- The mouse bug is well known(there is already a big bug report opened). It will be fixed when xorg release its next next version (xinput2 client support). [Note that the next release is forseen for this month, so we can hope to see the next next release for the end of 2009.]
http://bugs.winehq.org/show_bug.cgi?id=16889
--- Comment #7 from joaopa jeremielapuree@yahoo.fr 2009-02-03 15:32:46 --- Maybe this bug could be closed as fixed, couldn't it?
http://bugs.winehq.org/show_bug.cgi?id=16889
--- Comment #8 from Austin English austinenglish@gmail.com 2009-02-03 17:00:09 --- (In reply to comment #7)
Maybe this bug could be closed as fixed, couldn't it?
Nothing was fixed in wine. If anything, invalid.
http://bugs.winehq.org/show_bug.cgi?id=16889
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |DUPLICATE
--- Comment #9 from Austin English austinenglish@gmail.com 2009-08-05 10:06:10 --- Dupe
*** This bug has been marked as a duplicate of bug 7640 ***
http://bugs.winehq.org/show_bug.cgi?id=16889
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #10 from Dmitry Timoshkov dmitry@codeweavers.com 2009-08-05 22:55:59 --- Closing duplicate.
-
wine-bugs＠winehq.org