> Apparently my vi command muscle memory hasn't faded.<p>Back in the day I did most of my dev work on Solaris. I then spent 4 years as CTO as a startup that was pretty much only Windows.<p>When I subsequently went back to working at a unix shop I was initially struggling with vi as I tried to read some of the C++ code. I couldn't remember commands, was having to refer to the man pages every few mins. It was torture.<p>A couple of days in, I was writing up some notes in vi when someone walked past my desk and started chatting. When we finished talking I looked down at the monitor and I'd written more than I had when I was concentrating, nicely formatted, the works. Turns out "my hands" had remembered a load of what I thought I had forgotten.<p>For the next few days I had to keep finding ways to distract myself so that I could work efficiently. Eventually it all came to the foreground but it was the most bizarre experience while it was happening.
<i>I’m not using SDL or any other library to hide those platform differences.</i><p>Once start working on Linux port he'll regret about that. Every developer that start with own platform-specific code end up using SDL2 anyway. Don't do that mistake.
<i>Xcode isn’t too bad.</i><p>I wish the author told me more about it than just this. Can somebody comment on how it compares to recent VS editions these days? About 5 years ago I also looked into using OSX as main OS. As I've always been using non-commandline graphic text editors and IDEs for most coding that made XCode the go-to environment but I just couldn't deal with it even though I tried. I don't remember all details but in general it just felt inferior to VS on like all fronts, with no advantages of any kind (for C++). Again, IIRC, but it did annoying things like opening the same document in multiple windows, one for editing and one for debugging or so? Anyway, what's the state today?
I recently went through a very similar process porting my screensaver [1] from Windows to Mac without using a library like SDL. Here are some additional difficulties I encountered during this process:<p>OpenGL on multiple monitors - this was much more difficult to do on MacOS. I had to create a separate window for each monitor, create a rendering context for each window, make sure my graphics code was issuing the drawing commands to the proper context, then have each context queue/batch "pending" rendering commands and issue them all at once at the end of a frame on a by-context basis. Whereas on Windows you can pretty much create a window that spans multiple monitors and draw to it with a single rendering context.<p>Input - I used DirectInput on Windows and wrangled a suitable implementation using HID Utilities on Mac, which was not easy given my lack of previous USB programming experience. A major annoyance was the lack of a device "guid" that you can get via HID Utilities to uniquely identify an input device - I had to manually contruct one using (among other things) the USB port # that the device was plugged into. Not ideal.<p>SSE intrinsics - my experience was that Microsoft's compiler was MUCH better at generating code from SSE/SSE2 intrinsics then clang - my Windows SSE-optimized functions ran significantly faster then my "pure" C++ implementations, where as the Mac versions ran a bit slower! My next thought was to take this particular bit of code gen responsibility away from clang and write inline assembly versions of these functions, but I took a look at the clang inline assembly syntax and decided to skip that effort. (I did write an inline assembly version using the MS syntax and squeezed an additional 15% perf over the MS intrinsic code.)<p>Prtty much everything else (porting audio from DirectSound to OpenAL, issuing HTTP requests, kludging up a GUI etc) was pretty straight forward/did not have any nasty surprises.<p>[1] <a href="http://www.ubernes.com/nesscreensaver.html" rel="nofollow">http://www.ubernes.com/nesscreensaver.html</a>
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?<p>What can make such considerable difference?
The comment about C++ templates is baffling and I wish the author would elaborate. The behavior he describes that clang doesn't support is... how templates are specified to work. They're near-useless without that property.<p><i>Most of these had to do with templates that expected the code inside them not to be compiled until they were instantiated. The Microsoft compiler has that behavior, while clang does not.</i>
I went the other way: last year I converted an OS X app to Windows. I hadn't used Windows for six years, and had forgotten most things.<p>It took two weeks to get the code compiling and running. That turned out to be the easy part. Getting the application performing well, feeling "native", and getting the bug count down took another six months.<p>I love Banished and I'd like to see a completed OS X port. But I'm not expecting this to be done, like, tomorrow!
I'd be more interested in his experience about porting to Linux (since supposedly he is working on it as well).<p>OpenGL on OS X is still behind the times, and so far it's not even clear if Apple will add Vulkan support when it will come out.
> couldn’t figure out how an ‘All Files’ category was useful when browsing finder windows<p>To this day I still don't see or find how it is useful.
The man's commitment to his game, considering that he works alone is incredible. Without using terms like "10xer" and "rockstar", he's got an incredible level of perseverance and dedication, considering that he already launched the game and at this point is working on features that are considered by many boring and a grind, all to make a polished finished product. The fact that he documented pretty much everything in his blog is great if you need motivation or are just curious about how to make a game from zero.
I do it this way, but it's based on my particular skill set:<p>First make the iOS version. Then, port it over to Java. Then, port it over to C# or maybe ActionScript3/Flash.<p>This way, I can recursively update previous versions as the 'best solution' to interesting problems become most clear by the end of the 2nd or 3rd port. This gives the Objective-C/iOS version the attention it needs, and I can use the rapid application development features for each new port.
We develop our game on Mac OS X and port to Win32 and Linux. Using CMake, SDL2 and C++11 there is very little code that actually needs to be rewritten. The windows build process is just a python script that pulls, cmake configure, compiles and zips the latest build.<p>The code that is completely different on the platforms is stuff like HTTPS requests, open file dialog, create/delete folders.
<i>The fact that it’s running at 1 FPS is a little disheartening – I know the GPU is fast enough. I’ve got a Windows machine with an Intel Iris Pro 5000 that runs Banished just fine, which is the same graphics hardware in my MacBook Pro. I’ve got my suspicions as to whats going on but I have a bunch of testing ahead of me to make sure I fix the issue properly.</i><p>Did the author buy a MacBook Pro just for this purpose? I'd assume this is his personal laptop, but his "Using a Mac" section sounds like he's not a Mac user even in his free time.
Well I sold my macbook pro because I wasn't able to build my ogre project properly. For years. Also there was some OIS (not iOS, OIS) input issue. It comes from apple force feeding Cocoa into opengl apps, or something like that, which can only be remedied by using some SDL hack.<p>Anyway, I don't really care anymore, I bought a thinkpad instead. Cocoa is just something I just can't even.<p>My experience has been pretty different. I'm not a professional developer though.