And there were the same problems on Android – plus more. Sound should naturally be played asynchronously by the browser engine while the JavaScript runtime proceeds with game play, but this was not so.
#HTML5 VIDEO PLAYER NOT WORKING IN CHROME CODE#
On iOS (6, on iPhone 4/5), the results were erratic: having multiple audio elements on the page, started from code or by click / touch events interfered heavily with the DOM updates of the game engine. In case you didn’t want the audio as DOM elements, you could use the instantiate audio objects via JavaScript this way: var audio = new Audio(“my file”) īut it doesn’t really make any difference. The idea was to create a very simple jQuery component to be added to Pupunzi’s jQuery components library. Simple enough.Īs our application is pure JavaScript, and as backgrounds sounds and effects change during gameplay, we couldn’t just “print” the HTML audio elements in the page, we created a simple function to inject such element in the DOM when needed, and to play, pause, stop the audio.
Now no library was minimalistic in code, and as what we needed seemed so simple, we decided to try to just use the element and play that. So we had the choice of either looking inside these third party libraries to see what was the problem, or do something ourselves. Moreover we didn’t want the Flash fallback. Some demos didn’t even load pages correctly, like !/SoundJS/demos/testSuite, others worked but were “audio player” oriented, like. While the ones tried were mostly working on desktop browsers (meaning Firefox and Webkit family), first test with multi audio on Android mobile weren’t working. Given our limited intellectual means and minimal requirements, we first checked available HTML5 audio libraries in order to include them and so we didn’t have to reinvent the wheel. We also got further confidence by consulting sites such as where it shows the audio element as fully supported since several major versions.īig, big mistake.
Java, Flash, Unity…) so we started in a quite confident mood. There is no development platform built in the last 20 years that does not support such minimal requirements for audio (and much, much more, see e.g. The background audio is not responsive with respect to game events.īeing a 3-match game, events are at a slow pace so effect sounds would be mostly played one at a time, at most two having a partial overlap. Our audio feature requests are very limited: we want a background track for the game, changing only at level change, and a few sound effects on events. This looks like a peachy start, as the browsers for which support is required are on mature platforms supporting (in theory) a wide range of HTML5 features. Hence we would want our audio solution to work also on desktops. With the well known scaling trick (CSS “transform: scale(…)”) which we built in our mobile app, we got it to run quite nicely in all resolutions, so also on desktop browsers. The game is for mobile browsers, actually a limited and updated range of mobile browsers: Safari for iOS 6+, and the stock browser (i.e. The game: Bust the Dust This story starts when we had to provide audio to an HTML5 game we were building.
0 kommentar(er)
