Not dead yet, New life, Same direction

It’s been almost four months since the last post. The arrival of a bundle of joy I thought may give me more evening time actually means I’m retiring at a much earlier hour than ever before. That combined with my other halves maternity leave means I don’t have much time alone. All this will change once she’s back at work.

I was quickly checking my email this morning. Twitter, which I don’t really use, had spammed me with an article from a blog I didn’t previously follow. The article is about writing a book. But I believe the principles line up with my own and apply to other project types too. In particular I independently came up with the method of keeping cheap notebooks around for brainstorming ideas. Thinking things through in this manner helps grow or eliminate them as things to spend real time on.

Expanding on the article, I also use mechanical pencils for my notes as they are precise and useful when revising doodles and I store notes on my phone when ideas strike when I’m out and about.

The article in question :

In my head I have been working through ideas and planning for my next project. I’ve decided to make an app using Xamarin Forms, but will also be doing MonoGame experiments to keep a hand in there.

Slaying the Summer Slump

So, the dreaded summer slump hit. I’ve been keenly aware that I have not posted on this blog for a couple months. I do have the luxury of a dedicated main home development space (Man Cave) but it isn’t used much at this time of year. This quiet period happens annually. There are also other things happening at home which will compound this issue further in the future. To combat this I picked up a convertible Windows tablet and have Visual Studio & Monogame set up on it. I can now move around the home, and tinker/research/blog during the fragments of time I do get.

Adding pinch zoom to the experiment turned out tricky. So for now that branch of investigation will close.  I’ve not quite decided what to do next, so deciding is the first task.

Experiment update

Observation is a passive science, experimentation an active science – Claude Bernard (1813-1878, French scientist)

I started the Recursive Tree experiment thinking I’d be on a straight-ish course through a set of milestones but have learned something unexpected. Once it was on a touch device I instinctively expected it to be tactile. This discovery has reinforced my previous hunch that regular use of the target platform when doing cross-platform development is an absolute must.

Because of this, instead of the original plan for the next part of the experiment, I’m doing Pinch Zoom first. Following the development model I’m hoping to use throughout I’ve implemented as much of the heavy lifting parts of code within the Windows Desktop build first. I started adding zoom to the mouse-wheel and once ready will add the gesture based manipulation of those same parameters to the iOS build.

Here are some screenshots of it in action

A zoom of the lower right-hand side branch.

A deeper zoom of the lower right-hand side branch.

Bonus: A zoom of the lower right-hand side branch with an extra tenth layer of iteration added.

Experiment Progress

I’ve done the first part of recreating the scene from the Demo I linked previously.

Here’s a screenshot of the original scene taken from the entry for the demo on

A screenshot of it running on my iPhone. Due to the thin lines & high-resolution it looks better when you click it!.

Finally, a rough side by side edit, with iOS on the left, and a scaled up Amiga screenshot on the right.

OK it’s not a perfect 1 to 1 copy, but it’s close. It would take some trial and error with the scaling and angle parameters. Also, as I’m pre-populating the list of vertices it doesn’t animate like the original. I could achieve that by looping and drawing only parts of the pre-populated list.

One of the things to investigate is 2D libraries to draw lines of varying thickness to replace my use of DrawUserPrimitives which doesn’t support line thickness.

This is the point at which I’ll diverge from the original (including removing the blue lines..).

I’ve also hit a few things with Free Provisioning which are of note.

Free Provisioning on an iOS device runs out after 1 week. The impact of this is as follows:

  • Any existing copied app won’t run after that time. On some devices it shows the MonoGame startup screen (or whatever you’ve replaced it with) then just exits. On some devices you get an actual error “My App” Is No Longer Available.
  • If you (make the mistake of) deleting all previous apps before running a new one you have to re-trust the Publisher in Device Management again to run new apps on it. Running/Debugging will hang until you’ve done this. The symptom is Xamarin Studio will copy to the device then fail to connect debugger. If you run the copied app manually the error shown leads you to this.

Window Centring Fix for MonoGame v3.6

I was debugging a problem I’ve had for a while. Under Windows the running process wouldn’t actually stop once I’d hit ESC even though the Window closed.. After searching I found that it should be fixed, but I was still using MonoGame v3.5.1. I updated to v3.6 which solved it. After upgrading I discovered that the program window now doesn’t auto-centre. They’ve already fixed it for their next build.


Here’s the quick workaround I knocked up to see me through until that comes out.

protected override void Initialize()
    // Temporary hack to reposition window as auto-centre/center is broken in MonoGame 3.6
    Point WindowSize = new Point(this.Window.ClientBounds.Size.X / 2, this.Window.ClientBounds.Size.Y / 2);
    Point ScreenSize = new Point(graphics.GraphicsDevice.DisplayMode.Width / 2, graphics.GraphicsDevice.DisplayMode.Height / 2);
    this.Window.Position = new Point(ScreenSize.X - WindowSize.X, ScreenSize.Y - WindowSize.Y);

