For me the most interesting part (and answer to it) why on OS X the game runs at 1FPS, whereas on windows machine with the same graphics card it runs just fine?
I have never seen such huge difference. I'm playing and making games and most of them run 10% faster on Windows at most, and this is due to graphics driver.
However, there is one thing that is a major difference: the system timer. Windows sleep() call has a granularity of 10ms, while OSX one has 1ms. So, if you (or your game library) is using sleep to return unspent CPU time to OS, it's easy to write the code that would run fast on one OS and very slow on the other.
Most developers treat OSX version as a checkbox on their "required features list" and only care whether the game works or not when porting. They do not want to spend time looking at the intricacies of OSX and just tell you that it's graphics driver's fault.
I develop games on Linux and OSX and later port to Windows before releasing (because that's where the players are), so I have to write specific code for Windows to make sure it runs faster. For example, my latest Steam game was really lagging and slow on Windows until I figured out the timer problem I wrote about above.
Other developers do it the other way around, and OSX performance isn't top priority.
OpenGL is not the same everywhere even on the same GPU.
Every driver can negotiate its capabilities with the client app.
Apple has a software renderer that takes hold if client ask for an extension the gpu doesn't have, you have to ask a render surface in a specific way to get an error back when you ask ans unsupported feature.
At least that was the case when I last worked on a OSX app.
"Since the OpenGL framework normally provides a software renderer as a fallback in addition to whatever hardware renderer it chooses, you need to prevent OpenGL from choosing the software renderer as an option."
also note that 1 this might not be the banished problem and 2 this may be an outdated document
This is a good hypothesis. A difference in a few FPS could be attributed to less efficient drivers on one platform, but dropping to 1 FPS sounds to me like he's hitting a software rendering path on one platform and is fully HW accelerated on the other. I admit, it's been over a decade since I wrote OpenGL drivers, so perhaps things have changed drastically and my intuition is out of date.
1 FPS sounds like software rendering. He probably accidentally requested some OpenGL feature which is not hardware accelerated in his GPU, so the whole pipeline transparently switched to software rendering to be able to fulfill his request.
OpenGL on OS X has platform specific quirks which can require using different methodology. Linux developers of Witcher 2 (from VirtualProgramming) stumbled on various parallelism issues when trying to port their OS X version of eON wrapper to Linux. See https://github.com/virtual-programming/witcher2-linux/issues...
To put it shortly - you can't just assume "it's all OpenGL so same code will work the same".
It should be something elementary the author still hasn't implemented properly during his porting actions. He says that he has "specific startup code" in "two different sets of the same GL code" in "copy-pasted-slightly-edited" form and that he "started writing things specific to OSX. Memory management, file I/O, timers, date handling, threading, etc."
Basically, there's a lot that could possibly go wrong during his first days of porting, and after all that he just saw "the title screen" and observes 1 FPS rendering. So it can be anything, it's too early to know, I hope the author posts later what was missing.
The existing OSX drivers are surely good enough for games, so it's the problem of the use and surely not the case that "the platform doesn't allow" or the "drivers."
Also note that it's not about DirectX vs OpenGL. He has OpenGL on Windows too (see the first paragraph here for the quote).
Drivers. On MacOS they tend to be a bit behind the Windows versions, also MacOS itself is reasonably GPU-heavy. Add to that Apple's tendency to lag behind the latest (as in from the last five years) OpenGL standards and you've got a recipe for slow OpenGL.
Though interesting that it's an Iris Pro, MacOS used to have the best Intel drivers as Apple pulled them in-house. ATI and NVidia have always treated MacOS as a secondary target.
If it was a 10% performance hit, I could blame the driver but comparing 60 FPS (I presume) with 1 FPS when people are playing the game in Mac OS X using WINE; that sounds like something is probably not quite right in his code.
I also found that even with a GPU-heavy fullscreen application, having another (smaller) window on top doesn't noticibly degrade rendering performance. It seems the window manager is doing some clever things there in regards to compositing.
This makes no sense since OSX is certainly capable of the same level of graphic performance as any other OS (some would say it has even more powerful low-level tools now that Metal is available), so there must be something else going on in his setup that is causing a problem. As others have noted, possibly the drivers, but more likely he's not using the Mac's API to guarantee GPU rendering vs software rendering, or other fairly small settings that can lead to a big difference.
I don't have the links with me, but I've read somewhere that this happens because Windows uses DirectX, whereas OS X uses OpenGL.
I assumed this is because Game Engines are built usually targeting Windows/DirectX. Some say that DirectX is more mature and powerful, although this might be subjective. And so the games perform better on Windows.
FYI,
With the advent of Vulkan, maybe subjective opinion that DirectX is better than OpenGL dies down, as Vulkan is supposed to very good - kind of like a rewrite of OpenGL.
And with DirectX 12 on Windows 10, Microsoft has done a lot of good stuff.
Vulkan is still in development. It is based on the same concepts as Apple's Metal, AMD's Mantle and Microsoft's DX12, i.e. low-level access to the GPU.
Which is pointless if you are limited to a MS only walled garden. Also, rushing it out ahead just to be first isn't a plus if it has deficiencies that could be fixed before the release. Vulkan is developed with reasonable pace and it's good that they aren't trying to rush it out before it's ready.
> Professional game developers don't have any issues with walled gardens.
That's nonsense. Tell them that doing double work is a good thing (especially for the limited budget). No sane developer likes walled gardens and lock-in because it always translates in complications (not caused by real technical reasons), and doing the same work multiple times to address stupidity of vendors who push said lock-in.
> That is how the industry has survived
Saying that industry survives on lock-in is like saying that technology survives on the lack of progress. I.e. it's a completely backwards thinking.
However, there is one thing that is a major difference: the system timer. Windows sleep() call has a granularity of 10ms, while OSX one has 1ms. So, if you (or your game library) is using sleep to return unspent CPU time to OS, it's easy to write the code that would run fast on one OS and very slow on the other.
Most developers treat OSX version as a checkbox on their "required features list" and only care whether the game works or not when porting. They do not want to spend time looking at the intricacies of OSX and just tell you that it's graphics driver's fault.
I develop games on Linux and OSX and later port to Windows before releasing (because that's where the players are), so I have to write specific code for Windows to make sure it runs faster. For example, my latest Steam game was really lagging and slow on Windows until I figured out the timer problem I wrote about above.
Other developers do it the other way around, and OSX performance isn't top priority.