January 6, 2012 Leave a comment
Yesterday was spent in Mac land, which is an unfamiliar and glossy place. Fortunately I found a nice set of blog posts to guide me on my quest. If you want a tutorial, go read those posts. If you want to see what happens when someone tries to go from zero to Mac port, read on.
Here’s a recap of my experience. This is more for my own benefit rather than a tutorial for others, though it may give you an idea of what’s involved.
- Download XCode 4.2 for Lion, MonoDevelop and the MonoFramework.
- Watch some videos on how Macs work (seriously) and set up a user account for myself since my Mac is borrowed.
- Try to install xcode. Discovered that my version of OSX is Snow Leopard, not Lion and thus I have downloaded the wrong version. But the version for Snow Leopard is only available for paid Mac or iOS developers! I need to either upgrade to Lion or purchase a Mac/iOS developer membership in order to get xcode for Snow Leopard.
- Decide I’ll need it eventually anyway and purchase a Mac Developer account for $99 + tax.
- Purchasing doesn’t grant access immediately, but I receive my activation within about an hour.
- Download XCode 4.2 for Snow Leopard this time!
- Download and set up Git
- Fork and clone MonoGame. It’s still under very active development, so I choose to fork rather than just download a copy. Maybe I’ll be able to contribute!
- Install Mono itself (which is the analog to the .NET framework SDK in my head)
- Install MonoDevelop (IDE analog to Visual Studio)
- Don’t install MonoMac Add-in for MonoDevelop, because it appears to already be installed!
- Download MonoMac samples for playing with later from Github
- Download MonoGame samples for playing with later from Github
- Build some of the MonoMac samples and play with them. No problems there! That’s .NET on a Mac then. Easy peasy!
- Build some of the MonoGame samples and play with them. Some strange changes are needed in order to make them work, but nothing too absurd. XNA on a Mac! Easyish peasyish!
- Running an already ported sample is nice, but it’s time to try my hand at porting something “from scratch”. My target is the SpriteSheetSample, which is a relatively small and simple set of projects for a Content Processor, a runtime class and a sample game putting it all together. Should be easy! Roughly:
- Create a new solution file
- Add in the existing MonoGame framework and Lidgren projects, ensuring the former properly references the latter.
- Create new MonoMac projects for the SpriteSheet (runtime library) and SpriteSheetSample (sample game) projects. Make sure they reference MonoGame.
- Add some compiler defines like MONO and MAC so I can conditionally compile everything and only keep one copy of the files
- Set up the new Program.cs to launch the game the Mac way
- Copy over the already-built .xnb files from my Windows machine (I don’t keep these in source control)
This is a bigger hassle than it sounds. I need an automated solution (“Create Copy for Mac”).
- Build and run! Doesn’t work. Or even crash.
Eventually discover the “Application Output” window and see “Unable to load nib file MainMenu”. Turns out I’ve missed one of the steps in the tutorial and didn’t add an empty interface called MainMenu. This is one of those strange things I was talking about earlier.
- I use Mercurial for my projects, so update .hgignore to include:
This is another thing to automate.
- Compiles! Yay! Runtime error! Boo! It’s an error drawing the spritesheet. Looks like the SpriteSheet object is non-null, but fields are null. WTF? Clearly something went wrong during the content load.
- Crisis! The debugger does not work! Stepping through code highlights nonsensical lines like comments and destructors when the callstack clearly shows otherwise. This is not workable at all. After restarting and googling the debugger problem, I come up empty.
- I decide to check if I can solve the content load problem itself. After some more googling, I find some misleading info about a lack of ExternalReference support in the ContentManager of MonoGame. This eventually proves to be a red herring and is a lesson in making sure your tools work so that you can properly identify the true problem.
- Eventually, I manually clean all the projects in my solution (the “Clean All” command was/is failing) and the debugger resumes working. Victory!
- From here, it’s a straightforward case of stepping through the content load methods. I discover that non-public fields are not being populated even when marked with the [ContentSerializer] attribute. Easy fix!
- With everything in place and working, I push my changes to my repository.
- Then I pull them down to Windows machine and check that everything still works.
- Everything still works. Done!
A little bumpy, a bunch of rough edges, but I ported something written in XNA to the Mac. What’s more, I kept it in one set of files, so it’s essentially the same as working with a copy for Xbox 360. There are definitely some opportunities to streamline the workflow though.
So the next steps are:
- Port another small library/sample to get the hang of what needs to be added/changed/reference/etc in a Mac copy of a project.
- Devise some way of automating this part of the process. Maybe.
- Come up with a good solution for keeping content in sync for Mac builds. I’m find with building everything on my Windows machine, but I don’t want built content in source control. It would work if I was using something like Perforce, but Hg (or Git for that matter) just isn’t suited to the task. Perhaps a simple rsync script. Moving forward, maybe a Dropbox solution.
- Find a desktop layout that works. As in, my physical desktop. Working on Macbook is uncomfortable, especially when it’s in front of my PC’s monitors.
For giggles, I’m going to try to keep a running total of time and money invested in this little adventure.
Running total: 2 days, $112.87