Slashdot Mirror


Square Enix Pulls, Apologizes For Mac Version of Final Fantasy XIV

_xeno_ writes: Just over a week after Warner Bros. pulled the PC version of Batman: Arkham Knight due to bugs, Square Enix is now being forced to do the same thing with the Mac OS X version of Final Fantasy XIV (which was released at the same time as Batman: Arkham Knight). The rather long note explaining the decision apologizes for releasing the port before it was ready and blames OS X and OpenGL for the discrepancy between the game's performance on identical Mac hardware running Windows. It's unclear when (or even if) Square Enix will resume selling an OS X version — the note indicates that the development team is hopeful that "[w]ith the adoption of DirectX 11 for Mac, and the replacement of OpenGL with a new graphics API in Apple's next OS, the fundamental gap in current performance issues may soon be eliminated." (I'm not sure what "the adoption of DirectX 11 for Mac" refers to. OS X gaining DirectX 11 support is news to me — and, I suspect, Microsoft.) Given that the game supports the aging PS3 console, you'd think the developers would be able to find a way to get the same graphics as the PS3 version on more powerful Mac OS X hardware.

17 of 94 comments (clear)

  1. DirectX 11 for Mac by Anonymous Coward · · Score: 2, Insightful

    Wait what?????????

    1. Re: DirectX 11 for Mac by adler187 · · Score: 4, Informative

      Probably referring to http://boilingsteam.com/codewe...

    2. Re:DirectX 11 for Mac by beelsebob · · Score: 3, Informative

      No, Metal for Mac, which is a graphics API that works in a similar way to D3D 11/12. i.e. not a state machine, but instead issuing buffers of commands based on pre-verified states.

  2. Blaming their tools by Viol8 · · Score: 4, Insightful

    Sounds to me like they Driect X coders who don't know how to code for OpenGL properly but instead of fessing up they decided its easier to blame their tools than themselves. Poor workmen etc...

    1. Re:Blaming their tools by tk77 · · Score: 5, Interesting

      Whats worse is that it appears they weren't even developing for OpenGL, but rather using Transgaming's (nVidia) cider to translate DX calls to OGL.

      "...it works by employing middleware developed by TransGaming (presently NVIDIA) to convert Windows’ DirectX drawing method into OpenGL on Mac systems."

      They then go on to compare OGL and DX and claim that if it was developed natively for OGL there would be a 30% performance gap. Excuses for laziness, in my opinion.

    2. Re:Blaming their tools by beelsebob · · Score: 4, Informative

      That would be because the PS3 and PS4 use sony's proprietary graphics API that looks nothing like OpenGL.

      The OpenGL API contains various features that are simply not conducive to writing either a fast implementation of the standard, or a fast application that uses it. The two main issues are:

      1) That OpenGL is a state machine, draw calls are issued at arbitrary moments when in arbitrary states. This means that the implementation can't validate that the draw call was made in a valid state until you actually make the call. That doesn't sound like much, but it actually turns out to be a major headache. It means that compiling shaders can end up delayed until you actually make a call because you don't know what vertex formats it'll read, what blending modes it'll use, etc. It means that uploading data can be delayed until you make a call because you don't know what format it needs to be in. It means that blobs of data can't be placed in the right area of memory because you have no knowledge of whether the memory needs to be for fast reading only, fast read and write (only on the GPU), pulling off the GPU onto the CPU etc.
      2) That lots of OpenGL operations are explicitly thread safe, and there's no way to tell OpenGL about the fact that two operations won't interfere with each other. Want to overwrite an area of a texture for the next frame while the previous frame was rendering because you have knowledge that the two won't try to read and write the same area at the same time? Nope, tough shit, can't be done. Uploading the texture will block waiting for the GPU to finish rendering with it.

      Apple acknowledges that these are problems, and as a result, they've made their own graphics API (Metal) which is much more similar to how D3D and Sony's proprietary APIs work. Thankfully, the next OpenGL spec (code name Vulcan) will head towards this way of doing things, and maybe we can get back to the standard open way of doing things being reasonable.

    3. Re:Blaming their tools by Damarkus13 · · Score: 4, Insightful

      They didn't even try. They slapped a compatibility layer (Cider) on their DX11 engine and now are acting shocked that the performance is terrible. Sounds to me like management looked at the cost of licensing Cider vs. the cost of actually writing an OpenGL engine. It's probably not the workmen's fault.

  3. Exactly what I was thinking by drinkypoo · · Score: 4, Insightful

    Even though the GPU makers focus on D3D and not OGL the GL performance is usually quite close to D3D. So when people start blaming their woes on OpenGL I start assuming they don't know what they're on about.

    --
    "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  4. I wouldn't blame the coders by alexhs · · Score: 3, Interesting

    I wouldn't blame the coders, unless they where responsible for the technology choices

    It's first and foremost a management issue :

    However, in the chaos leading up to the multi-platform launch of our expansion, we released incorrect requirements, which were not updated prior to the Mac version’s official release.

    However, due to our miscommunication with retailers, the Mac version was made available earlier than intended. As a result, some customers were able to download and play a pre-release build which suffered from performance problems.

    If that's not management rotten to the core, what is ?

    Rather, it works by employing middleware developed by TransGaming (presently NVIDIA) to convert Windows’ DirectX drawing method into OpenGL on Mac systems.

    Any company relying on Microsoft technology to achieve cross-platform deserves a spectacular failure anyway.

    --
    I have discovered a truly marvelous proof of killer sig, which this margin is too narrow to contain.
    1. Re:I wouldn't blame the coders by _xeno_ · · Score: 2

      If that's not management rotten to the core, what is ?

      Final Fantasy XIV is kind of the poster child for bad management at Square Enix, to the point where they actually fired the original management team. This new fiasco is from the team hired to replace the original team.

      Any company relying on Microsoft technology to achieve cross-platform deserves a spectacular failure anyway.

      Which makes no sense, because they've already ported the graphics engine twice! The game also supports the PS3 and the PS4. If they can deal with three different graphics engines, you'd think adding a fourth would be no big deal.

      --
      You are in a maze of twisty little relative jumps, all alike.
  5. Re:Why release it? by carlhaagen · · Score: 4, Informative

    I've programmed portable OpenGL-based applications for many years for the three dominant desktop platforms - Windows, Linux, OS X - and I have no idea which million issues on OS X and its implementation of OpenGL it is you refer to.

  6. Re:Why release it? by jo_ham · · Score: 3, Informative

    You don't need Apple's drivers for bootcamp for the GPU - you can just install the AMD or Nvidia ones that AMD and Nvidia supply for windows.

    The one Apple ships with the bootcamp driver package (that you install from a USB stick when you first set up windows and has everything you need for the keyboard, networking, bluetooth, etc) includes one of those OEM drivers from AMD or Nvidia, it just tends to be an older one since they don't update the package all that often.

    Once you have windows installed though it's no different to any other windows machine in terms of GPU drivers.

  7. Re:Mac OS and retina screens. by maccodemonkey · · Score: 4, Interesting

    I have a MacBook Retina which I use for development, it has a 2880x1800 screen, but to you need to go into 'Display' and set it to Scaled and 'More Space' in order for it to render like it has a 1920x1200 screen. So non retina applications the OS reports the resolution to be 1920x1200, then it upscales the application window to 3840x2400 and also does composition at 3840x2400, which is then downscaled to 2880x1800 and displayed. Performance gets even worse if you also have an external screen, because and it also does the same if you have an external 3840x2160 and downscales to 1920x1080. Basically you add an external 1080p screen and it will try to make the integrated graphics render graphics for basically two 4k screens.

    When you run in scaled mode like that, ALL applications over-render. Both retina and non-retina. It's why I really suggest people avoid the scaled modes.

    Non-scaled displays do not scale. I've verified that at work. So external displays do not over render unless you have a 4k display and you've put it in a scaled mode.

    Games are actually one exception. A full screen OpenGL game gets to directly output properly to the screen. Full screen OpenGL doesn't get scaled or over rendered. I've verified this on multiple Apple platforms with OpenGL code of my own. It means on a device like the 6 Plus where scaled output is normal (the 6 Plus has a 1080p screen but has a much higher res frame buffer) OpenGL performance isn't degraded. I even have non-full screen OpenGL code that doesn't get over-rendered either.

    My guess is that none of the original article has to do with scaling at all. It's likely they're using something like Cider that abstracts DirectX calls to OpenGL, and has always really sucked for performance. (EA did several ports with Cider and they all had severe performance issues as well.) OpenGL on the Mac also just has general issues.

  8. race to the bottom by Anonymous Coward · · Score: 3, Insightful

    I'm noticing a trend here, all these high profile, multimillion dollar budget games that run on the latest h/w all have major bugs. And I mean major bugs that ruin the experience. With these sky rocketing project budgets is kinda odd.

    Could it be that big budget games are getting pressure by their iOS/Android counterparts (hence rushed and over hyped?) ? Sounds similar to youtube/shorts/webisodes vs scripted major network content.

    Or is it that with all the great tools and superstar coders mean nothing: rushing a major game to market (within 1 yr) has hit its limits, games take 12-16months for example. Otherwise expect some level of failure. No different from a Pixar movie that typically takes 4yrs, compared to a 35 day Transformers shoot..... time == quality.

  9. Re:Why release it? by tlhIngan · · Score: 2

    They probably just ran into a million issues on OS X and its implementation of OpenGL and Apple doesn't give a shit.

    I also never heard of DX11 on OS X. I imagine he must be referring to Bootcamp, although I don't know the state of Apple's drivers for bootcamp.

    I guess they could have just not released the game in the first place instead of pulling it later...

    No, they basically recompiled their app using a Windows API library.

    There are lots of Windows API libraries - like WineLib - where you take your Windows source code, compile against the library and you have a Mac/Linux/Etc. app.

    Square used Cider, which is an older port of WINE (before WINE switched licenses because TransGaming was effectively selling WINE without contributing back)

    And no, there is no "DirectX for OS X". There's a DirectX API provided by the library that runs on top of OpenGL. Basically they're hoping the next release of Cider will have improvements in the Windows API library.

    But it still will run like crap. Because it's a Windows game that runs on a Windows API emulation layer that runs on top of OS X. So of course, when you add in the library, it's no wonder performance on OS X sucks - OS X is running a virtual Windows API layer.

    The reverse is also true - iTunes/QuickTime are notorious offenders in the "runs like crap" category, because they do the same thing - Apple has an OS X API layer that runs on Windows, and it's that OS layer that iTunes runs on.

  10. It's a start by Tifer · · Score: 2

    Now they should apologize for *all* versions of Final Fantasy XIV.

    1. Re:It's a start by sandytaru · · Score: 2

      They apologized for 1.0 because it was bad. But 2.0 was pretty good, and the new expansion (dubbed 3.0) is so crammed with fan service that we decided that they're never going to remake 1-6, they're just going to put all the contents of those games into XIV and call it done.

      --
      Occasionally living proof of the Ballmer peak.