Download: CocoonJSAudioPlugin

How to use: Just put the CocoonPlugin as the first entry to register and you can use everything else of the SoundJS-library just as is in CocoonJS now.

createjs.Sound.registerPlugins([createjs.CocoonJSAudioPlugin]);

//this will allow me to play 3 parallel instances of jump.ogg
  createjs.Sound.registerSound('jump.ogg','jump', 3);

direct link: http://labs.indiegamr.com/olines/index.html

For bluring I used this filter: Link – but still: For those kind of operations HTML/JS is unfortunately still way behind flash in terms of performance.

Audio != Audio

While most browsers and devices already do support audio in general, that doesn’t mean you can just play any audio file in any modern browser. The following table briefly lists the support for Audio-codecs.

As you can see there is no single codec and format that is supported by all browsers and devices. In addition to this not every device does support the WebAudio-API and some devices only allow audio-playback upon a user-interaction or only allow playing one sound at a time. So what should you do? Setup an audio file for any codec and then check the browser’s support before loading and playing the file? While this would be currently the only way to do it right, this not only sounds like a lot of work, but also is. What about browsers that don’t support the audio-element at all? – Implementing a flash fallback is no easy task as well.

SoundJS

One possible solution is SoundJS – SoundJS is a JavaScript framework that will take care of all the compatibility issues with audio on different devices and even adds the ability of a flash-fallback should the browser support no audio. You would still have to provide different files for each sound to ensure that a soundfile is available for each device depending on the codec support but besides this, playing a sound with SoundJS can be done with 2 lines of JavaScript:

var src = ‘mySound.m4a|mySound.ogg’;
createjs.Sound.registerSound(src);
//…after the sound was loaded, it can be played by:
createjs.Sound.play(src);

What I also like about SoundJS is that it features a plugin-system, so you can write your custom playback-plugin for individual needs, for example I used it to write a CocoonJS-plugin for it.

howler.js

Another solution is howler.js, it is also released under the MIT license, so you can use it free in any of you projects it works very similar to SoundJS. One advantage over SoundJS is that it is very lightweight with only 9kb and offers pretty much the same functionality as SoundJS – with one exception though: howler.js features no flash-fallback, but if you are targeting mobile platforms, this should be no problem.

var sound = new Howl({
  urls: ['mySound.m4a','mySound.ogg']
}).play();

Another thing I like about howler is the support of sound-sprites:

var sound = new Howl({
  urls: ['sounds.mp3', 'sounds.ogg'],
  sprite: {
    blast: [0, 1000],
    laser: [2000, 3000],
    winner: [4000, 7500]
  }
});

// shoot the laser!
sound.play('laser');

SoundManager 2
A third option is SoundManager 2, (github), just like SoundJS it features a flash fallback if HTML5 audio is not supported. SoundManager2 is used by popular site like SoundCloud, last.fm or the Nyan Cat site. The focus of SoundManager2 is more on implementing audio-players on web-sites as it also features UIs for audio playback. Sounds are played like this:

// create "mySound"...
soundManager.createSound({
  id: 'mySound',
  url: '/path/to/an.mp3'
});

// ...and play it
soundManager.play('mySound');

Comparison

As you can see, all three frameworks have their pros and cons, you should check out their sites and see what features you need for your project. The following table is just a very brief overview on the differences:

*this doesn’t mean that you cannot use it for other cases, it’s just my personal evaluation

A last word: Beware of MP3!

What a lot of people probably don’t know: MP3 is not free!
Implementing mp3 into your app/game is no problem, but what you should know is that if your game is ‘distributed’ (technically that includes 1 user playing the game in his browser) more than 5000 times, you have to pay an mp3 codec royalty of $2500. But not only because of the licensing I would suggest you to use Ogg Vorbis(.ogg) or AAC(.m4a, MP4), OGG and AAC do have a better sound-quality while encoded with a smaller file-size than their MP3-counterpart.

If you want to learn more about the workflow of implementing audio into your html5- (mobile-) app/game and additional information on creating and publishing an HTML5 game, you should checkout my book at: http://indiegamr.com/zerotoappstore/

Download: easeljs_cocoonjs_touchfix.js

(updated version to work with EaselJS 0.7+, thx to Jonny)
How to use: Download JS-fix and implement it through a script-tag somewhere after the EaselJS-script-tag and your done!

