Anyway, I guess most Linux users would advocate a OpenGL version rather than dx-anything. But I can't even start to imagine how much work it would be to rewrite the whole darn thing.
By the way, just spent two nights in a row racing FBM on demo servers after about 2 years not racing at all. 0.6E though, will try the latest patch tonight. Good fun!
Edit: Just tried LFS 0.6E17 in wine-1.7.18. It ran "fine" after using winetricks to install DX9, but not nearly with the same performance as in windows (but that is to be expected, I guess?).
The first DX9 enabled version (E15?) worked perfectly with the latest version of WINE at that time. Oddly enough I seem to be having an issue with E17. WINE 1.7.19 apparently fails to do some texture conversions and a lot of textures are missing as a result.
Are there any particular types of textures that are missing? I'm trying to understand why some would succeed and others would fail. Maybe a screenshot would help.
EDIT : I don't think LFS contains any relevant changes as I did not change anything to do with texture loading. From the vague information I found in Google from that error message, it seems to be a problem loading a DXT1 texture, which is pretty basic stuff for DX9. Is it easy to go back to the earlier version of Wine to see if LFS still works in that version? That would confirm that it's a new bug introduced into Wine, and I would hope the Wine developers can easily fix that.
i think theyre pretty clear in saying that theyve never officially supported anythign below 7 and that anything working on antique xp is luck but not to be expected
The problem seems to be isolated to JPEG textures - as is somewhat confirmed by this "fixme" message
fixme:d3dx:D3DXCreateTextureFromFileInMemoryEx Generation of mipmaps for compressed pixel formats is not implemented yet
I guess that a newer revision of DX9 introduced a functionality that is not supported yet by WINE directly. I'm on a less than useless mobile connection at the moment so I cannot grab the latest DX9 libraries and start experimenting but if it takes as less as telling WINE to use a native d3dx9 library I don't consider it a problem.
Any chance you can reupload E15 so we can verify that a native d3dx9 library is necessary only for E17 onwards?
I attached a screenshot to show what my LFS looks like now.
EDIT: I tried to downgrade to 1.7.18 (what's reported to work by felplacerad) and it exhibits the same behavior so I suppose that WINE really is lacking some functionality used by LFS.
Reverting to E15 doesn't fix anything which is rather odd because I'm absolutely sure it used to work before. It's however possible that I'd had the required fix already in place when I tested LFS in WINE last time. I replaced the hard drive in my computer some time after that so I might as well have forgotten all about it...
Putting "d3dx9_43.dll" into LFS directory and launching LFS like this:
WINEDLLOVERRIDES=d3dx3_43=n wine LFS
fixes the problem with no apparent side effects so I mark this problem as solved. It'll make a good WINE AppDB entry though.
But I noticed something wrong in your "code" section above, which says "d3dx3_43" but should be d3dx9_43 ... I'm just mentioning that as if you copied and pasted that from your real startup command, I guess it's not having any effect and you could leave that out?
Oh... I tried renaming the library to something nonsensical and the problem came back. I conclude that WINE uses the DLL automatically no matter whether I explicitly tell it to do so or not. I suppose that the "override" directive is needed only if the library is placed in the WINE's equivalent of "system32" directory, whereas I put in directly into LFS directory to avoid any potential problems with other applications.
I'm using wine 1.4.1. I have no wine dll overrides set.
I tested removing the d3d files from my fake system32 folder and indeed had lots of errors with textures.
Unless your machine is really old, no. Performance should be quite similar. Sometimes it's even sightly faster on WINE, probably due to some duplicate calls being filtered out.
I find it funny how Windows users complain about support from a 12 year old OS, from a company that has a three to five year release cycle of Operating systems, and a 9-12 year support cycle. $119/upgrade, or less than $40/year
Let's compare to other popular OS...
MacOSX has a "support 2 versions back" policy, but a yearly release cycle, and you have to upgrade or get left behind. $50/year
Ubuntu Linux releases every 6 months, with an LTS version every year and a half. Regular versions are supported up until the next release, and LTS has 3 year support. Like Apple, upgrade or get left in the dust. And by the nature of Linux, the system can get quite dirty with orphan files when upgrading. Free of course
If your computer was Vista capable, you can run Windows 7 or 8 no problem.
So stop complaining about old systems and support for XP. It is time to leave XP behind and end the myth that Windows is the most insecure OS.