Windows game developer about porting to and using OS X (opens in new tab)

This always happens to me with passwords. I have trouble remembering some passwords. Yet, when I'm in front of the page and I actually need to get in, either I lose some focus and let my unconsciousness do the work or I won't get it right.

When I used to play piano as a kid, this happened to me all the time.

Sit me in front of the piano and I'll mindlessly bang out the song I've been practicing. Make me think about it in the middle and I'll forget what comes next.

Furthermore SDL2 is absolutely fantastic and just works. You may say, you do not want to use it as it "just" abstracts away keyboard/mouse/controller input, window and GL context creation but these things are damn hard to get right.

An alternative is Cocos2d-x, but they manage memory using a single autorelease pool.

Before going with SDL2, I'd highly suggest evaluating it compared to GLFW.

I'm using both every day at the moment.

- I don't spend a lot of time setting up the IDE, so it's important the defaults are sensible. For instance, it might be possible to change this, but XCode's code completion seems to be less useful than VC2015. I really need it to be near immediate, and I also need it to check string that may appear in the middle of a function name instead of just the start. Especially since NS libraries have strange and long names for things. As I'm writing this, I just found out you can have tabs in XCode. Why isn't that a default?

- XCode crashes maybe once or twice a week for me. VC doesn't.

- Unspecific weird things happen in XCode way more than VC. For instance I was unable to see variable values in XCode for a while. Eats up my time looking it up. Hasn't happened to me on VC yet.

- XCode is highly integrated with the Apple environment. You can build stuff for the app store and send it right there.

- XCode has a less than complete Git integration. You need a bit more detail than what it gives you. I use SourceTree anyway, but it might matter for some people.

- Compile times are hard to compare, as I'm doing different things on the two environments. VC2015 is definitely a lot faster than a few years ago though.

I use both VS and Xcode daily. Once you get over the initial "gee this thing looks like iTunes" shock and get used to a few small annoyances, Xcode is quite ok to work with. Keyboard shortcuts and source file navigation are completely different to anything else though, once you get used to it, it works well though.

Where Xcode is better than Visual Studio for C/C++ dev (IMHO of course):

- C++ compiling and linking is easily 5x..10x faster out of the box than Visual Studio thanks to clang

- the static analyzer has a really nice 'arrow'-visualization of the steps that lead to the warning

- clang provides more useful error messages

- compiler warnings and errors are directly overlaid into the text editor view

- built-in support for clang address sanitizer (just a checkbox to tick)

- support for iOS development is really slick

- better out-of-the-box support for command line builds either through xcodebuild or the gcc-compatible toolchain

- Xcode comes with a lot of profiling and analysis tools where Visual Studio has only slowly caught up (but VS2015 seems to be mostly on par).

Where Xcode falls behind compared to VS:

- Xcode has that strange 'Scheme' feature for build configuration

- the debugger's variable inspection has usability issues

- working on source files with a couple thousand lines of code feels laggy

- before El Capitan, the whole UI felt slow on a Retina MBP, but I guess that's because of general optimizations in the OS

- it crashes or freezes about once or twice a week on me

- probably a number of smaller ignorances which I have learned to ignore

I usually don't touch any of the UI builder tools in both IDEs, only straight C and C++ stuff so I can't comment on the more platform-specific features.

[edit: formatting]

My personal experience:

Visual Studio feels a lot more "enterprise-y" than Xcode and offers a lot more advanced features and tools on pretty much all fronts, especially in the UI (e.g.: Xcode doesn't even have file tabs, but sth. I'd describe as big "whole-UI-tabs"). But...

Xcode has llvm. This compiler and it's tools (i.e. the analyzer, debugger, etc.) just make VS' compiler look like it's from the 90s. Really.

-> Have you ever heard of llvm's "address sanitizer"? Forget the days of endless debugging! This little helper has revolutionized my debugging productivity and solved so many little subtile bugs for me...

So in the end you'll loose a lot of nice UI gimmicks and additional tools, but the compiler suite makes up for that.

And even if you don't need those llvm features, you still get a unix environment, which makes working on many fronts a lot easier. E.g. I'm primarely working on different kinds of web servers: To test everything I can just install whatever I need... brew, curl, netcat, wrk, ... And it will just work. And let's not forget all those "standard" unix tools like find, xargs, grep, etc.!

I use both on a regular basis, VS for my job and XCode for hobby work.

I prefer VS because it performs better when editing and navigating the code base ( it is actually faster to run in it inside VirtualBox than XCode natively ).

Also VS has code navigation and editing features that XCode lacks. For instance if you want to do a find/replace in VS you can double click on a word do Ctrl+H and the word you selected populates the search box. You can then populate the replace box with what you have in the clipboard or just type in what you want. In XCode you need to copy the word to replace into the clipboard, do a Cmd+F, paste the word into the search box and then type in the replace box. This is much slower.

In VS you can setup bookmarks in your code with Ctrl+F2 and jump between bookmarks by pressing F2. This is great when you need to have present multiple parts of the code base to accomplish some task. I don't know how to do this in XCode.

