No longer works in Wine

ZOS_MollyH · March 2016

Hey @NerfPlease !

Per system requirements, OpenGL has not been supported on PC. It was temporarily used as a workaround, but it is not a supported environment. DX11 is required for minimum specs per our system requirements.

Billtheman · March 2016

Molly can you just answer one question yes or no. Are you forcing DX11? I think if you check you will find that you are forcing DX11 so that OPENGL cannot work because only DX11 can work.

ZOS_MollyH · March 2016

Hey @Billtheman ,

Unfortunately we don't have that information available. All we can provide at this time are the supported system specs, and that Wine/Linux environments are not nor have they ever been a supported OS.

NerfPlease · March 2016

@Billtheman man, i think it must be some workaround

first time i need to google some 3rd party sites to find a way... i hope it will be not a hack way
i will try reddit first

KhajitFurTrader · March 2016

Billtheman wrote: »

Molly can you just answer one question yes or no. Are you forcing DX11? I think if you check you will find that you are forcing DX11 so that OPENGL cannot work because only DX11 can work.

Before ESO version 2.3.0, the Windows client featured three distinct rendering paths: Direct3D 9, Direct3D 11, and OpenGL 2.1. The latter shared a common code base with the Mac client, i.e. they used the same tech and tool chain, most likely a third-party, cross-platform library or SDK. We all know that the first rendering path (D3D9) was dropped in order to prepare for DirectX 12 in the future, so that two DirectX rendering paths -- which will have to be maintained separately, in both 32- and 64-bit code branches -- will remain on the Windows client. This makes sense from a economy of code maintenance point of view.

Now that the Mac client features a brand new OpenGL 4.1 rendering path, the assumption can be made that this was a Mac-only development, using code and tech specific to OS X, and supporting 64-bit only. Why?

The 32-bit client on Mac was dropped completely, there is no longer a 32-bit option on OS X.
There is no fallback option to OGL 2.1 at all in the new Mac 64-bit client.
From 1.) and 2.) it can be concluded that the old OGL 2.1 tech could support 32-bit only.

This leaves us with the following propositions:

The old OpenGL 2.1 rendering tech could not be ported to the new 64-bit version of the Windows client.
The new OS X OpenGL 4.1 tech -- assuming it could be ported to Windows at all -- is unfit to run in a 32-bit memory model; the patch notes explicitly state that the new 64-bit Mac client needs more memory (8 GB minimum is recommended), and systems below this amount will see detrimental effects to performance (paging etc.).
This would leave the Windows client with two separate, incompatible OpenGL rendering engines in two different code branches -- needless to say that this is every developer's nightmare. It would totally fly in the face of economy of code maintenance.

OpenGL support on Windows was likely scrapped due to a irreconcilable 32/64-bit dichotomy of the code. Given both the facts that a) Windows continues to need 32- and 64-bit code bases in the foreseeable future, and b) OpenGL was ever and continues to be poorly handled on Windows by the GPU manufacturers (i.e., DirectX will always be better optimized in drivers, because that's where the benchmarks count), the decision to forego OpenGL on the Windows client might have been the only sensible one.

NerfPlease · March 2016

^ this answer must be from ZOS team
answer like this

see - the person know what he s talking about, not like previous green answers in this topic

i just hope Wine will come with DX11 support this year...

Megalex1 · March 2016

Alternatively you can just install a real gaming OS like Windows and enjoy the game

KhajitFurTrader · March 2016

NerfPlease wrote: »

^ this answer must be from ZOS team

It is just my educated guess, concluded from my own observations, tidbits of "green" information, and decades worth of experience related to software development. Please do not take it as official canon, because it isn't. As a pure conjecture, it might even be far from the truth.

BDB_Inc · March 2016

ZOS_MollyH wrote: »

OpenGL used in Windows can use up twice the memory as using DX11, which is likely why it's not working. On OSX, OpenGL is a requirement as well.

@ZOS_MollyH,

If the memory usage of OpenGL was the issue, the game would start and run until it ran out of memory and then crash. It's not starting at all now, so it's not due to memory usage. I ran this game for a year on OpenGL and it didn't seem to crash more frequently for me than it did for my friends using Windows and D3D11. I used to run for hours without a problem.

Since the work has been done to implement OpenGL in OS X, couldn't some of the work and/or knowledge gained by the ZOS development staff be used to implement OpenGL for the Windows version? If successfully implemented, this might bring back some of the Windows users who have left, as well as some of the Linux folk.

Merlight · March 2016

KhajitFurTrader wrote: »

Now that the Mac client features a brand new OpenGL 4.1 rendering path, the assumption can be made that this was a Mac-only development, using code and tech specific to OS X, and supporting 64-bit only. Why?
The 32-bit client on Mac was dropped completely, there is no longer a 32-bit option on OS X.

There is no fallback option to OGL 2.1 at all in the new Mac 64-bit client.

From 1.) and 2.) it can be concluded that the old OGL 2.1 tech could support 32-bit only.

Since OpenGL is a cross-platform API, such constraints would've been self-imposed by ZOS. One does not simply cut development costs by refusing to write portable code. Withdrawal of OpenGL renderer from the Windows client was deliberate. And apparently it affected not only us Linux free-loaders.

KhajitFurTrader wrote: »

