View Single Post
Cryptic Studios Team
Join Date: Sep 2012
Posts: 59
# 520
03-03-2013, 01:22 PM
Quote:
Originally Posted by evilgenius180 View Post
I don't think it so much lies as it's that WINE is an emulator (no matter what they claim on their site.) When you run an emulator, it has to run on the host system, so it literally can't pull in your total system resources, it has to save some for the host OS. It's the same problem from which virtual machines suffer.

As for my system, I was able to put some of the sliders up higher. I set the texture quality to 200 without slowing the game down. Anti aliasing seems to slow it down a little, so I just left it off. I noticed the shadow quality setting only has "Low" and "Off" for settings, I had a "High" setting under Windows. I could run the game under maximum settings in Windows and it ran smoothly. But, I'm willing to put up with the reduced settings in order to not have to run Windows anymore. I was literally only running it for a few games.
See, that's what I'm talking about, though. WINE is telling us that we can't do some random rendering feature that'll allow us to have decent looking shadows, even though it can.

At one point I had a hack inserted into the renderer setup that made it ignore everything the capabilities queries said if it detected that WINE was present and we could turn all the shadows up with no problem. Unfortunately, while shadows worked fine, some other stuff did start breaking (unrelated to shadows), so that never made it into the client we send out. (And despite me playing around with this in my personal time in the past, Cryptic doesn't officially support this.)

And I disagree with your assertion that WINE is an emulator. It's a re-implementation of the Windows libraries, but the code does not run in some emulated virtual machine where each opcode must be reprocessed and translated, or JIT compiled into something else. All the code in an application running under WINE that doesn't touch the Windows API directly runs, effectively, as native code, and it's just about as capable at using up system resources as any native application.

The problem we're dealing with here is just the buggy DirectX to OpenGL wrapper that makes up their DirectX implementation. (Okay. So it's more complicated than just a wrapper.)