The Great Porting Adventure: Day 3 Recap
January 7, 2012 2 Comments
The way I was numbering these posts felt a bit weird, since the “Day 3” post was a recap of Day 2 plus my plan for that day. I’ll use this post to get back on track, and also because I probably won’t be doing any work today so calling it Day 4 would just be silly.
So my plan was to come up with an automated way of creating and setting up the MonoMac copies of solutions and projects, but given that I didn’t really know what was happening, I figured it would be prudent to try porting over a few more projects manually. Looking into the .sln and .csproj format, I decided it might just be faster to do it all manually this time around. I’d certainly like to take a stab at making a tool to do this at some point in the future though.
- Started porting over my “DebugUtil” library, which I figured was pretty straightforward and self-contained. I quickly realized that it relied on my “Core” library, which in turn relied on EasyStorage. So much for minimizing dependencies.
- Started porting over EasyStorage. To my surprise, this was relatively painless. There was a bit of a discrepancy in the implementation of IUpdateable and IDrawable in MonoGame (its eventhandlers were just EventHandler, not EventHandler<EventArgs>) but that was simple enough to fix. Not sure if that was the right way to fix it, but it compiled and the sample ran fine nonetheless. There also seems to be a difference in the way .resx strings are handled, but I just ignored all of that and kept only English support for the time being. None of my games are localized anyway, so I’ll fight that battle another day.
- Then it was time to tackle some of my own libraries, including my debug utilities, my “core” library (with things like input, audio and storage) and my “tweaker menu” lib, for messing with tagged values at runtime. Audio support with XACT is kinda spotty/missing with MonoGame, so I just compiled out audio for now. That was a fight I knew I’d be making going into this, so I plan on dealing with it after the rest of the game is working.
- Next came TiledLib. This should have been straightforward, but the support for ExternalReference in the ContentReader implementation in MonoGame was a bit broken. Specifically, the path it pieced together for external assets was incorrect. I played around with it a bit and got it to construct the proper path.
- With all my dependencies now converted, and some of them tested, it was time to move on to the main event and start porting DLC Quest.
- Only a few compilation errors off the bat, including one for a missing GameTime constructor. Easy enough to implement myself, but a strange omission.
- I then came to realize how often I use “#if WINDOWS” in my code. A whole lot of “|| MAC” was added.
- I compiled out Audio, my keybind input hooks and my whole “draw from a different thread while loading content on the main thread” just to simplify things. I’ll tackle these soon, but for now audio has some missing XACT support, my input hooks rely on Windows functionality, and creating a SpriteBatch on a different thread seems to cause an OpenGL shader crash.
- Et voila!
But wait! Why did I choose a screenshot of the intro screen and not gameplay? Well, there’s still a lot of work to be done. Something in my main game’s spritebatch calls, be it the SpriteSortMode.Deferred or the use of a custom BasicEffect, causes a crash in MonoGame. I haven’t looked into it enough yet to say what the cause is.
Still, mighty fine progress for two days worth of work in MonoGame (plus one day for investigating porting options)! Nothing more for today though – time to go play some games with friends.
Running total: 3 days, $112.87