In VS you have a stack of source code windows that you can easily move about via Ctrl+W+n where n is the stack depth. This is incredibly useful to navigate between multiple files. Again, I don't know how to this without using the mouse in XCode.

Then there are other issues with XCode mentioned by other comments like the incredibly confusing build settings and the instability of the IDE.

I often wonder if Apple actually uses it to develop their software.

I've been using XCode daily since version 3 and I still miss VS. XCode (IMO) is a festival of UX badness - can't change positions of navigator windows, can't change fonts/colors outside of source/console, the 'assistant' window (or whatever it's called this week) frequently opens up unexpected or unrelated files, refuses to stop trying to automatically balance square brackets, spews truncated errors and warnings over the top of code then shows a tiny version in a mouseover for about 3 seconds before hiding it, truncates said warnings in the issue navigator, tiny fonts almost everywhere, severe weirdness with variable inspection and no integrated 'watch' in the debugger - which likes to show disassembley even when you ask it not to.

Lack of refactoring support for Swift is currently baking my noodle, as is the lack of a supported plugin API (with which I could solve many of my own problems). Very crashy.

All that being said, it has a lot of good stuff. The analysis and profiling tools are great, there's a bunch of really powerful tools for games and 3D, view debugging is a thing now, the UI builder is super powerful (once you get used to it) and the unit/performance/UI testing tools are (IMO) pretty awesome. Lately integration with all things App Store (provisioning, entitlements, etc) has got a lot better and most of my pain points there have gone away.

It's hugely subjective though, some people would disagree with much of this. Like any IDE, you end up in a love/hate relationship. The main difference being that if you hate VS you can hit up the extensibility API and make your pain go away, whereas Apple don't really care if you hate them.*

*I'm aware of Alcatraz and it's neat, I'm just not quite sure I want to introduce unsupported hackery into my production environment.

Adding in a third option to the mix - JetBrains recently added a C++ editor to their catalogue called CLion[1]. While VS and XCode have quite a headstart over it, CLion is cross platform and comes with native support for CMake projects. JetBrains also make the (de-facto from my experience) Java IDE - IntelliJ which shares a core engine with CLion.

A bugbear of mine for XCode is the absence of C++ refactoring tools, which CLion certainly has.

[1]: https://www.jetbrains.com/clion/

I don't use VS but I use Xcode every day. Downsides: incredibly laggy, buggy, can crash a lot depending on the version. Upsides: actually pretty thoughtful in terms of UI and UX, at least insofar as a fully-fledged IDE can be. I could never wrap my head around VS's stupid toolbars. Debugging, when it works, is really nice; there's more interactivity and inline code interaction than I remember VS having. (VS probably has more power features in this arena, though.) The profiling tools are top-notch; you can even capture frames when debugging an iOS OpenGL app. Fuzzy search is a huge help — is VS still missing this feature? You can very easily access the docs for any property or method with an Alt-click, as well as the headers with a Cmd-click. Adding external code and projects, as well as hooking up all the dependencies, is pretty easy once you've done it a few times. So yeah, not great by any stretch, but pretty good when it works.

I can only speak for Xcode 5, but after I read an article similar to http://mattorb.com/xcode-behaviors-for-fun-and-profit/ that explained how to effectively use tabs and "behaviors", I am mostly a happy camper. I also replaced its clang/libclang.dylib with a more recent build, so I could have C++14 support.

I'm way more productive in Xcode. I've also used it more in the last years so that obviously influences my statement.

I find the UI in VS2013 very "unstable" - I constantly manage to drag stuff away and hide windows I need to use. I miss the .h/.cpp side by side view when I'm in VS.

It's very easy to setup a color scheme in Xcode that looks nice. I've used hours in VS to get something that is ok. And then it resets to the default about once a week randomly.

Debugging C++ template code actually works in Xcode. Running debug build of stl under win32 is extremely slow in my experience.

I almost never have crashes in Xcode, but I think this probably depends on your code base and project setup a lot.

LLVM compiler errors are much easier to understand. That said, VS have found bugs that LLVM don't see. So, compiling on both help keep code base in good state.

Our game code compiles in half the time on Xcode/LLVM compared to VS2013.

I use Xcode and visual studio daily.

Things I like about Xcode:

- the OpenGL debugger and profiler are top notch

- clang is a great compiler

Things I dislike:

- it's incredibly unstable. I've had it crash 8 times within an hour.

- I can't do a find-in-files without freezing the ide for 30 minutes. (Visual studio can handle the same code base in seconds)

- a lot of ui design decisions are "different" for seemingly no reason. Most devs can jump between vs/IntelliJ/eclipse easily, but almost every Xcode design decision is just weird. Like why do compile errors show up where my file navigator is supposed to be? Why are important tabs just shown with tiny incomprehensible flat icons? It's all arbitrary, but it seems like every ide has settled on conventions that Xcode breaks to no obvious advantage

Dunno much about VC but the Xcode editor compared to Jetbrains IDEs (IntelliJ) is horrible, ABSOLUTELY HORRIBLE. I'm just talking about the code editor (storyboard editor and other tools are fine).

