Monthly Archives: September 2015

OnDisable & OnApplicationQuit

In my latest project, I ran into an issue with OnDisable being fired when I stop the project running in the editor.  I’d get a host of errors about destroying transforms and not gameobjects.  Now I didn’t do any of that, but I did have an OnDisable routine that moved all the children of the disabled gameobject into a pool for reuse at a later point.

Turns out that all GameObject’s are disabled when you exit run mode in the editor, and they all have OnDisabled called one last time.  Not sure why this caused the error I was seeing and not even sure it was a real problem, but it was ugly seeing all those red exception errors fill my console window.

OnApplicationQuit to the rescue! After some googling I found that others have been having the same problem and it is a pretty simple solution.  Just add a private bool to your script and the Monobehavior method ‘void OnApplicationQuit()’ which just sets this bool to true.  Now in your OnDisabled method you can check to see if that bool is true & do nothing if it is!

OnApplicationQuit is called before the OnDisabled methods, so that flag gets set and your other methods just return. Simple & Clean!

private bool applicationIsQuitting;
void OnApplicationQuit()
{
	applicationIsQuitting = true;
}
void OnDisabled()
{
	if (applicationIsQuitting)
		return;
	Debug.Log("OnDisabled");
}

Dangers of copying files (Google Play Services Lib)

Had an issue today where after upgrading to the latest version of the Google Play Services the build process threw up a ton of  cryptic error messages like “Temp/StagingArea/android-libraries/google-play-services_lib/res/values/common_colors.xml:4: error: Resource entry common_signin_btn_dark_text_default is already defined.”

Turns out that while upgrading the Google Play Services folder, instead of replacing the old folder completely, the new folder was merged with the old one.  This left the old ‘colors.xml’ file which then conflicted with the new ‘common_colors.xml’ file.  Deleting the old folder and then copying in the new folder fixed it!

Obviously we figured it out, but it did manage to waste 30 minutes.  Hopefully, by writing this entry, I’ll remember the next time this happens, and maybe even help some other unfortunate soul from wasting their own 30 minutes.

 

c# Jagged Arrays

While working on a new game app, I needed to initialized a multi-dimensional array upon declaration.  I initially used a two dimensional array declared as such:

readonly TrackType[,] validTypes = {{TrackType.none},
{TrackType.one, TrackType.two, TrackType.three}};

This worked fine and the array was declared and initialized correctly.  I then decided I wanted to extract a row from this array and work on it, rather than always using two indexes as I processed the entries.  However, with a multi-dimensional array it’s not possible to do this implicitly.  The solution was to create a Jagged Array.  Each element is accessed in a similar way, but it allows you to grab a pointer to a row of the array, which is what I wanted.

The syntax for defining and initializing it during declaration is quite different however, and this is what I ended up with:

readonly TrackType[][] validTypes = new TrackType[][] {
new TrackType[] {TrackType.none},
new TrackType[] {TrackType.one, TrackType.two, TrackType.three}};

More typing, but it gets the job done.

Re-sizing iOS screenshots

While not a perfect solution, grabbing screens at iPhone 6 Plus resolution and then down-scaling for iPhone 6 & iPhone 5 screen sizes is a lot quicker.

To do this I use the mogrify command from the amazingly useful ImageMagick toolset.  However, as the aspect ratio for the iPhone 5 is slightly different to the iPhone 6 Plus, you need to add a ! to the end of the resize options as follows:

mogrify -resize 1136×640! *.png

This will resize the images exactly to the iPhone 5 landscape size, ignoring any aspect ratio, otherwise you get 1136×639, which just won’t do.

For iPhone 6 landscape size I use:

mogrify -resize 1334×750! *.png

Note that mogrify will overwrite the source file, so I make a directory for each size I want and copy the iPhone 6Plus sized files in.

Just as a FYI, the iPhone 6Plus sized images are 2208×1242 (landscaped)

Making iOS Preview Videos (landscaped)

I had a post on this earlier, and I thought I had it figured out.  However, my latest silly App is landscape, and the same tricks don’t seem to work to force a nice 1920×1080 video.

After a little google work, I found this handy answer on SO:

http://stackoverflow.com/questions/25797990/capture-ios-simulator-video-for-app-preview

Using FFPMEG, it’s possible to scale up the video.  It seems you need to oversize it and then crop it.  The following commands are from the SO answer:

ffmpeg -i video.mov -filter:v scale=1084:1924 -c:a copy video_1084.mov
ffmpeg -i video_1084.mov -filter:v "crop=1080:1920:0:0" -c:a copy video_1080.mov

I ended up using slightly different commands, I was coming from a iPhone 6 landscaped video, so I needed to scale my output to 1928×1084 and then crop it to 1920×1080.  I also used .mp4 as the extension, as this is what iMovie exported them as.

Just as a side note, I don’t like making a fake iPad video, so I just record the gameplay with Quicktime and knock out a specific iPad version.  It’s limited to 30 seconds, so it’s not like its a ton of extra work.

Hope this helps someone else out there.