Yea there was a "stall" on the DX thing.... but it got over that. But the hang up on Star Trek Online.lnk actually hung up the installer... I could still cancel out of it... but over 20 hours after hitting that file it didn't budge.
Same problem, Its when the program is creating a shortcut, it stalls. Mine has the same problem, Not really sure what to do. :S
as a big tip to anyone trying to get this to run on linux....
with Wine 1.2, in the registry.. under Software->Wine->Direct3D you can add a string called StrictDrawOrdering and set it to disabled, and it will stop some weird performance drops, as things are able to draw a bit faster on the screen... seems to work good for me
with Wine 1.2, in the registry.. under Software->Wine->Direct3D you can add a string called StrictDrawOrdering and set it to disabled, and it will stop some weird performance drops, as things are able to draw a bit faster on the screen... seems to work good for me
Thanks for re-posting that here. Hopefully it will help others in the future.
Do you get a blank white popup window when the launcher loads? Also can you take a screenshot of your loader screen?
Hi there, i just installed STO but after start i only get this mentioned white screen and nothing else.
I installed ie7 and corefonts with winetricks too.
*edit: Maybe i know whats the problem. ie6 or ie7 never installed, cause i have a 64 bit linux and 32bit wine. Using winetricks to installe ie6 and ie7 then fails cause it detects my 64bit linux host and denies installing 32 bit ie. Strange thing cause all other 32 bit apps work..
*edit2: ok, i fxed my earlier problems by installing "bin32-wine_gecko" on my archlinux installation, now the launcher starts. I can fill in my credentials but i cannot hit the "patch" button. I think this brings me back to problem 1. How to install ie6.
Is there anything i have to do to get rid of it? I searched in this thread but i cannot find anything that helps.
That screenshot shows a line stating "Failed to init Gecko", I'm no expert however in my mind that would tell me your IE7 install is broken.
I noted a later edit to your post saying you can now enter login info but cannot click on patch, I still think IE7 is the problem even though it is semi-sorta working, I would recommend trying IE6 instead.
As far as getting rid of IE7, without reinstalling everything all over again, a sloppy and unrecommended hack would be to simply delete the folder IE7 installed to then install IE6 by running the command winetricks ie6″. If it doesn't work you might just be better off with a fresh new .wine folder as Winetricks recommends.
Winetricks does not provide a way to uninstall files it installs. This is for several reasons, but mainly because the preferred way to uninstall anything in Wine is to simply install into a fresh .wine directory.
Personally I'm on a BSD box not Linux, and I had much better luck using IE6, when I tried IE7 it was all borked up.
I posted an article online about what I had to do to get STO running for me, it may or may not be of help to you or others.
thx for your interest in helping, i will check your site.
I tried deleting the wine folder several times and created hundreds of new wine bottles but without luck.
It seems that this is a problem with my linux-/wineinstalaltion cause the problem, not being able to install wine is only present to me. On other archlinux computers it seems to work.
I made a thread in the archlinux forum, maybe someone can help me, cause this is not STO / wine related problem i think. The thread i'm talking about is this one: https://bbs.archlinux.org/viewtopic.php?id=102422
thx for your interest in helping, i will check your site.
I tried deleting the wine folder several times and created hundreds of new wine bottles but without luck.
It seems that this is a problem with my linux-/wineinstalaltion cause the problem, not being able to install wine is only present to me. On other archlinux computers it seems to work.
I made a thread in the archlinux forum, maybe someone can help me, cause this is not STO / wine related problem i think. The thread i'm talking about is this one: https://bbs.archlinux.org/viewtopic.php?id=102422
cya
Okies, sorry wasn't an easy fix for ya. I looked at the link detailing the IE6 install issue. Don't have an answer for you on that but I'll ask around with some folks I know and if I get any potential solutions I'll pass them along.
I recently had to reinstall this on Gentoo (I briefly went to the dark side and had another 'turrrible' OS on the system - glad I went back.. anyway). And, it took me a while to figure out the right way to do this - or at least a method that would work.
I saw (and remembered having this issue before) that the Wine's internal internet explorer doesn't work at all (even wine 1.3.0's internal one blows up mightily). Gecko, for those who aren't familiar, is the firefox/mozilla core. Since this game seems to use IE semantics and operate under the assumption you have it, you'll definitely need ie6 or 7. From past experience, 6 works, albeit with either javascript errors or the occasional weird window that pops up for no reason during patching. During this install, however, I managed to solve the problem by skipping ie6 and going directly to ie7.
Mind you, this operates under the assumption you have a working wine install. I'm not going to include instructions for that part as it varies from distribution of Linux to distribution.
(Hardware: 2 Quad-core Opteron 2378s, 16G RAM, 2xNvidia GeForce GTX 275s in SLI mode, 4 1TB 7200 RPM Seagate Barracuda drives (in a software raid 10 configuration), using the SuperMicro H8DA8-2 motherboard -- overkill on the detail, but, eh.)
Distribution: Gentoo. Arch: amd64
(-O2 -march=native -mtune=native - for the Gentoo folks)
For the purposes of my testing, I tested both ~app-emulation/wine-1.2.0 and ~app-emulation/wine-1.3.0. (I masked the 1.3.0 version to test and it resulted in the same instructions as 1.2.0.) Also: ~x11-drivers/nvidia-drivers-195.36.31 (I might unmask the most modern but untested ones, but I am not yet sure I want to tempt fate.)
First, set the overrides, download the dlls, download and use winetricks to get the packages recommended by this article (ALSO: Please ensure you have installed 'd3dx9' via winetricks. This becomes important later...):
(For brevity, you can simply google the missing dlls you need. There's a website that has windows dlls for free.)
Once IE7 is working and installed, proceed to install Star Trek Online normally. Note, you'll also need to follow the instructions provided in the following STO post (page 34, post #335 of this thread):
You may also need to disable the mmdevapi dll in winecfg depending on your distribution: Keep in mind, this instruction tends to apply if and only if you have a sound server installed in your X distribution. If you use ALSA (or an outdated OSS) directly without either esd or pulseaudio, you may not need to do that at all.
Note: The DXSetup piece (as mentioned in various threads) seems to stall but it isn't actually stalled. What you could do to find out what it's doing is via a program called 'lsof'. something like:
lsof | grep Cryptic
That segment will tell you what it's doing in the directory for the game... but...
You'll want to look for anything other than that directory:
lsof | grep drive_c | grep -v Cryptic
The first field is the application, second is the process id, third is your username, 4th is the file descriptor (which tells you if it's being read, if it's a directory, or if it's in memory).. and skip to the last field (that's the file or directory that's open).
If you want to get a fair idea about what the progress is, open a large enough terminal and just run this via watch. Like so:
watch "lsof | grep drive_c | grep -v Cryptic"
or to watch the Cryptic directory once that's past:
watch "lsof | grep Cryptic"
Mind you, it will take a trained eye - plus a harddrive activity light. But, you can also use: dstat to see it's writing to the drive:
By default, this updates every second, so you can see that there was a nice little burst of 69M written to my disk in that period of time. The two tools (regardless of linux distribution) should provide you enough evidence of what is occurring. It seems like DXSetup is stuck, but it almost certainly isn't. :-)
Edit to add:
There are some performance tweaks in Linux that may be of help -- but be warned, this is not for the tame or timid. Nor, unfortunately, is it for the folks who don't know what the implications are.
PCI Latency
==> This is probably the most overlooked and most under-utilized option to improve performance. I didn't really consider it myself until I saw what I was missing. In my case, as much as a 50-60% improvement at high end video settings. Your mileage will vary. Gentoo is fortunate enough to include this in it's default desktop profile and an example config, but you may not necessarily need it either. Generally speaking, you want to, paradoxically, increase the latency to your pci devices except for things like your network and audio cards. This allows the cards enough time to receive, respond, and give appropriate warnings on data it as received. This 'opens up' the PCI bus and improves performance by and large. Most Linux distributions do not set this to an optimal value.
Video Card Tweaks
==> This is done in accordance to your video card type, vendor, and Linux distribution. It is highly recommended you read your distribution's guide on your particular video card. For gaming, however, very few cards beat or compete Nvidia in the Linux world. Nvidia offers a wide variety of distributions support and community help on gaming.
Also, make sure those changes are committed to your xorg.conf file - and X is restarted.
readahead and readahead-early services
==> This instruction is for RedHat derivatives. You'll want to enable that service and run it. The readahead-early service is for faster boots and technically still outside of the scope of this... but while you're there... ;-) The 'readahead' service itself is the one we're looking for.
Read-ahead Buffers
==> This is also one of those "oh, really, I didn't know about that" gotchas that many folks miss. If you're using Linux, you undoubtedly don't have an optimal read-ahead buffer setup on your system. By default, this set to 128k (or 256 512 byte block reads) on almost every distribution. The package will vary from distro to distro, but you'll want the 'blockdev' binary usually located in /sbin.
It will report this (and it has to be done as root) -- skip to the bottom of this bullet point for LVM:
To increase this value (also as root), you'll probably want a safe but reasonable value. If you do a lot of gaming with huge files (or massive video playback), you may want to set this to something like 8192 (or 4M in 8192 512 byte sectors)
# /sbin/blockdev --setra 8192 /dev/sda
Generally speaking, you could see about a 20-25% improvement in disk accesses for gaming.
Note, if you're using md raids for your disk partitions, the value of the block readahead can be checked on your raid device. So, substitute sda (or hda) for your raid partition (like /dev/md2). That value is set by the chunk size used when the raid volume was created. By default, this is an absurdly low value. Linux kernel tuning experts suggest values of 512k to 1024k for chunk goodness. That value is also determined by the raid type and number of spindles (or drives) in your array. In the case of Raid 10, it is (chunk size * spindles * 2). In my case, as I chose the value of 1024k as a chunk size when I created my raid partition, it was (1024 * 4 drives * 2) or 8192k readahead (or 8M). This is confirmed via:
unimatrix-01 ~ # blockdev --getra /dev/md2
16384
If you're using LVM (Logical Volume Manager) which is a default on many RedHat derivatives, you'll want to change this in LVM directly rather than through blockdev. Find the partition and Logical Volume your games or data is stored on, then do this as root:
lvchange -r 8192 VolGroupXX/LogVolYY
Unlike the blockdev changes mentioned above, this change is persistent upon reboot. blockdev changes must be put into a system startup script or they will be lost upon reboot. Play with a value that works for you - but no value larger than 8192 will provide any noticeable performance gains.
Prelink!
==> This is also often overlooked. This particular setup is done by some distributions but not others. Check your distro for support. Essentially, this links the libraries that you need into the binaries themselves automatically - shaving the need to re-read every library and library directory on the disk when a program is called.
Optional Preload
==> This is very rarely used, but some distributions will allow you to install this daemon. Once running (give it a day or two), it will learn the frequency of which files tend to be opened the most. It will then load those most frequently used files into memory based on your individual patterns. It will make loading games or applications a lot faster.
And, it took me a while to figure out the right way to do this - or at least a method that would work.
I saw (and remembered having this issue before) that the Wine's internal internet explorer doesn't work at all (even wine 1.3.0's internal one blows up mightily). Gecko, for those who aren't familiar, is the firefox/mozilla core. Since this game seems to use IE semantics and operate under the assumption you have it, you'll definitely need ie6 or 7. From past experience, 6 works, albeit with either javascript errors or the occasional weird window that pops up for no reason during patching. During this install, however, I managed to solve the problem by skipping ie6 and going directly to ie7.
Mind you, this operates under the assumption you have a working wine install. I'm not going to include instructions for that part as it varies from distribution of Linux to distribution.
Awesome post! Thanks for sharing this. Major kudos!
I recently had to reinstall this on Gentoo (I briefly went to the dark side and had another 'turrrible' OS on the system - glad I went back.. anyway). And, it took me a while to figure out the right way to do this - or at least a method that would work.
This awesome posting definitely reminds me of all the times I've sought for a solution to a tiny issue with something in Linux and found it in a Gentoo wiki or forum. Thanks for another one.
I recently had to reinstall this on Gentoo (I briefly went to the dark side and had another 'turrrible' OS on the system - glad I went back.. anyway). And, it took me a while to figure out the right way to do this - or at least a method that would work.
I saw (and remembered having this issue before) that the Wine's internal internet explorer doesn't work at all (even wine 1.3.0's internal one blows up mightily). Gecko, for those who aren't familiar, is the firefox/mozilla core. Since this game seems to use IE semantics and operate under the assumption you have it, you'll definitely need ie6 or 7. From past experience, 6 works, albeit with either javascript errors or the occasional weird window that pops up for no reason during patching. During this install, however, I managed to solve the problem by skipping ie6 and going directly to ie7.
Mind you, this operates under the assumption you have a working wine install. I'm not going to include instructions for that part as it varies from distribution of Linux to distribution.
Lots more stuff....
[/LIST]
Want to tweak your post a little to assist all the other people with install problems since your post covers all the tweaks which were great..
First the system I am running:
NVIDIA 9600GT with latest driver supported
Ubuntu 10.04
Wine 1.2 (Latest supported)
Do these steps in this order from here on in. These steps worked flawlessly every time.
STO will work straight up under Linux for just about any Distro provided you can do the following:
- Install latest Wine (above or better later)
- Install Winetricks
From here I will walk you through the setup that is error free install and run:
Before intalling STO:
- install corefonts via winetricks
- install d3dx9 via winetricks (Do NOT install DirectX itself)
- install ie7 via winetricks
- Now put your CD or copy to HD then run under wine.
- Follow the prompts and install as normal.
On completion do the following:
- Open wine configuration
- On the graphic card screen, do NOT select virtual desktop.
- select the first checkbox for the mouse and leave the rest as default.
On the Audio tab:
- Select Alsa (default unless your audio either works with another or works better with another)
- click apply/ok to close.
Now run the game, a white popup window will appear which is the ie7. Close it. login, run your updates which will take for freakin ever, and then play. Adjust sound and video in-game to what you like.
NOTE: When you alt-tab or anything that removes focus from the game, it will make the game appear as though it froze or locked up. This should not be the case. Look at the top left of your gamescreen and you should see a little 1" x 1" square. If you click that, it refocuses onto the game.
This was tested on Gentoo, Ubuntu and Fedora. Please respond to let me know if this does or does not work on any other systems.
Want to tweak your post a little to assist all the other people with install problems since your post covers all the tweaks which were great..
First the system I am running:
(...)
Glad you edited the pompous sounding start. Much more respectful.
In addition to my earlier post, I'm adding more "tweaks" and enhancements you can do to further improve your performance (and this helps Star Trek Online).
One of the interesting things I found out after perusing the Gentoo Sources package was that Con Kolivas writes some cool performance tweaks for the Linux Kernel specifically, as it turns out, for Gaming and Video under Linux. For reference: Con Kolivas' site. You'll want to verify what your specific Linux distribution recommends package-wise. The patches contained on this site are for those who build their own kernels. (Gentoo users: You can use ~sys-kernel/ck-sources and that does work with genkernel -- and also contains the same patches that Gentoo sources does. So, you get the benefit of a faster kernel with Gentoo features)
Key features that were in the kernel changes were tweaking the vm.swappiness variable to a 0 value (indicating not to swap unless you really need to and to try to keep everything cached instead). However, it also includes a "really use the swappiness value" patch since the kernel tends to, oddly enough, ignore the value even if you set it manually using sysctl. Another key feature of this patch is the inclusion of the BFS CPU scheduler. (This becomes relevant to a later section of this post.) There are some other tweaks to how the caching is done within the kernel as well.
Following a reboot with the ck kernel patches, you'll also want to install schedtools (if your distribution doesn't include it by default). This becomes an interesting tweak and one of those rare "huh, I didn't know about that" moments. After installing both ck kernel and schedtool, you'll want to probably make two adjustments prior to starting X. One, make every process currently running as root run in a scheduled batch mode. This means the priority and cpu provided to it operate under the assumption you won't be getting active video feedback (tail and top don't count) in real time. Two, we'll be making sure that when we start X, we do so with the ISO (real time feedback/response) mode.
To that end, prior to starting X, you'll want to do something like "pgrep -U root | xargs schedtool -B" in a startup script. Then, for starting your X session, you'll want to put "schedtool -I -e {command to start X goes here}". Mind you, these two will depend on your distribution - so follow those instructions for your distribution. For Gentoo, it was easy: "schedtool -I -e /etc/init.d/xdm start"
Those two commands told the system to schedule any non-X application (like cron, etc) to go into batch mode. Anything started by X (your window manager, your wine games, your X your interface altogether) will then be put into "ISO" or Interactive mode. Both of these are relatively safe changes and are not considered dangerous in terms of starving your applications for CPU. It just means you'll have an interactive desktop. Video should be a little snappier too with fewer stutters.
Edit to add: As an alternative, you can just schedule wine in Interactive mode, but it could potentially cause X to, paradoxically, become less responsive. To just schedule wine for interactive mode: "schedtool -I -e wine Star Trek Online.exe" or similar. I decided that it was simply easier to schedule X and everything it spawned as interactive rather than individual processes. This would have the least amount of maintenance for the most gain.
(One of these days, I'll get around to writing a blog on how to do other stuff in Linux that isn't included in most distributions by default like compiz enabled desktops, etc - but that's outside of the scope of this thread.)
Do these steps in this order from here on in. These steps worked flawlessly every time.
STO will work straight up under Linux for just about any Distro provided you can do the following:
- Install latest Wine (above or better later)
- Install Winetricks
From here I will walk you through the setup that is error free install and run:
Before intalling STO:
- install corefonts via winetricks
- install d3dx9 via winetricks (Do NOT install DirectX itself)
- install ie7 via winetricks
I did not include those instructions for, unfortunately, a good reason: They did not work for me. I tried many possible variations and iterations. I spent a good part of 3 days trying all the variations. After doing a lot of research online, I determined a great number of folks were having the same problems in the same order for the same reasons as me. Thus, I wrote the post that addressed that problem.
Edit to add: In addition, I do not get an extra window popping up for me every time I start Wine for Star Trek Online. The only time I do is when I update wine versions - and that's before the Star Trek Online app starts (wine configuration is being auto-updated).
I think the problem centered around missing dlls for ie7. It refused to install stating it wasn't a valid OS. Thus, as I found in my research, it was necessary to trick ie into believing it already had the native dlls present (and why you need to do the overrides mentioned in the article). After making the requested changes, ie-7 installed (without updates) without a hitch. And, of course, Star Trek Online worked as expected.
This awesome posting definitely reminds me of all the times I've sought for a solution to a tiny issue with something in Linux and found it in a Gentoo wiki or forum. Thanks for another one.
Thanks. That was the intended theme of my post. :-)
Sorry to resurrect this thread, but I wanted some advice on getting STO to run well in Ubuntu.
So far, through reading the advice in this thread and elsewhere, I've finally gotten to the point of being able to get into the game, and I even get sound. And the graphics are decent, though not quite as good as in Windows. And the performance suffers the same slight drop from Windows. For instance, I don't have shadows, or at best, they are of very low quality, and my cursor disappears unless I set it to software cursor.
So, my question is, how can I tweak the game's performance? Is there anything I can do in WineCfg, or some configuration file for the game itself that will put the performance and graphics level closer to my Windows levels?
I have a good amount of Linux experience, but not much experience with Wine.
My specs are:
Pentium D 925 3.0ghz dual core
4gb ram (3 usable, since I'm on 32-bit)
Geforce 8600GT 512mb
Ubuntu 10.04
And the graphics are decent, though not quite as good as in Windows. And the performance suffers the same slight drop from Windows. For instance, I don't have shadows, or at best, they are of very low quality, and my cursor disappears unless I set it to software cursor.
So, my question is, how can I tweak the game's performance?
My specs are:
Pentium D 925 3.0ghz dual core
Geforce 8600GT 512mb
Your specs are low for STO, so you're not going to get smooth performance at better quality settings any ways. On top of that Wine on Linux will take a performance hit over just Windows. Wine is an emulator after all.
But as for graphics quality, I don't see what you would be forced to play at a lower quality. Are you sure the game client isn't automatically adjusting the graphics settings for you? Have you tried to go in and manually tweak graphics settings in the client to turn up the shadow quality?
I ran into an issue last week where a hardware problem caused my wine windows 'registry' to become corrupt, so I retried 2 installation methods suggested in this thread. (In fact, in the end, I tried 11 different permutations, perhaps qualifying me for a QA position, based on each of the methods described below.) To that end, I'm going to give a comparison and then illustrate pros and cons to doing it one way vs another. You, as a linux user, will be tasked with deciding which method is better for you. For simplicity, however, please select Windows XP as your OS within winecfg or winetricks. All the tests done on various flavors resulted in a lot of errors at various points in the install process.
For the purposes of my testing, I used wine versions 1.2.0, 1.3.2. I also used Nvidia Drivers 260.19.04 (and 260.19.06 as of last night) and 195.36.31.
Method 1: Easiest possible install by Agrinder
In this method, it was proposed that the user would simply install Wine (the latest stable release for your distribution), acquire winetricks, and then use winetricks to install 'corefonts', 'd3dx9', and 'ie7'.
Result: This works. With a caveat or two. You have an additional blank popup box appear whenever you launch the Star Trek Online executable (my supposition on the source of this is related to the rest of the caveats in this method). In addition, the screen does not update properly for the 'Engage' and 'Patch' button. Further, it doesn't say (outside of the title bar at the top) what the progress of the patching or verification of files is. It leaves the user somewhat blind to the current state of the patching process. If you're looking for the easiest method and don't care about the caveats mentioned, this is probably the one you want.
Method 2: Much harder installation method by me.
In this method, I mentioned configuration of various overrides prior to installing ie7 in addition to some dlls needed prior to installation. Once these steps were complete, the installation follows much the same as method #1 above for Star Trek Online.
Result: This works. With a caveat or two. This has a lot more initial steps in getting the ie7 installation working. At first gloss, ie7 appears to behave in the same fashion as it does in the other installation method. Indeed, the installation of Star Trek Online appears to be identical. What is different, however, is in the patching screen. Engage or Patch properly are marked depending on the state of the client. In addition, the status frame in the bottom middle works properly (indicating download size, amount patched, etc). If you're looking for the most complete method for client state and don't care if it involves more steps, this is the one you probably want.
Also, as hinted in the other posts, video drivers definitely seem to have an impact on stability. Moreover, if you have a hard drive with failures imminent or suspected (Gnome has tools that will let you see this in a graphical format -- or you can check using smartmon tools depending on your distribution), this could also manifest itself as either a game crash, a system crash, or unusual and unexplained errors. When in doubt, check your hardware - especially if the game is working most of the time and suddenly stops.
In the end, it is also a sane and safe idea to back up working and known working wine configuration registries. (Located in WINEPREFIX as *.reg) In addition, if you plan to install other applications using wine, PLEASE make sure to put them in separate wine bottles (wine installation directories for simplicity). When they are finished, winemenubuilder will install a link on most Linux desktops pointing to the proper wine installation. This prevents you from making a mistake (like Installing Vent and it crashing, or whatever) that will trash your working Star Trek Online install. (For example, I have 4 wine prefixes/bottles. I never trust a windows installer to work withour error.)
Note: Also, as mentioned by other wine contributors in this thread, UseGLSL, VertexShaderMode, and a few other options can more or less affect the stability of your STO install. In some cases, it may prevent you from working at all with the wrong options. When in doubt, try to go with the defaults and stay out of changing them unless you really need to do so. While performance can be a problem if you don't change some options, the bigger issue is that you may not be able to start the game at all (resulting in a Fatal Error screen that is vague and useless). So, before you make a change of any kind, do one of two things: Either backup your wine registry OR copy your wine bottle to another directory, set your WINEPREFIX to that directory - and make your changes there. (The latter method is safer, but takes longer to do and uses more diskspace. In fact, I used this method after getting a stock install with no options selected to have a referenced copy to work from.)
On top of that Wine on Linux will take a performance hit over just Windows. Wine is an emulator after all.
I'm not sure that statement is true - but I do agree his hardware isn't up to the task. Depending on options selected (within the registry as well as the game itself), it can have none to almost no noticeable difference. Indeed, all I found was missing wasn't performance related - but feature related within my graphics cards. Nvidia hasn't released full extension support in Linux like it does windows (even in the latest beta drivers where they're now adding extensions present in windows drivers - it's still incomplete).
Actually, I found my system less likely to have stalls and cranky issues during STFs in Wine than I did testing under Windows 7 natively with the highest optimizations present for each respective OS.
Mind you, this comes with the caveat that someone has followed my OS level suggestions regarding IO scheduling tweaks, PCI latency adjustments, readahead buffer changes, etc, for Linux.
Edit to add: The issue is not so much in that wine is causing performance issues or bottlenecks directly in so much as the issue is between opengl and directx.
For clarification, by and large, Linux drivers almost exclusively use OpenGL. This tends to mean graphics rendering is CPU bound and not GPU bound. So, the slower your processors are on your system, the slower game rendering is - even if a lot of the work is done on your GPUs. It's stupid, it's counterintuitive, but true. Even if a game supports multiple threads, they tend to offload other actions to those threads (sound, disk i/o, network i/o). You'll often find one processor almost exclusively favored in use in a thread and the others not so much. This is MOST apparent on my dual quad core system where I have a total of 8 processors available to the OS. One of them gets used almost to the exclusion of the others.
But, don't take my word for it, Tom's Hardware article spells it out.
Wine is continuing to work on their directx implementation, to be fair. But, the issue is not so much the emulation so much as the rendering method chosen.
For clarification, by and large, Linux drivers almost exclusively use OpenGL. This tends to mean graphics rendering is CPU bound and not GPU bound. So, the slower your processors are on your system, the slower game rendering is - even if a lot of the work is done on your GPUs. It's stupid, it's counterintuitive, but true. Even if a game supports multiple threads, they tend to offload other actions to those threads (sound, disk i/o, network i/o). You'll often find one processor almost exclusively favored in use in a thread and the others not so much. This is MOST apparent on my dual quad core system where I have a total of 8 processors available to the OS. One of them gets used almost to the exclusion of the others.
But, don't take my word for it, Tom's Hardware article spells it out.
Wine is continuing to work on their directx implementation, to be fair. But, the issue is not so much the emulation so much as the rendering method chosen.
Indeed. And here's the paradox: you have less overhead and a less-bloat, cleaner-running kernel with Linux to make things faster. But DirectX in Wine on Linux is adding layer upon layer, reducing the benefits gained from the faster kernel. Worse, DirectX games are designed for Windows to take the most advantage of DirectX tweaks to get the most out of a wide range of GPU/CPU combinations.
So in running a DX game on Linux, we take performance hits and performance gains. In the end we hope they work themselves out, but we know the performance curve is going to vary. As you said, his CPU is rather behind that curve for gaming in Linux.
Indeed. And here's the paradox: you have less overhead and a less-bloat, cleaner-running kernel with Linux to make things faster. But DirectX in Wine on Linux is adding layer upon layer, reducing the benefits gained from the faster kernel. Worse, DirectX games are designed for Windows to take the most advantage of DirectX tweaks to get the most out of a wide range of GPU/CPU combinations.
So in running a DX game on Linux, we take performance hits and performance gains. In the end we hope they work themselves out, but we know the performance curve is going to vary. As you said, his CPU is rather behind that curve for gaming in Linux.
I think you're misunderstanding the rendering method. We're not adding another abstraction layer. Wine isn't translating directx in this context. It uses its own GDI method instead. (OpenGDI is the default wine option.)
However, this can change entirely if you set the renderer to OpenGL. It's faster on more modern systems - but potentially another issue. Look at the rrm option in winetricks - or in your user.reg in Wine.
There is no directx analog comparison in Wine just yet. The version they have is incomplete and not ready - so we can't make a direct comparison yet. When we have them side by side, I will be more inclined to make a comparison.
At the moment, it would be more accurate to compare OpenGL to OpenGL on one OS vs the other. Unfortunately, most modern games do not give you that option - they use DirectX by default. Wine works around this by letting you specify OpenGL as your renderer. It's not a direct comparison.
But, yes, his CPU is going to be the problem - not his graphics cards - in Linux.
I am watching DirectX progress as it is added to Wine. I hope they have a working model to test in the next few months on most games - this would go a long way towards smoothing out installs and setups. And, of course, reducing overhead on CPUs. GPUs are actually substantially faster. Having the workload offloaded to them will result in speeds, I think, that would put Windows to shame.
I am watching DirectX progress as it is added to Wine.
DirectX is a proprietary library developed by Microsoft (originally developed 3rd party, then gobbled up by Microsoft, but that's beside the point). It isn't being "added" to Wine. People are installing it inside of Wine, and outside of its license. Otherwise they're forced to use OpenGL, which is a "layer" more so than DX that can talk directly to the hardware.
I'm not sure what you meant by "added" to Wine? Are you talking about 3rd party rewrites of the DX library or unlicensed installs of it?
Your specs are low for STO, so you're not going to get smooth performance at better quality settings any ways. On top of that Wine on Linux will take a performance hit over just Windows. Wine is an emulator after all.
Actually, STO runs rather well in Vista and XP with this hardware. (I have both versions of windows tweaked for maximum performance, but still.) Also, my processor is dual-core, in case I wasn't clear. So, it's not top-of-the-line, but it's no slouch either.
And I've seen plenty of games run better in Linux/Wine than in Windows, so I agree with AuntKathy that it's not as simple as saying that we should expect a performance drop. It might be true in this case, but I don't want to just give up on the idea of better performance just because it's in Wine.
In any case, thanks for the replies. I've managed to TRIBBLE wine/STO up, so I'm going to just remove wine and start over. So, I'll try the various suggestions and see where that gets me.
I've been trying to install DirectX in Wine, but I haven't been able to successfully do it yet. Assuming I am able to accomplish that, would STO in wine actually use DirectX instead of OpenGL? Is it worth the effort of attempting that?
Comments
Same problem, Its when the program is creating a shortcut, it stalls. Mine has the same problem, Not really sure what to do. :S
just make sure it at least has the Star Trek Online.exe on there... the rest of the install doesn't matter (besides to save time/bandwidth).
If you run Star Trek Online.exe and you are missing anything from the install, it will download/patch it and get it working.
with Wine 1.2, in the registry.. under Software->Wine->Direct3D you can add a string called StrictDrawOrdering and set it to disabled, and it will stop some weird performance drops, as things are able to draw a bit faster on the screen... seems to work good for me
Thanks for re-posting that here.
Hi there, i just installed STO but after start i only get this mentioned white screen and nothing else.
I installed ie7 and corefonts with winetricks too.
*edit: Maybe i know whats the problem. ie6 or ie7 never installed, cause i have a 64 bit linux and 32bit wine. Using winetricks to installe ie6 and ie7 then fails cause it detects my 64bit linux host and denies installing 32 bit ie. Strange thing cause all other 32 bit apps work..
*edit2: ok, i fxed my earlier problems by installing "bin32-wine_gecko" on my archlinux installation, now the launcher starts. I can fill in my credentials but i cannot hit the "patch" button.
Is there anything i have to do to get rid of it? I searched in this thread but i cannot find anything that helps.
Here is a screenshot:
http://www.abload.de/image.php?img=sto-white4vgz.png
edit: Don't know if this matters but i have a STO tray icon too. But i cannot interact with it.
Thx to all
That screenshot shows a line stating "Failed to init Gecko", I'm no expert however in my mind that would tell me your IE7 install is broken.
I noted a later edit to your post saying you can now enter login info but cannot click on patch, I still think IE7 is the problem even though it is semi-sorta working, I would recommend trying IE6 instead.
As far as getting rid of IE7, without reinstalling everything all over again, a sloppy and unrecommended hack would be to simply delete the folder IE7 installed to then install IE6 by running the command winetricks ie6″. If it doesn't work you might just be better off with a fresh new .wine folder as Winetricks recommends.
Personally I'm on a BSD box not Linux, and I had much better luck using IE6, when I tried IE7 it was all borked up.
I posted an article online about what I had to do to get STO running for me, it may or may not be of help to you or others.
The article is here - [ LINK ]
thx for your interest in helping, i will check your site.
I tried deleting the wine folder several times and created hundreds of new wine bottles but without luck.
It seems that this is a problem with my linux-/wineinstalaltion cause the problem, not being able to install wine is only present to me. On other archlinux computers it seems to work.
I made a thread in the archlinux forum, maybe someone can help me, cause this is not STO / wine related problem i think. The thread i'm talking about is this one: https://bbs.archlinux.org/viewtopic.php?id=102422
cya
Okies, sorry wasn't an easy fix for ya. I looked at the link detailing the IE6 install issue. Don't have an answer for you on that but I'll ask around with some folks I know and if I get any potential solutions I'll pass them along.
i found a way to get it installed. It was as simple as installing wine 1.2
You can read a more detailed description here: https://bbs.archlinux.org/viewtopic.php?pid=806104#p806104
Again, thx for your help.
I saw (and remembered having this issue before) that the Wine's internal internet explorer doesn't work at all (even wine 1.3.0's internal one blows up mightily). Gecko, for those who aren't familiar, is the firefox/mozilla core. Since this game seems to use IE semantics and operate under the assumption you have it, you'll definitely need ie6 or 7. From past experience, 6 works, albeit with either javascript errors or the occasional weird window that pops up for no reason during patching. During this install, however, I managed to solve the problem by skipping ie6 and going directly to ie7.
Mind you, this operates under the assumption you have a working wine install. I'm not going to include instructions for that part as it varies from distribution of Linux to distribution.
(Hardware: 2 Quad-core Opteron 2378s, 16G RAM, 2xNvidia GeForce GTX 275s in SLI mode, 4 1TB 7200 RPM Seagate Barracuda drives (in a software raid 10 configuration), using the SuperMicro H8DA8-2 motherboard -- overkill on the detail, but, eh.)
Distribution: Gentoo. Arch: amd64
(-O2 -march=native -mtune=native - for the Gentoo folks)
For the purposes of my testing, I tested both ~app-emulation/wine-1.2.0 and ~app-emulation/wine-1.3.0. (I masked the 1.3.0 version to test and it resulted in the same instructions as 1.2.0.) Also: ~x11-drivers/nvidia-drivers-195.36.31 (I might unmask the most modern but untested ones, but I am not yet sure I want to tempt fate.)
First, set the overrides, download the dlls, download and use winetricks to get the packages recommended by this article (ALSO: Please ensure you have installed 'd3dx9' via winetricks. This becomes important later...):
http://wine-review.blogspot.com/2009/02/ie-7-on-linux-with-wine.html
(For brevity, you can simply google the missing dlls you need. There's a website that has windows dlls for free.)
Once IE7 is working and installed, proceed to install Star Trek Online normally. Note, you'll also need to follow the instructions provided in the following STO post (page 34, post #335 of this thread):
http://forums.startrekonline.com/showpost.php?p=2472874&postcount=335
You may also need to disable the mmdevapi dll in winecfg depending on your distribution: Keep in mind, this instruction tends to apply if and only if you have a sound server installed in your X distribution. If you use ALSA (or an outdated OSS) directly without either esd or pulseaudio, you may not need to do that at all.
Note: The DXSetup piece (as mentioned in various threads) seems to stall but it isn't actually stalled. What you could do to find out what it's doing is via a program called 'lsof'. something like:
That segment will tell you what it's doing in the directory for the game... but...
You'll want to look for anything other than that directory:
The first field is the application, second is the process id, third is your username, 4th is the file descriptor (which tells you if it's being read, if it's a directory, or if it's in memory).. and skip to the last field (that's the file or directory that's open).
If you want to get a fair idea about what the progress is, open a large enough terminal and just run this via watch. Like so:
or to watch the Cryptic directory once that's past:
Mind you, it will take a trained eye - plus a harddrive activity light. But, you can also use: dstat to see it's writing to the drive:
By default, this updates every second, so you can see that there was a nice little burst of 69M written to my disk in that period of time. The two tools (regardless of linux distribution) should provide you enough evidence of what is occurring. It seems like DXSetup is stuck, but it almost certainly isn't. :-)
Edit to add:
There are some performance tweaks in Linux that may be of help -- but be warned, this is not for the tame or timid. Nor, unfortunately, is it for the folks who don't know what the implications are.
==> This is probably the most overlooked and most under-utilized option to improve performance. I didn't really consider it myself until I saw what I was missing. In my case, as much as a 50-60% improvement at high end video settings. Your mileage will vary. Gentoo is fortunate enough to include this in it's default desktop profile and an example config, but you may not necessarily need it either. Generally speaking, you want to, paradoxically, increase the latency to your pci devices except for things like your network and audio cards. This allows the cards enough time to receive, respond, and give appropriate warnings on data it as received. This 'opens up' the PCI bus and improves performance by and large. Most Linux distributions do not set this to an optimal value.
==> This is done in accordance to your video card type, vendor, and Linux distribution. It is highly recommended you read your distribution's guide on your particular video card. For gaming, however, very few cards beat or compete Nvidia in the Linux world. Nvidia offers a wide variety of distributions support and community help on gaming.
Also, make sure those changes are committed to your xorg.conf file - and X is restarted.
==> This instruction is for RedHat derivatives. You'll want to enable that service and run it. The readahead-early service is for faster boots and technically still outside of the scope of this... but while you're there... ;-) The 'readahead' service itself is the one we're looking for.
==> This is also one of those "oh, really, I didn't know about that" gotchas that many folks miss. If you're using Linux, you undoubtedly don't have an optimal read-ahead buffer setup on your system. By default, this set to 128k (or 256 512 byte block reads) on almost every distribution. The package will vary from distro to distro, but you'll want the 'blockdev' binary usually located in /sbin.
It will report this (and it has to be done as root) -- skip to the bottom of this bullet point for LVM:
To increase this value (also as root), you'll probably want a safe but reasonable value. If you do a lot of gaming with huge files (or massive video playback), you may want to set this to something like 8192 (or 4M in 8192 512 byte sectors)
Generally speaking, you could see about a 20-25% improvement in disk accesses for gaming.
Note, if you're using md raids for your disk partitions, the value of the block readahead can be checked on your raid device. So, substitute sda (or hda) for your raid partition (like /dev/md2). That value is set by the chunk size used when the raid volume was created. By default, this is an absurdly low value. Linux kernel tuning experts suggest values of 512k to 1024k for chunk goodness. That value is also determined by the raid type and number of spindles (or drives) in your array. In the case of Raid 10, it is (chunk size * spindles * 2). In my case, as I chose the value of 1024k as a chunk size when I created my raid partition, it was (1024 * 4 drives * 2) or 8192k readahead (or 8M). This is confirmed via:
If you're using LVM (Logical Volume Manager) which is a default on many RedHat derivatives, you'll want to change this in LVM directly rather than through blockdev. Find the partition and Logical Volume your games or data is stored on, then do this as root:
Unlike the blockdev changes mentioned above, this change is persistent upon reboot. blockdev changes must be put into a system startup script or they will be lost upon reboot. Play with a value that works for you - but no value larger than 8192 will provide any noticeable performance gains.
==> This is also often overlooked. This particular setup is done by some distributions but not others. Check your distro for support. Essentially, this links the libraries that you need into the binaries themselves automatically - shaving the need to re-read every library and library directory on the disk when a program is called.
==> This is very rarely used, but some distributions will allow you to install this daemon. Once running (give it a day or two), it will learn the frequency of which files tend to be opened the most. It will then load those most frequently used files into memory based on your individual patterns. It will make loading games or applications a lot faster.
Awesome post! Thanks for sharing this. Major kudos!
This awesome posting definitely reminds me of all the times I've sought for a solution to a tiny issue with something in Linux and found it in a Gentoo wiki or forum.
First the system I am running:
NVIDIA 9600GT with latest driver supported
Ubuntu 10.04
Wine 1.2 (Latest supported)
Do these steps in this order from here on in. These steps worked flawlessly every time.
STO will work straight up under Linux for just about any Distro provided you can do the following:
- Install latest Wine (above or better later)
- Install Winetricks
From here I will walk you through the setup that is error free install and run:
Before intalling STO:
- install corefonts via winetricks
- install d3dx9 via winetricks (Do NOT install DirectX itself)
- install ie7 via winetricks
- Now put your CD or copy to HD then run under wine.
- Follow the prompts and install as normal.
On completion do the following:
- Open wine configuration
- On the graphic card screen, do NOT select virtual desktop.
- select the first checkbox for the mouse and leave the rest as default.
On the Audio tab:
- Select Alsa (default unless your audio either works with another or works better with another)
- click apply/ok to close.
Now run the game, a white popup window will appear which is the ie7. Close it. login, run your updates which will take for freakin ever, and then play. Adjust sound and video in-game to what you like.
NOTE: When you alt-tab or anything that removes focus from the game, it will make the game appear as though it froze or locked up. This should not be the case. Look at the top left of your gamescreen and you should see a little 1" x 1" square. If you click that, it refocuses onto the game.
This was tested on Gentoo, Ubuntu and Fedora. Please respond to let me know if this does or does not work on any other systems.
Glad you edited the pompous sounding start.
is that really needed? runs fine on Mac OS X with normal wined3d, no need for any .dlls from MS.
In addition to my earlier post, I'm adding more "tweaks" and enhancements you can do to further improve your performance (and this helps Star Trek Online).
One of the interesting things I found out after perusing the Gentoo Sources package was that Con Kolivas writes some cool performance tweaks for the Linux Kernel specifically, as it turns out, for Gaming and Video under Linux. For reference: Con Kolivas' site. You'll want to verify what your specific Linux distribution recommends package-wise. The patches contained on this site are for those who build their own kernels. (Gentoo users: You can use ~sys-kernel/ck-sources and that does work with genkernel -- and also contains the same patches that Gentoo sources does. So, you get the benefit of a faster kernel with Gentoo features)
Key features that were in the kernel changes were tweaking the vm.swappiness variable to a 0 value (indicating not to swap unless you really need to and to try to keep everything cached instead). However, it also includes a "really use the swappiness value" patch since the kernel tends to, oddly enough, ignore the value even if you set it manually using sysctl. Another key feature of this patch is the inclusion of the BFS CPU scheduler. (This becomes relevant to a later section of this post.) There are some other tweaks to how the caching is done within the kernel as well.
Following a reboot with the ck kernel patches, you'll also want to install schedtools (if your distribution doesn't include it by default). This becomes an interesting tweak and one of those rare "huh, I didn't know about that" moments. After installing both ck kernel and schedtool, you'll want to probably make two adjustments prior to starting X. One, make every process currently running as root run in a scheduled batch mode. This means the priority and cpu provided to it operate under the assumption you won't be getting active video feedback (tail and top don't count) in real time. Two, we'll be making sure that when we start X, we do so with the ISO (real time feedback/response) mode.
To that end, prior to starting X, you'll want to do something like "pgrep -U root | xargs schedtool -B" in a startup script. Then, for starting your X session, you'll want to put "schedtool -I -e {command to start X goes here}". Mind you, these two will depend on your distribution - so follow those instructions for your distribution. For Gentoo, it was easy: "schedtool -I -e /etc/init.d/xdm start"
Those two commands told the system to schedule any non-X application (like cron, etc) to go into batch mode. Anything started by X (your window manager, your wine games, your X your interface altogether) will then be put into "ISO" or Interactive mode. Both of these are relatively safe changes and are not considered dangerous in terms of starving your applications for CPU. It just means you'll have an interactive desktop. Video should be a little snappier too with fewer stutters.
Edit to add: As an alternative, you can just schedule wine in Interactive mode, but it could potentially cause X to, paradoxically, become less responsive. To just schedule wine for interactive mode: "schedtool -I -e wine Star Trek Online.exe" or similar. I decided that it was simply easier to schedule X and everything it spawned as interactive rather than individual processes. This would have the least amount of maintenance for the most gain.
(One of these days, I'll get around to writing a blog on how to do other stuff in Linux that isn't included in most distributions by default like compiz enabled desktops, etc - but that's outside of the scope of this thread.)
I did not include those instructions for, unfortunately, a good reason: They did not work for me. I tried many possible variations and iterations. I spent a good part of 3 days trying all the variations. After doing a lot of research online, I determined a great number of folks were having the same problems in the same order for the same reasons as me. Thus, I wrote the post that addressed that problem.
Edit to add: In addition, I do not get an extra window popping up for me every time I start Wine for Star Trek Online. The only time I do is when I update wine versions - and that's before the Star Trek Online app starts (wine configuration is being auto-updated).
I think the problem centered around missing dlls for ie7. It refused to install stating it wasn't a valid OS. Thus, as I found in my research, it was necessary to trick ie into believing it already had the native dlls present (and why you need to do the overrides mentioned in the article). After making the requested changes, ie-7 installed (without updates) without a hitch. And, of course, Star Trek Online worked as expected.
Thanks. That was the intended theme of my post. :-)
it wasn't needed for me. It was just the dlls portion that blew up mightily for me.
"Shouldn't be", I agree. "Is", unfortunately. Otherwise, said post would not have been written (for Linux at least).
So far, through reading the advice in this thread and elsewhere, I've finally gotten to the point of being able to get into the game, and I even get sound. And the graphics are decent, though not quite as good as in Windows. And the performance suffers the same slight drop from Windows. For instance, I don't have shadows, or at best, they are of very low quality, and my cursor disappears unless I set it to software cursor.
So, my question is, how can I tweak the game's performance? Is there anything I can do in WineCfg, or some configuration file for the game itself that will put the performance and graphics level closer to my Windows levels?
I have a good amount of Linux experience, but not much experience with Wine.
My specs are:
Pentium D 925 3.0ghz dual core
4gb ram (3 usable, since I'm on 32-bit)
Geforce 8600GT 512mb
Ubuntu 10.04
Your specs are low for STO, so you're not going to get smooth performance at better quality settings any ways. On top of that Wine on Linux will take a performance hit over just Windows. Wine is an emulator after all.
But as for graphics quality, I don't see what you would be forced to play at a lower quality. Are you sure the game client isn't automatically adjusting the graphics settings for you? Have you tried to go in and manually tweak graphics settings in the client to turn up the shadow quality?
I ran into an issue last week where a hardware problem caused my wine windows 'registry' to become corrupt, so I retried 2 installation methods suggested in this thread. (In fact, in the end, I tried 11 different permutations, perhaps qualifying me for a QA position, based on each of the methods described below.) To that end, I'm going to give a comparison and then illustrate pros and cons to doing it one way vs another. You, as a linux user, will be tasked with deciding which method is better for you. For simplicity, however, please select Windows XP as your OS within winecfg or winetricks. All the tests done on various flavors resulted in a lot of errors at various points in the install process.
For the purposes of my testing, I used wine versions 1.2.0, 1.3.2. I also used Nvidia Drivers 260.19.04 (and 260.19.06 as of last night) and 195.36.31.
Method 1: Easiest possible install by Agrinder
In this method, it was proposed that the user would simply install Wine (the latest stable release for your distribution), acquire winetricks, and then use winetricks to install 'corefonts', 'd3dx9', and 'ie7'.
Result: This works. With a caveat or two. You have an additional blank popup box appear whenever you launch the Star Trek Online executable (my supposition on the source of this is related to the rest of the caveats in this method). In addition, the screen does not update properly for the 'Engage' and 'Patch' button. Further, it doesn't say (outside of the title bar at the top) what the progress of the patching or verification of files is. It leaves the user somewhat blind to the current state of the patching process. If you're looking for the easiest method and don't care about the caveats mentioned, this is probably the one you want.
Method 2: Much harder installation method by me.
In this method, I mentioned configuration of various overrides prior to installing ie7 in addition to some dlls needed prior to installation. Once these steps were complete, the installation follows much the same as method #1 above for Star Trek Online.
Result: This works. With a caveat or two. This has a lot more initial steps in getting the ie7 installation working. At first gloss, ie7 appears to behave in the same fashion as it does in the other installation method. Indeed, the installation of Star Trek Online appears to be identical. What is different, however, is in the patching screen. Engage or Patch properly are marked depending on the state of the client. In addition, the status frame in the bottom middle works properly (indicating download size, amount patched, etc). If you're looking for the most complete method for client state and don't care if it involves more steps, this is the one you probably want.
Also, as hinted in the other posts, video drivers definitely seem to have an impact on stability. Moreover, if you have a hard drive with failures imminent or suspected (Gnome has tools that will let you see this in a graphical format -- or you can check using smartmon tools depending on your distribution), this could also manifest itself as either a game crash, a system crash, or unusual and unexplained errors. When in doubt, check your hardware - especially if the game is working most of the time and suddenly stops.
In the end, it is also a sane and safe idea to back up working and known working wine configuration registries. (Located in WINEPREFIX as *.reg) In addition, if you plan to install other applications using wine, PLEASE make sure to put them in separate wine bottles (wine installation directories for simplicity). When they are finished, winemenubuilder will install a link on most Linux desktops pointing to the proper wine installation. This prevents you from making a mistake (like Installing Vent and it crashing, or whatever) that will trash your working Star Trek Online install. (For example, I have 4 wine prefixes/bottles. I never trust a windows installer to work withour error.)
Note: Also, as mentioned by other wine contributors in this thread, UseGLSL, VertexShaderMode, and a few other options can more or less affect the stability of your STO install. In some cases, it may prevent you from working at all with the wrong options. When in doubt, try to go with the defaults and stay out of changing them unless you really need to do so. While performance can be a problem if you don't change some options, the bigger issue is that you may not be able to start the game at all (resulting in a Fatal Error screen that is vague and useless). So, before you make a change of any kind, do one of two things: Either backup your wine registry OR copy your wine bottle to another directory, set your WINEPREFIX to that directory - and make your changes there. (The latter method is safer, but takes longer to do and uses more diskspace. In fact, I used this method after getting a stock install with no options selected to have a referenced copy to work from.)
I'm not sure that statement is true - but I do agree his hardware isn't up to the task. Depending on options selected (within the registry as well as the game itself), it can have none to almost no noticeable difference. Indeed, all I found was missing wasn't performance related - but feature related within my graphics cards. Nvidia hasn't released full extension support in Linux like it does windows (even in the latest beta drivers where they're now adding extensions present in windows drivers - it's still incomplete).
Actually, I found my system less likely to have stalls and cranky issues during STFs in Wine than I did testing under Windows 7 natively with the highest optimizations present for each respective OS.
Mind you, this comes with the caveat that someone has followed my OS level suggestions regarding IO scheduling tweaks, PCI latency adjustments, readahead buffer changes, etc, for Linux.
Edit to add: The issue is not so much in that wine is causing performance issues or bottlenecks directly in so much as the issue is between opengl and directx.
For clarification, by and large, Linux drivers almost exclusively use OpenGL. This tends to mean graphics rendering is CPU bound and not GPU bound. So, the slower your processors are on your system, the slower game rendering is - even if a lot of the work is done on your GPUs. It's stupid, it's counterintuitive, but true. Even if a game supports multiple threads, they tend to offload other actions to those threads (sound, disk i/o, network i/o). You'll often find one processor almost exclusively favored in use in a thread and the others not so much. This is MOST apparent on my dual quad core system where I have a total of 8 processors available to the OS. One of them gets used almost to the exclusion of the others.
But, don't take my word for it, Tom's Hardware article spells it out.
Wine is continuing to work on their directx implementation, to be fair. But, the issue is not so much the emulation so much as the rendering method chosen.
Indeed. And here's the paradox: you have less overhead and a less-bloat, cleaner-running kernel with Linux to make things faster. But DirectX in Wine on Linux is adding layer upon layer, reducing the benefits gained from the faster kernel. Worse, DirectX games are designed for Windows to take the most advantage of DirectX tweaks to get the most out of a wide range of GPU/CPU combinations.
So in running a DX game on Linux, we take performance hits and performance gains. In the end we hope they work themselves out, but we know the performance curve is going to vary. As you said, his CPU is rather behind that curve for gaming in Linux.
I think you're misunderstanding the rendering method. We're not adding another abstraction layer. Wine isn't translating directx in this context. It uses its own GDI method instead. (OpenGDI is the default wine option.)
However, this can change entirely if you set the renderer to OpenGL. It's faster on more modern systems - but potentially another issue. Look at the rrm option in winetricks - or in your user.reg in Wine.
There is no directx analog comparison in Wine just yet. The version they have is incomplete and not ready - so we can't make a direct comparison yet. When we have them side by side, I will be more inclined to make a comparison.
At the moment, it would be more accurate to compare OpenGL to OpenGL on one OS vs the other. Unfortunately, most modern games do not give you that option - they use DirectX by default. Wine works around this by letting you specify OpenGL as your renderer. It's not a direct comparison.
But, yes, his CPU is going to be the problem - not his graphics cards - in Linux.
I am watching DirectX progress as it is added to Wine. I hope they have a working model to test in the next few months on most games - this would go a long way towards smoothing out installs and setups. And, of course, reducing overhead on CPUs. GPUs are actually substantially faster. Having the workload offloaded to them will result in speeds, I think, that would put Windows to shame.
DirectX is a proprietary library developed by Microsoft (originally developed 3rd party, then gobbled up by Microsoft, but that's beside the point). It isn't being "added" to Wine. People are installing it inside of Wine, and outside of its license. Otherwise they're forced to use OpenGL, which is a "layer" more so than DX that can talk directly to the hardware.
I'm not sure what you meant by "added" to Wine? Are you talking about 3rd party rewrites of the DX library or unlicensed installs of it?
And I've seen plenty of games run better in Linux/Wine than in Windows, so I agree with AuntKathy that it's not as simple as saying that we should expect a performance drop. It might be true in this case, but I don't want to just give up on the idea of better performance just because it's in Wine.
In any case, thanks for the replies. I've managed to TRIBBLE wine/STO up, so I'm going to just remove wine and start over. So, I'll try the various suggestions and see where that gets me.
I've been trying to install DirectX in Wine, but I haven't been able to successfully do it yet. Assuming I am able to accomplish that, would STO in wine actually use DirectX instead of OpenGL? Is it worth the effort of attempting that?