I'm missing Jetbrains code completion so hard and all those useful shortcuts like CMD+E, CMD+W, CMD+ALT+V, CMD+ALT+M, SHIFT+F6, CMD+SHIFT+UP/DOWN, CTRL+N, CMD+1..9, CMD+F9, ALT+SHIFT+F9/F10.

Guess I have to buy an AppCode license.

For me it's just feels too heavy and laggy, though I cannot compare to VS.

But I do not do much iOS/OS X GUI development, so I am happy with the terminal/vim.

Just the title screen, not a complete port. Nor would 1FPS be probably considered "working" :)

He put the OS glue in place in 1 week and that sounds about right for this sort of effort, given some prior experience with writing portable code. The bulk of effort was spent earlier on abstracting principal code from the platform specifics, and sounds like he did all the right things there. Good stuff.

It's not working. It just rendered. Like the author said, it's mostly just moving the core c++ codebase in then futzing with xcode to get it to build. If you can use *nix you can use OSX.

I'm curious about his opinions on OSX after he's gotten the game to run with sound and above 1FPS.

Not really. One of the major parts of the OSX port is opengl support which he has been working on since at least March. http://www.shiningrocksoftware.com/2015-03-14-porting-opengl...

If you have written your game with a good api layer that shield you from platform specificity, I can't imagine why it would take that long to port... It's mostly SMOP

He had done most of the work on Windows beforehand (OpenGL, implementing his own portable shading language, UTF-8 etc).

> SSE intrinsics - my experience was that Microsoft's compiler was MUCH better at generating code from SSE/SSE2 intrinsics then clang

I don't know whether this is still the case – or something like tweaking the target CPUs would help – but assuming it is, did you report it to either the open-source Clang project or Apple? The developers have seemed to be quite responsive to reports like this.

Not just he has developed the game, but also made the art, sound and everything you see from the game, this guy has ultra high levels of productivity.

Does anyone know whether he did the graphics too? It's not world class art, but it looks real good, so I'd be very impressed if that was the same guy too.

Yeah I am also impressed, pretty much aspire to be that productive but have failed.

It's not a bad game, especially for its price, but remember that this is a town, not city building game. That means that there is a hard limit to the size of the town - any bigger, and the agents (citizens) will literally starve to death en route to their next destination because it is too far from their home.

If you want to expand further, all you're doing is making exact, self-contained replicas of the same town in other places on the map. There's not much variety because each town needs the same resources, and each map has those same resources.

Like many games of this genre, the game has a reverse difficulty curve. This is especially true here because of the focus on survival. That means that the first few winters will be spent micromanaging every single resource to ensure everyone has sufficient materials, but after that initial period is over, it's impossible to fail because the town basically runs itself.

Indeed, for me it's only recent city builder that captures the feeling of the original Settlers game(s). The feeling where I just want to see what my little city is up to, see the people scurrying about their little lives.

The game is relatively deep, and has tons of room for clever tactics. Also, it was developed by a single person, which is pretty impressive for a game like this.

I played it a couple of years ago and enjoyed it but eventually got tired of it. Has there been a lot of new features since?

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.

edit:

found some reference from the curious https://developer.apple.com/library/mac/documentation/Graphi...

"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

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.

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.

drivers.

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.

He's talking about two-phase name lookup, which VS doesn't implement (yet?), but clang does (as it should, striving to be a standard-compliant compiler). Here's a nice article about it: http://blog.llvm.org/2009/12/dreaded-two-phase-name-lookup.h...

TL;DR: If a type, variable... depends on template parameters, code using it is checked when the template is instantiated with concrete template arguments. Otherwise it is checked when the template is defined.

I don't quite understand why you call templates near-useless, if two-phase name lookup didn't exist?

Microsoft's C++ compiler treats templates more like macros: http://blogs.msdn.com/b/vcblog/archive/2015/09/25/rejuvenati...

It is a nice starting point for queries about files on the system as a whole rather than in a particular folder. i.e. Show me all of the PDF files I've used recently. Or find a file with name x but I have no idea where it is. `find / -name foo` vs `find . -name foo`

Yeah, I guess the author meant more like "very similar to Unixes (unices?) I've used before", which quite possibly means 'various Linux distros'. Aside from official certification, OSX is still sufficiently different to make this mistake forgivable, and not just in terms of the UI. The filesystem organisation is unusual, to say the least.

What does this atually mean (when compared to Linux, which is a UNIX clone)? That they have paid someone for a certificate? Is it more than that?

That sounds like a lot of work.

The first thing the author talks about is their unfamiliarity with the Mac environment, and the game wasn't made for OS X in the first instance, which would suggest they did buy a Mac purely for an OS X port.

Perforce client (P4V). Consider yourself lucky you don't recognize it.

Working through the Ogre issues on OS X is like a rite of passage, I thought?

I tried multiple times to contribute OS X fixes to the Ogre code base. They're not hard things --

1. Use SDL not OIS.

2. The symlinking is broken.

3. Link the frameworks properly.

There was one more thing, I think. Just minor issues that probably have crept into the codebase because no one is able to contribute the fixes.

It's Ogre. It's not OS X.