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 demozoo.org.

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);
 
    base.Initialize();
}

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/CPTest.app/libxamarin-debug.dylib’: 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.