First Project Outline

The first project is a series of experiments based around a simple graphical program. This will allow me to try out some things like managing different screen sizes and how to share the code between projects for each platform.

I’ll be recreating one of the scenes from this Demo (one of my favourites).

I already have a simple class I wrote previously that draws lines in MonoGame using vertex arrays. Once I’ve got the recreation of the original scene up and running on multiple platforms I’ll be trying out 2D library alternatives to replace my rudimentary line code and will add some modern (shader based) twists to the original scene.

Magic Breakfast

One of the times I get to tinker with projects is first thing in the morning. Today I set out to see if I could bypass the Exception being thrown on the iPod Touch from yesterday. When I start Xamarin Studio it offers me updates, I figure why not, as I read E-mails, sip coffee and eat breakfast. Once the updates are done I plug the offending device in and prepare to set forth debugging. It works. Magic. I’m glad I’d applied the updates before committing the cardinal sin of reaching out for help before being fully up to date.

The one remaining issue is, why is editing the file in Xamarin Studio making the remote file hidden? Is this issue limited to Xamarin Studio or is it an OS X thing? I discover that it only affects Game1.cs and one of the project files, not Main.cs or anything else, and appears to be limited to Xamarin Studio as Xcode and Visual Studio don’t have the issue. I’ll try and live with it for now to see what the impact is. After all, all my code won’t be in Game1.cs.

Keeping It Real (Hardware)

Following on from the previous blog entry the next step is seeing the code run on real hardware. To do this the device must be Provisioned.

Fortunately I found an article about Free Provisioning on the Xamarin site.

I already had Xcode installed which saved some time. After following through the article I got to the point of creating the required project in Xcode and was seeing the following error.

There are no devices registered in your account on the developer website. Plug in and select a device to have Xcode register it.

After some googling I found the trick was to stay on the screen with the error showing and use the drop-down in the top left to select my device (instead of the default Simulator). After clicking play and allowing the certificate on my device (as prompted) the blank Xcode project runs on my real device.

It’s worth noting, my development target is a 5th Gen iPhone Touch that was given to me as it doesn’t hold charge. It’s 32-bit, and the maximum iOS version it will run is 9.3.5. I changed another setting to allow that in Xcode. To make the architecture 32-bit in Xamarin Studio isn’t quite as obvious, but another article on the Xamarin site Compiling for Different Devices showed me what to set. and has a handy table listing all architecture targets. In the Xamarin Studio project options this relates to Project Options -> iOS Build -> Supported architectures.

Now I need to run my MonoGame project on a device via Xamarin Studio. After a bit of poking around and right-clicking the project (not solution) I find the place to select the Signing Identity, which now shows my Apple ID.  When selected the Provisioning Profile doesn’t change as expected. Unsurprisingly it doesn’t work when trying to run the project. The error is /Library/Frameworks/Mono.framework/External/xbuild/Xamarin/iOS/Xamarin.iOS.Common.targets: Error: No installed provisioning profiles match the installed iOS signing identities. I found a post about the error, one reply suggested that the Apple ID needs to be added in Apple Developer Accounts which can be found in Publishing under Preferences. Now, I don’t have a developer account yet (that’s what Free Provisioning is all about) but as it also uses an Apple ID I thought I’d give it a shot. Adding one requires installing something called fastlane, which I’ve never heard of, and isn’t installed. I follow the link, and go through the article. After doing this, and repeating the process with fastlane now installed I’m able to add my Apple ID to the list. This doesn’t fix anything immediately, and restarting Xamarin Studio doesn’t help either. Revisiting the forum post again I find another nugget of information (by poster MikaY). It was something mentioned in an information bubble next to the unpolulated Provisioning Profile which didn’t make sense until now. You have to make the “Bundle Identifier” in the Info.plist, which I find resides in the Xamarin Studio project match the one in the Xcode project.

This gets me past the error I was having straight into another one.

/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/iOS/Xamarin.iOS.Common.targets: Error: Failed to codesign ‘bin/iPhone/Debug/device-builds/ipod5.1-9.3.5/’: libc++abi.dylib: terminating with uncaught exception of type Security::UnixError: UNIX error exception: 13

I Google the error, and find this post which basically says “You’re building from a share”…

So I copy the project to the Mac and build it from there.

It works!

Then it throws an exception (Microsoft.Xna.Framework.Audio.NoAudioHardwareException). I try it on my iPad and on my iPhone. All fine. Phew!

So my initial code sharing solution isn’t working, and I had also previously hit a problem with it making Game1.cs and another project file hidden. I have a plan.. Keep the project on the Mac, but link the project to the Game1.cs on the Windows share. Following yesterdays method, I press stop, change the colour, press play, and that works too. I do discover that the hidden file issue still exists, and is caused by every edit of the file.

