I'm also trying LTP under WINE. Wall of Text™ incoming!
My specs
Debian GNU/Linux - Stable/Testing hybrid - amd64
Intel Core i5 (4 physical cores)
ATI Mobility Radeon 5000 series
Using non-free fglrx drivers: 12.020.000.015.037075 (guess ATI haven't heard of
semantic versioning)
GPU acceleration is working correctly on my machine (I use a compositing window manager for example and I can play UT2k4 on max GPU settings just fine)
WINE 1.5.29/x86 (configured via PlayOnLinux)
Installing the game
The installer crashed for me in exactly the same way as reported above but I have a VirtualBox installation with a copy of Windows on it that I use for browser testing. I managed to install the game into the VM and then copy the installed files out of there and onto my main OS into a newly-created WinePrefix.
I tried installing it into an amd64 WinePrefix first but the game refused to start. I noticed when I installed to Windows it wanted to be x86 so the failure of the amd64 WinePrefix wasn't surprising. I only tried the amd64 prefix out of interest.
On an x86 WinePrefix I am somewhat further:
- Having noticed it amongst the prerequisite software installed during the LTP installer's run - I installed the vcrun2010 package using PlayOnLinux (it creates a library override for me). If you're not using POL then I think that the winetricks script can do the same thing for you.
- I'm targetting Windows version WinXP - I've also tried Win7 and I see no appreciable differences.
- I'm not using a Virtual Desktop.
- I'm using WINE's default audio setup.
- I'm not running the game fullscreen (I'm using a window @ 1024×768)
- Currently I have all graphical settings switched to minimum (including the 4 in-game graphical settings)
What works
- The launcher works
- The game starts
- I can toggle all of the graphics FX and see the immediate differences when toggling bloom and FSAA
- I can start a new game
- What little of gameplay I have been able to test seems to work, except …
Blocking performance issue for testing under WINE
Whilst the 3D of the game, and the UI seems pretty responsive I am having trouble with the in-game mouse cursor that is stopping me from giving it more than a cursory (no pun intended) test. Moving the cursor around feels like wading through tar, it lags behind the actual mouse movement and also moves erratically. That erratic movement essentially means that sometimes I'll move the (physical) mouse a tiny bit and the in-game mouse cursor won't budge at all, sometimes I'll move it a lot and it won't budge either. Other times the in-game cursor will move seemingly normally for a split-second, often shooting to the extremities of the window (screen edge).
I experience the problem both whilst docked/interacting with the docked UI as well as when flying in space. It doesn't seem to be related to how many graphical assets are drawn on-screen at the time. It doesn't manifest so much when in the main menu
before starting a game, but once in a game (after pressing escape to return to that menu) the same behaviour occurs on the menu. Oddly, it seems that the problem is less severe when the 'spacebar menu' (the "top bar" I think it's called) is opened.
Something possibly-related (but perhaps not) is that the mouse cursor doesn't seem to have been properly 'grabbed' by the window. That is - the cursor was able to escape from the game window even in full 3D mode, which it can't do in other 3D games. Obviously, I can set MouseWarpOverride on via WINE and that will snap the cursor back into the window should it ever leave but usually the game/app manages to keep hold of the cursor on its own.
I have tried the following (including a few combinations of these, where it makes sense to try them). None of them have helped:
- Turning off both of the in-game options that might interact with the mouse cursor (auto-aim and target assist)
- Overriding and using native DirectInput (I don't even know if the game uses DirectInput, I didn't think it did but it's a known WINE tip that using native dinput can sometimes solve mouse lag problems)
- Setting WINE's MouseWarpOverride to each of Enabled, Disabled and Force
- Enabling and disabling GLSL (although since the game doesn't use D3D that shouldn't have helped anyway)
- Emulating a virtual desktop and running the game fullscreen inside it
- Configuring WINE to 'Automatically capture the mouse for full-screen windows
- I've tried a few other WINE versions: 1.5.20, 1.4-rc5, 1.3.32 and 1.1.42 - no appreciable difference with any of those.
The mouse cursor issue makes the game basically unplayable, since a three-legged dog on tranqs can fly rings around me. Just to repeat though, the game itself seems to be running at an otherwise acceptable FPS, it's just the mouse cursor that's gone haywire.
(very) Long wait for game to load
A second issue (but not a showstopper for me) is that the loading screen (the one that appears between the main in-game menu and the actual start of the game) apparently sticks around for a lot longer under Linux than it does on Windows (on what is presumably a similar-spec machine). This (again) came up in conversation with Bele on IRC because he remarked that he thought the game had hung on the Linux machine he tried it with.
On mine (which is relatively high-spec as Linux machines go, mainly because it's my primary system) it would seem like it has hung for about 10-15 seconds. The spinning animation stops dead, the cursor is unresponsive and the CPU usage as reported by my task manager jumps up to 25%. Since I have 4 cores and I assume that the loading process is single-threaded, that probably means it was maxxing out a single core for all it could. After that period of unresponsiveness the spinner eventually starts stuttering and eventually the game starts with the ship in the station. After a moment or two the game seems to start performing normally (except for the mouse insanity above). Overall I'd say the loading screen is visible for about 30-45 seconds.
Addendum
I just want to make it clear that I understand that there is no duty for Josh to do any work to fix these issues running the game on WINE, the LTP was always billed as a Windows-only affair. Any attempt to run it on WINE (or any other compatibiliy wrapper/emulation platform) is not supported. Fixing bugs that are reported by people running it on Windows should be the priority; I only tried running it under WINE "to see if it would work at all".
Thought I should re-iterate this in case it looks (by the long post that reads a lot like a bugreport) that I'm pestering for a fix. I'm not, it's as much for other people's academic benefit (who might also want to try LTP under WINE) as it is for Josh who might find this information useful in one way or another.