Quoting: STiATIf you have an issue with the mouse (not moving / moving horrendibly slow):
https://github.com/PlayOnLinux/wine-patches/tree/master/custom/rawinput2 [External Link]
that one helps ;-). I think POL actually provides a wine version with rawinput2 patch in the repos which you could try.
It's an issue with mouse acceleration being wrong implemented in EE1. I've done this with xinput commands setting mouse acceleration profiles too at some time, but the rawinput2 patch seems to work properly.
Didn't try in the past year though.

Quoting: Geppeto35Ooh nooo! Again a Total War! Stop that Feral :P :whistle:

Quoting: Guest

Spoiler, click me

You are right in that the ABI unstable nature of Linux makes it difficult to support well. However, it is not impossible, but it does require knowledge and skills that your average developer will not have unless they are already very familiar with the platform.

Steam's runtime was a good attempt to alleviate this, however it creates problems of its own. We used the steam-runtime SDK at VP simply because it gave a nice consistent set of libraries to build against. However, it quickly became a problem that they were too old, and the toolchain used to build against them (gcc 4.5) was also getting too old.

Valve did work on a newer steam-runtime, but it was only usable from inside a chroot. This is no good when you are using an IDE or some other application which wants to call those tools - you either have to run said IDE/app inside the chroot (which can be a dependancy nightmare) or live with a relatively slow invocation of the chroot enviroment for every file compiled.

Yes I know this is where the fanboys start screaming "use makefiles!" but this not what game devs are used to on other platforms, and quite frankly, they are cumbersome.

I did actually start to assemble a custom "SDK" for VP's Linux stuff, based around GCC 4.8 (which was still fairly current at the time).. but other things stopped me getting it finished off. Building your own toolchain with crosstool-ng or the likes is certainly not what your average dev will be used to dealing with!

edit: I should also say that expecting a developer to recompile the game when there's ABI breakage is not an acceptable solution. You really cannot expect a a developer to support something forever, and "just release the source code" is not a viable solution. More work needs to be put into ABI stability on Linux, for it's own good.

Quoting: Leopard

Quoting: AnxiousInfusionI don't know if it's running better now because of patches, or because I finally abandoned that godforsaken fglrx.

Probably because of the dropping fglrx.

How can you stand with it until now?