Hope this helps someone, comment for any issues,cheers!

If you use an older version of EaselJS: easeljs_cocoonjs_touchfix_pre_0.7.js (for pre-EaselJS 0.7)

Long story short: This is probably the most senseless piece of code I have ever written and most likely will ever have written:

onComplete = function(e) {
  //...doing some other stuff

  // at this point everything is
  // loaded and ready to go
  // ...but ... you know ... the client ...
  setTimeout(
    function() {
      $('#loadingCover').hide();
    }, 3000
  );
}

Here is an example (play around with the alpha threshold and toggle the detection mode):

// Rect Collision
var intersection = ndgmr.checkRectCollision(bitmap1,bitmap2);
// intersection is null if no collision, otherwise a {x,y,width,height}-Object is returned

// Pixel Perfect Collision
var collision = ndgmr.checkPixelCollision(bitmap1,bitmap2,alphaThreshold);
// true or false
// alphaThreshold default is 0, set to higher value to ignore collisions with semi transparent pixels

So I did a little searching to see if I could locate the app and modify it, those were my steps how I removed the ads:

Step 1: Searching the Registry

Bingo! – There is the location of all Windows8 Apps!

Step 2: Taking ownership of the app-folder

Unfortunately I am not able to edit stuff in the app-folder right away, so I took ownership of the folder:

Step 3: Locating the files to modify

Within the folder of the metrotwit app there were quite a few files and folders, one that caught my attention was a folder called “views”. Inside the views-folder were a bunch of XAML-files, including one called “MainPage.xaml”.

Step 4: Editing the file

I opened MainPage.xaml and search for the term “Upgrade to Pro”, this was the label right below the ad. After that I located the visibility-property for the ad-container I just changed the binding to the variable “VerifiedProUser” – which I was not! (see screenshot below) – the ads were gone! Other ways to removed the ads that have proven to work:

• Set the width&height of the ad-container to 0px 0px
• change the dom-location of the container so the element is blocked by other elements

But there are certain restrictions when editing those files, that I found out about:

• The filesize has to stay the same, since there is a checksum of each file listed in the ‘AppxBlockMap.xml’ that is checked every time the application is launched. I was not able to regenerate the checksum, it uses the SHA256 algorithm but apparently with a salt to it, which was too much of a hassle for me to figure out
  UPDATE: I was messing around with some apps a little more today and just found out that you can remove just anything from the ‘AppxBlockMap.xml’ or delete this xml-file entirely => If no ‘AppxBlockMap.xml’ is present, no files will be checked for their checksum, which means that you can now freely add or remove code from any files without worrying about the filesize: Well done Microsoft!
• If the XAML-Object contains an ‘x:Name‘ it cannot be commented out, this will cause the app to throw an error and not launch

The final step was saving the file and starting the application, and there you go: The ads were not visible any more!

I have tested this with several apps and with every app it was a fairly easy goal to accomplish.
What can developers do to prevent this? I’d say the question is: What should microsoft do to prevent this?
However, as a developer I would consider adding certain methods that check the visibility and location of an ad every couple seconds – I have not yet looked into modifying app-logic but I’d imagine this is not as easy as modifying a simple XAML-view.
Or developers can use C++ as this would require a disassambler to get to the source and even then it would be hard to modify stuff…or at least a lot harder than with XAML files.

Thoughts on this are welcome!

Update #2: Obviously there is a tool available that let’s you upgrade trial-versions of app to full-versions for free with on click of a button. I have not tested that tool yet nor would I encourage anyone to use it. But there is no doubt that many users will do so as it gains popularity(can you blame them?). But Microsoft should act quickly.

Update #3: As I got some feedback from people saying “it’s not nice to rip off developers [ect…]” – I do agree! But the point here goes way beyond that: If I am able to modify an app within 15 minutes – then a virus will be able to do the same. Imagine a virus adding some lines of code to the application logic and the next time I use the application all my data(that is accessible by the application) could be sent to an evil server – just to give one brief example.

I personally love the  ‘-webkit-overflow-scrolling: touch’-feature as it allows you to implement a scroll pane for mobile devices with just writing two lines of css and no need of hasseling around with JS to make some content scroll smooth ect., however this approach also comes with a drawback: hardware acceleration will cause performance-issues on iOS (maybe other mobile devices, though it was only tested on an iPad2 running iOS6)

