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).