Todays summary:

  • I’ve created a Free Provisioning profile in Xcode.
  • I’ve been able to use this with all my devices from Xcode.
  • I’ve got Xamarin Studio using the Free Provisioning profile, but the iPod Touch is throwing an exception in MonoGame.

So a mostly succesful day, slightly soured by the fact that the one actual permanent device I’ve got for development is the only device of the three that has an issue.

Less Talking, More Doing!

So, the blog is up! After some faffing with hosting I’ve finally got it live and can edit away from a computer  via my phone and/or iPad. I put them to good use making a start on an Online Resources page. This is intended to be my curated jump off point for finding information and keeping up to date with the MonoGame community. If I’m working on things and need information I’ll go there first, if that fails, and I find the information somewhere else I’ll feed that back into the page.

Now this blog is up, I suppose I had better actually do something now I have a place to write about it!

First order of business is getting my development environments working. I already have Visual Studio 2015 (Community Edition) and MonoGame for Visual Studio installed. But I now have a Mac and want to share code to it, and run the output on the iOS simulator and an actual iOS device.

So just How do I get from only developing locally on Windows 10 machine, to having it also buildable on the Mac? It’s worth pointing out, I’m totally not fussed about performance at this point. I just want to see it work on the target platform.

So, off I head to the MonoGame download page, and follow (off-site) link to the Xamarin site and it offers me Visual Studio for Mac (Preview) which takes about 30 mins to download and install. Link it to the same Microsoft account as the one I use on my Windows 10 PC, then close it, eject the installer and install MonoGame for Mac.

While it was installing I made sure I could access my shared folders from the Mac so I would be ready for (what I thought was) the next step.

So, I look in VS on the Mac, and try to start a new project. I expected it to have added like the Windows version – I can’t see anything related to MonoGame. I read up, backtrack, and realise, perhaps I should have installed Xamarin Studio after all, noticing that the Xamarin Studio download page is what mis-directed me to VS previously. I find this page on the Xamarin site under as part of the article Introduction to Game Development with MonoGame. So I download Xamarin Studio,and set it up which it doesn’t take more than another couple minutes. Figuring the MonoGame for Mac installer needs to be run last to add itself I run that again too for good measure.

The page I found was mostly accurate. The menus aren’t quite called what the article states, but it gets me there.  Proper steps are to click Xamarin Studio Community, then Add-ins.. then select the Gallery tab, then expand Game Development and hurrah, there’s the MonoGame Addin. I click Install… and let it do its thing.

(I get a couple of warnings which I screen grab with Skitch in case they’re actually important later)

Now when I create a new project there is a MonoGame section, and various platforms available.

I create an an iPhone/iPad project in the network folder I got ready earlier. I click the play (Run) button, and up pops a Simulator (which take a while as it’s the first time it’s been used). Eventually I see a MonoGame logo, and the familiar CornflowerBlue screen. Hurrah!

I click stop, change CornflowerBlue to DarkOliveGreen, click build, press play again and the iOS Simulator reopens the app with a CornflowerBlue again.. Oh!? I reset the Simulator, and make sure the app built. Still CornflowerBlue! I delete the app from the simulator, nothing changes. Something happens and the Simulator stops working completely. After exiting everything and reopening it I run the project, and behold, the DarkOliveGreen background I was after! Seems fine now. How do I apply changes with minimal clicks? I change the colour to WhiteSmoke, save the file, press the play button.. and it works. Do have I have to save? Stop -> Change -> Play -> Awesome. That first time was just a glitch.

So another idea. I close the open file in Xamarin Studio and am going to edit it on the Windows machine with notepad++, but I hit something unexpected. I can’t find the Game1.cs I’ve been editing. Sure enough, I can close/reopen the project on the Mac and Main.cs is there, but Game1.cs is not to be found outside the IDE. Turns out, for some reason Game1.cs has the hidden file attribute set. I discover something sets this every time you build the project.  Will have to bear this in mind when using Source Control or it could trip me up!

So, back to the test. If I save the file on the Windows machine and click play in Xamarin does it work? Yes.

So today:

  • Installed Xamarin Studio Community and MonoGame for Mac
  • Saw a default project running in the Simulator and could change the background colour locally and remotely.
  • Made the resources page I’d been drafting live and did my first proper blog post.

Next time the next goals are:

  • See the code running on an actual iOS device. (will need to follow this guide)
  • Work out how to properly link other source code into the project and not have too much of a mess on my hands!

This may seem overkill, and I do want to primarily develop on the Windows machine. I’ve used Visual Studio almost daily all the way back to 1993 when I was first learning C/C++ in its DOS based predecessor Microsoft Programmers Workbench, so I’m obviously most comfortable using it. I see stories of people porting from Windows to iOS easily, that’s fine! But, using something in a handheld touch environment after it’s been written and developed solely on a desktop platform with a mouse might not translate properly, it may not perform as well on the target hardware either, or the take full account of the screen dimensions.

To achieve this I must regularly run and use builds on real iOS hardware from day one. Of course, it will help show off what I’m doing better too.