b) OpenGL was ever and continues to be poorly handled on Windows by the GPU manufacturers (i.e., DirectX will always be better optimized in drivers, because that's where the benchmarks count)

This argument is moot when D3D11 doesn't work at all. Same for the argument about higher memory requirements.

KhajitFurTrader · March 2016

Merlight wrote: »

Withdrawal of OpenGL renderer from the Windows client was deliberate.

Well, of course it would be, or else the option to use OpenGL on Windows would still exist in one form or another, wouldn't it? I'm not privy to their internal deliberations and can only speculate on their reasoning, which I said.

I took into consideration that originally, they had used third party cross-platform tech to implement the OpenGL 2.1 renderer on both PC and Mac platforms, i.e. they had cross-platform development & debugging cut out for them for a big, non-trivial part. If this (presumably old and obsolete) tech could not be transferred over to 64-bit for whatever reason, and if the 32-bit OS X client was dropped anyway, how could it then be justified to let it remain solely in the 32-bit Windows client?

Assuming that the new OpenGl 4.1 renderer is home-brewed, and/or relies on non-cross-platform SDKs (e.g., those from Apple), porting the code over to Windows and testing/debugging it might have been an additional, considerable amount of work, which might have been cut due to manpower and/or time restraints. Only one year ago, nothing looked like a 64-bit client was even on the radar until after the console launch. I think it was them hitting a hard limit with Orsinium/Wrothgar design (5th paragraph), that served as a wake-up call for the sake of future development.

Merlight wrote: »

This argument is moot when D3D11 doesn't work at all.

Huh? I've read numerous reports from Windows users to the contrary.

kenjitamura · March 2016

I certainly hope they stop the DX 12 port they said they've been working on and transfer the work over to Vulkan since much of that work is likely applicable to a Vulkan port. I can understand Zenimax being resistant to an OpenGL client for Windows but no argument against OpenGL can be carried over to Vulkan. It is an API not burdened by legacy cruft, maintains feature parity with DX12, has widespread industry support, and has some very good debugging tools as well as lots of documentation and free source code examples floating around.

For now I caved and got myself a Windows license for dual boot, though I was extremely reluctant, and it'll be used solely for this game. But the moment a decent B2P MMORPG competitor with OpenGL/Vulkan support becomes available I fully intend to jump ship and erase my Windows partition.

Nausix · September 2016

Ok, after a few month without playing I thouth "hey! let's get some nice gaming with ESO" and then I quickly realise the thing.

That is really Lame. You did a lot of work already to make it work under OSX and never went to make it run under linux. Alright, we could still run it under wine using the OpenGL support and then you remove it. I mean, what is wrong with you? There is already lot of nice MMO out there that keep this support and even give a place for a community. I think about WoW and Guildwar and LoL and Diablo 3.. ok forget D3, but many other keep it alive, they don't "support" it officially, but they don't shut it either. I'm going to play another game and .. well you totally know what I mean, read my lips.

furryn · October 2016

I feel like throwing myself to the floor, crying and wailing hysterically.

I FINALLY have a bit of time to game again. I REALLY want to play elder scrolls. and i REALLY want to play with others.

But i have Ubuntu, and no wish to dual boot as it's super annoying, and then... THIS?

TESO had it's flaws in the early days, but it grew to be a really good game. I'm so very sad to see it take this turn of events.

On one hand, i guess i could suck it up and install windows. I do have the licenses for it. On the other? Well, I switched to Ubuntu to use Linux as my only OS. This is the year of 2016, even Microsoft have embraced Linux, why are you game devs so friggin stubborn about it? You could port the game to Vulkan and have super performance across all platforms, but instead you choose to go the DX way? are you kidding me?

You realise the death of the elder scrolls series, if anything, will be the technological narrowmindedness. Skyrim used an old Game engine, solid, but still felt aged. And i heard that engine was reused for Fall Out 4 (seriously?) And now this?

This frustrates me so much. The Elder Scrolls games were always about choice, but I guess that's only ingame, huh?

ALSO: saying that it's stupid to buy such a game to play it in wine might be true. But perhaps it should be thought of differently: We spot a great product that we like, and actually take out some of our hardearned cash to buy it. Instead of saying "we never supported wine or Linux and never will" you might say something like: "We hadn't thought it'd cause an issue, but we will take your complaint to heart" you know, sort of like GoG.com does: They're helping develop and maintain PoL scripts for their games so that Linux users can enjoy non-native games as well. THAT is good customer service.

KhajitFurTrader · October 2016

furryn wrote: »

Skyrim used an old Game engine, solid, but still felt aged. And i heard that engine was reused for Fall Out 4 (seriously?)

Bethesda Game Studios has been using their in-house tool chain for developing their games for a long time -- it grew and expanded together with every new game of the Elder Scrolls and Fallout single-player game series at least since Morrowind/Fallout 3. This isn't something you abandon and replace with something else on a whim. Games take long enough to develop anyway, trying to cram new/other tech than the tried an proven tools (and the compile targets they support) into the process would make it even longer. New tech only comes to new games when the tool chain has been updated to support it.

That's the main reason why (recent) BGS games support only some platforms: DirectX on Windows/XBone, and PS4. Support for macOS isn't very likely to ever happen with the tool chain in place, and personally, I don't expect it to be. On the other hand, when ZeniMax Online Studios fist started out with ESO in 2007, they decided on the platforms the game should run on and planned accordingly; cross-platform 32-bit OpenGL 2.1 support was to be provided by 3rd party SDKs, which served Windows and OS X well at the time (although officially, OpenGL was never mentioned as being supported on Windows, as by the System Specifications). But in contrast to single-player games, MMOs are long-lived: they get tech updates to their engines during their lifetimes. So years after initial development, when the decision to support 64-bit code and (future) DirectX 12 in the client came around, that older OpenGL SDK no longer fit the bill, and was dropped. I've explained it all in the post above.

furryn wrote: »

And now this?

Now? It's been 7 months by now...