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.

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.