In my last post I was writing about forcing html5 hardware acceleration on iOS6, turns out you do NOT want to do that on every element as this can also cause the performance to drop, pointed out by the following example:

The scenario is the following: The base is a big scrollpane using ‘-webkit-overflow-scrolling: touch‘ that contains many images that are scaled from 100px width to 50px width.
When combining this with forced hardware acceleration it will cause a massive drop in fps while scrolling.

Try it yourself by pointing your mobile browser to the following urls:
Images Example Version 1: http://goo.gl/XIn9e – NOT hardware accelerated, very good framerate
Images Example Version 2: http://goo.gl/DKC1u  - hardware accelerated, low framerate while scrolling, however seems not to affect the execution of JS as the displayed fps does not drop

The only difference between Version 1 and Version 2 is:

img {
 -webkit-transform: translateZ(0);
 -webkit-perspective: 1000;
 -webkit-backface-visibility: hidden;
}

The examples with HTMLImages shows a very huge drop in performance, however this effect is not solely limited to images but also <div> and other elements, even though it takes a larger number of divs to bring down the performance this way, it is possible:

Divs Example Version 1: http://goo.gl/1iF71 – NOT accelerated, fluid, high fps
Divs Example Version 2: http://goo.gl/qkdwm – accelerated, less frames on scrolling, seems to affect the execution speed of JS code

So bottom line: Forced hardware acceleration and ‘-webkit-overflow-scrolling: touch;’ do not work together very well!

1. Not all CSS Properties trigger hardware acceleration any more

Previously there were quite a few properties that triggered a hardware acceleration, for example:

• -webik-transform: translate3d(x,y,z);
• -webkit-transform: preserve-3d;
• …

As Apple states in its Developer Changelog for iOS6: ‘WebKit no longer always creates hardware-accelerated layers for elements with the -webkit-transform: preserve-3d option.[…]‘ There is a need for new CSS properties to trigger the acceleration, unfortunately I’m not aware of any official document by Apple listing those properties.

How to fix it:
Here are three properties that have been proven to work (at least in combination, I have not yet tested them solo, but they should):

• -webkit-transform: translateZ(0);
• -webkit-perspective: 1000;
• -webkit-backface-visibility: hidden;
  

As this is going to trigger hardware acceleration for the specified elements this might still not completely fix all the issues, therefore please continue reading Nr.2.

2. Overlapping with other Elements

Since I cannot downgrade to iOS5 I cannot say for sure if this “issue” already persisted, however it heavily persists with iOS6:

If you have an element(Element A) that is hardware accelerated and animated, it will/might cause performance and visual issues when overlapping with other elements(Element B) that are not hardware accelerated, as Element A will trigger Element B to be re-rendered with every change of Element A(at the end of a CSS-transition or when updating CSS properties through JS), which will cause:

• flickering of Element B, since it renders a lot slower
• heavy slowdown of the animation, since it needs more CPU time to render leaving less time for JS execution

One thing I noticed: If Element A OVERlaps another element it is not slowing down the animation as heavy as if Element A was UNDERlapping another element. Also it does not really matter if the parent-container of Element A has ‘overflow: hidden;’ or ‘overflow: visible;’ – it still slows doen the execution if the overlapping occures outside the bounds of the parent container.

How to fix it:
 a) This can be simply fixed by giving ALL overlapping elements the CSS properties that trigger hardware accerleration. (see 1.)
(My first approach to fix this was by alternating the DOM-order to only have OVERlapping elements, however fix a) is way easier and works way better – for me.)

I have visualized this here:

edit1: 16-10-2012

3. Avoid changes between ‘display: none;’ and ‘display: something;’

Changing the display-state on iOS is like adding or removing an element to and from the DOM and is therefor a very heady calculation depending on how many items you have in your DOM that can easyly cause the UI to freeze for a second or more.

How to fix it:
Instead of using the display-property, use the tranform-property instead, if you want to hide an item you can use something like this: transform:

translate(100000px,100000px);

and if you want to show the element, just set the values to 0:

translate(0px,0px);

You have to set the ‘position: absolute;’ though. This method needs a little bit more work than using ‘display’, however the performance of your webapp will thank you greatly for that.

I hope this helps someone as I was struggeling with this issue for quite a while, thoughts or additions on this article are very welcome!