View Full Version : Linux UnrealTournament

02-22-2011, 02:01 PM
playin on linux

02-23-2011, 05:29 AM
Are you running on the native linux support of UT (binaries install) or using wine?

I heard that wine runs UT better than the native Linux support provided by Epic.

02-23-2011, 05:34 AM
Playing on linux should not be an excuse for your lack of skill :cool:

02-23-2011, 07:16 AM
Actually UT runs in Linux as good as in Windows (at least on my end, I use Windows at home and Linux at work).

03-14-2011, 12:42 AM
Bump. The actual Linux version of UT99 is borderline useless on any distro I've tried past Ubuntu 7.10. The most I've gotten it to do after that was freeze after the intro and even on 7.10 it felt like a really stripped down version with a lot of options (including console commands) missing. The recommended way of playing UT though assuming your not using the Direct X 10 renderer is to run it through WINE on a Linux machine. Every mod works, anti cheats (except UTDC, which is no longer in use) work, maps, renderers, Old Unreal Multimedia Update, Unreal Tournament Retexturing Project, etc. it all works and even runs better than under Windows. I can even emulate EAX support by setting WINE up to emulate the sound. The only issue I've had is that I've had to set up an emulated desktop to fix a mouse problem, or if I installed with PlayOnLinux, extract UMod files with a tool and install those manually. Even Direct 3D 9 works as it should.

03-14-2011, 09:19 AM
There's one thing that doesn't work though: Unreal Editor. The viewports stay freezed (you can't move the viewports at all), which makes Ued useless in Linux (WINE developers still didn't fix that...).

03-14-2011, 07:36 PM
That's a actually not a WINE problem beleive it or not. It has something to do with the lack of relative mouse input under Linux, something that will be arriving when Xorg gets ditched for Wayland in a handful of distros in the near future. That's also why hacks are needed to handle the mouse on a handful of applications.


03-15-2011, 06:55 AM
That may be true, but also a fact is that some applications run better on WINE than in Windows itself, why? Because those applications are used by many many people, so WINE developers take more time to develop and fix things regarding those.

In UT case, the game itself works without a problem, because they made an effort to, however the Ued2.0 doesn't work, they already attempted to fix it, but quited as perhaps in their opinion it doesn't worth the effort compared to other top priority applications (the ticket is still there, since 2009).

So even if it's not their fault, they COULD fix it if they made an effort to, with whatever hack they could pull off (everything in programming is possible, it's a fact and more than proved, it just depends on available time and coders skill, in WINE's case, there's just no time as I believe they have the skill ofc).

03-15-2011, 07:46 AM
Kinda pointless when relative mouse input is around the corner, it would be smarter to wait for that to hit and then develop around that, while focusing on other problems not affected by that.

03-15-2011, 08:04 AM
Well, pointless "now", like I said in my post: the last ticket dates back to 2009 (2 entire years), so it wasn't pointless at all back then.
Again, they just didn't make an effort to fix it back then, so yeah, it's pointless now, even with the new server coming for some distros as any mapper has already moved to Windows to be able to build maps, so even after that it will be pointless anyway.

Only Linux people wanting to just "play the game" keep on Linux, developers are pretty much forced to use Windows just because of this.

For instance, although I developed my own shell script for my full customized compiling regarding my pack in Linux (which in this case it's NOT a regular compile like 99.9% of the UT mods released or in development, thus the need of a "custom compilation"), I will have to learn batch for Windows (which sucks compared Linux bash, and Linux shell script already sucks as a language) to do "nearlly" the same there, as many times I have to open Ued to test specific "potential features" and problems/engine limitations as well to proceed with development, to not talk about explosion sprites and several ice textures I have to build directly in Ued, and sounds I have to export to edit and make my own sfx.

So WINE should have fixed it before, and now fixing it is pretty much useless.