Construct 2 Release r225

New this build: audio scheduling, more WKWebView improvements, a new multiple colored shadow-casting lights example based on this tutorial, rewritten and updated support for IAP for Cordova on iOS, and some bug fixes. Also note since r224 there were three releases of NW.js for v0.13.0-rc2, rc3 and rc4 - get them at scirra.com/nwjs as usual. NW.js v0.13.0 just recently made its stable release at last, so NW.js support should be pretty robust now, and is being updated regularly with every Chrome update too now, so things are looking good for NW.js.

Audio scheduling

Events normally run 60 times a second, or roughly every 16ms. It's previously been difficult to schedule sounds with better accuracy than 16ms because of this. For example a sound played every 25ms would come either 16ms or 32ms apart, with an irregular pattern that would average out to one every 25ms. Now there's a new "Schedule next play" action which allows you to schedule the next "Play" action to happen a short time in the future. This playback is sample-accurate so can even happen between ticks. This makes it possible to get perfectly aligned playback regardless of how often events run.

There's a new 'Audio scheduling' example that demonstrates how to do this with a couple of events. It schedules playback at 25ms intervals up to 50ms ahead, and lets you listen to the difference. This type of technique is important for music-based games or sequencer type apps, where it's important to have exact playback timing which does not depend on the framerate.

Note audio scheduling requires Web Audio API support, which you can test for using the "Advanced audio supported" condition. Pretty much all platforms support it now, except IE11 and older (but Edge does support it).

WKWebView improvements

Since introducing WKWebView support, we've made a few improvements to mitigate the shortcomings it had previously. There's new memory management to avoid music tracks (which have to be kept fully decompressed in memory in WKWebView) clogging up and wasting memory: only one music track is kept in memory at a time now. Also with a heroic hack, we've managed to get video playback working too! Now WKWebView mode includes a local HTTP server solely to serve video files, which means it can dynamically assign a free port without affecting storage access, and still provide a working URL for the video element to play from.

Given these improvements, all features should now be working in WKWebView mode now. Given the great performance improvements in WKWebView, we want to make this a new default if possible. So if you haven't done so already, we encourage you to try exporting your iOS apps with WKWebView mode enabled, and let us know if you have any problems.