Posts tagged with “Canvas”
Less talk, more action – Apple just approved two of my JavaScript games for the AppStore: Biolab Disaster and Drop. Both are free; go check them out. You can also play them in your browser here and here.
Both games are pretty simple (the source for Drop is only 300 odd lines long) and written with my JavaScript Game Engine Impact.
These are certainly not the first games written in JavaScript to be available in the AppStore. Tools like AppMobi, PhoneGap or Titanium make it easy to bundle some HTML pages and JavaScript together in an App and display them in a UIWebView, which is basically just a browser window (correction: Titanium doesn't use a UIWebView but instead has some native bindings). Games written with Impact already work okay-ish in the iPhone's browser and thus also in AppMobi and PhoneGap.
So what's so special about these two games now? They don't use PhoneGap or Titanium. They don't even use a UIWebView. Instead, they bypass the iPhone's browser altogether and use Apple's JavaScript interpreter (JavaScriptCore) directly. All graphics are rendered with OpenGL instead of in a browser window and all sound and music is played back with OpenAL instead of… well, having no sound at all.
What makes this possible is a compatibility layer that mimics the HTML5 Canvas and Audio APIs but is implemented with OpenGL and OpenAL behind the scenes. Think of it as a browser that can only display a Canvas element and play Audio elements, but does not render generic HTML pages. A browser perfectly suited for HTML5 games.
This means you can take your JavaScript games written for Impact and run them on iOS with perfect sound and touch input and way better drawing performance than with Mobile Safari. Now, to be clear, I only implemented a bare minimum of the Canvas API - just enough to be able to run Impact. The whole thing is still in a very experimental state.
If you have a license for Impact you will find the complete source code for this all on your download page. I also wrote some basic documentation to get you started. In theory, you don't have to know anything about Objective-C to use this, but at this stage some Objective-C knowledge will sure come in handy. Again, this is very experimental. Don't expect it to work at all.
If you've been following this blog for a while, you might remember a post from October 2010 where I attempted the exact same thing. Back then I used the JavaScriptCore library that is already available on iOS and used by Apple in Mobile Safari. The problem was, that this library is "private", meaning that Apple does not want you to use it. And since you can't publish anything in the AppStore that uses private libraries I abandoned the idea.
However I recently revisited the project, because there was still a chance to make this work: JavaScriptCore is a part of the open source WebKit project. Instead of using the private library that comes with iOS, you theoretically could compile your own version of this library and bundle it together with your App. Which is exactly what I did.
Since Apple does not provide any project files to compile JavaScriptCore for iOS (presumably to annoy us) and JavaScriptCore itself uses some of iOS' private APIs, compiling this beast into a static library - in an App Store compatible fashion - took me a few days.
I also had to make a small sacrifice: JavaScriptCore uses libicu to sort strings according to a unicode locale. Sadly, libicu is also private on iOS and bundling it is not an option because of its size. So I got rid of libicu completely. This means that only ASCII strings are now sorted correctly (e.g. the umlaut "Ä" will come after "Z", not after "A" as it should). Other than that, the JavaScript library should behave exactly as the private one that comes with iOS.
Also, the JavaScriptCore library bundled with iOSImpact does not use the JIT compiler (Nitro). You can't allocate executable memory on the iPhone and if Apple doesn't lift that restriction, there's nothing I can do about it. However, Apple recently made an exception for Mobile Safari – if they would make their JavaScriptCore API public, they probably could enable the JIT for everyone. That's a big if though; I don't see it happening, because Apple loves native code (Objective-C) and hates scripting languages.
I was afraid Apple would reject the two games for some obscure reason, but they didn't. Which leaves me to wonder why the JavaScriptCore library that comes with iOS is private in the first place. Bundling JavaScriptCore with your App adds about 2MB in size – not much, but I fail to see how this can be in Apple's interest.
Anyway, the performance of both games is pretty good. I still get some occasional slowdowns (~20fps) on my iPhone3GS in Biolab Disaster when there are too many particles on the screen, but it remains playable at all times. It's also nice to have perfectly working sound on iOS now - something even some desktop browsers still struggle with.
The Mozilla Gaming Blog just published a guest post by yours truly. I write about the creation process, graphics and gameplay aspects of Z-Type, complain about HTML5 Audio and, of course, advertise my JavaScript Game Engine Impact.
Please enjoy Game On Spotlight: Z-Type.
I planned for a while now to participate in Mozilla's Game On contest. I didn't want to submit Biolab Disaster as my entry, but instead make something new and fresh. After all, the deadline for the contest was still months away. When I read this tweet I realized it wasn't anymore.
At this point I started to work on a game I wanted to make for a long time. I always was a fan of Crimsonland's (a 2003 arcade game) Type-o-Shooter mode and recently discovered the Dreamcast classic Typing of the Dead. So the overall direction of the game was clear.
Today I finished Z-Type. Please Enjoy!
I recently came across the hqx Scaling Algorithm for upscaling pixel art images. hqx was originally developed for the ZSNES emulator to scale up each frame in realtime and is thus written in fast (read: ugly) C code.
I took the challenge to implement hqx in JavaScript for Biolab Disaster and I think the result looks great. The algorithm does an extremely nice job with "organic" structures such as all the rock tiles, but tends to make low contrast zones quite blurry.
hqx comes in three flavours: hq2x, hq3x and hq4x. All of these are implemented in the JavaScript version and you can directly test them with Biolab Disaster hqx (the links below the game).
The source for the JavaScript implementation of hqx is available on Github under the GNU LGPL.
(Silly title, I know, but how could I ever resist such an opportunity?)
My HTML5 Game Engine Impact is now ready. It took some time, but I think it was worth it. I'm proud of what I have achieved and I hope you'll like it too.
Part of why it took so long to put it all together is that it now runs on the iPhone, iPod Touch and iPad. Try it yourself at playbiolab.com and impactjs.com/drop or watch a short video:
All those platforms still have their problems with sound and the iPhone 4 has a hard time filling all its pixels, but the games remain to be playable even on the 1st gen iPod Touch. You can read a bit more about Impact on mobile platforms in the documentation.
Even with iOS support, it might come as a shock to some of you that I am selling Impact, rather than releasing it for free. I love free and open source software and I've been contributing stuff for quite some time now. I had a hard time thinking about whether to release my Game Engine for free. The reason I decided to charge for Impact is a) it is easily the biggest thing I've ever made and I'd love to continue working on it full time, and b) I believe it is worth the money.
Ironically, my decision to sell Impact set back the release date quite a bit. If I'm selling something, I want it to be worth every penny. And even though the engine hasn't been far from completion for some time, I hadn't written a single line of documentation.
I feel that a good documentation is crucial for the success and adoption of any software project. So I set myself the goal to write the best documentation I possibly could.
I'm not a big fan of inline documentation (with documentation generators like JSDoc) because it tends to clutter the source code with trivial statements and – more importantly – makes it easy to write bad documentation. If you are writing the documentation separately from the code, you think about it differently. You think about the documentation as something that works without the source code, something that makes sense without the source code.
You rarely see code examples in automatically generated documentations, but for me as a developer, code examples are oftentimes exactly what I need. Take a look at the documentation for the ig.Entity Class - one of the more complex classes of Impact. This is something documentation generators just can't do.
Of course it took me longer to write the documentation separately than it would have if I wrote it inline, but this is only because it is more in-depth, more thorough.
But don't take my word for it. Please see for yourself!
On a lighter note, I'm currently sending out a few thousand emails to those who signed up on the old Impact landing page. I'm using a 10-line PHP script for that. Let's see how this turns out...
Before I go into some details of my HTML5 game Biolab Disaster, let me use my 15 minutes of fame to say the following:
Safari, please get your shit together! You are a very nice browser; my game runs with an excellent frame rate and everything works fine. But please (please!) support the Ogg Vorbis codec for Audio elements. There is no reason not to. I had to encode all my sound files in Ogg Vorbis and MP3, just because of you, Safari. You make my life unnecessarily difficult.
(I could now go on and say the same thing about Microsoft's upcoming IE9, but I don't care enough about their half-assed attempt to build a browser)
Biolab Disaster was completely build for HTML5 – that is, JavaScript and the new Canvas and Audio elements. It doesn't need any Plugins, just a good browser. The game was initially conceived as a demo for my Impact Game Engine, but it became much more in the process. I made a short making-of video that shows how the game and the engine were built:
Despite this all being a relatively new technology, the browser support is pretty good already. When I began with this project it wouldn't run in Opera at all; now Opera has one of the best Canvas and Audio implementations around. Current versions of Chrome and Firefox still have some sound issues (lag) but otherwise run the game fine. I did some performance tests on different browsers and platforms:
Frames per Second
A frame rate below 30 starts to feel “chunky” and anything below 20 is not really playable – or at least no fun to play. The iPhone 3GS and iPad therefore sadly fall into the “unplayable” category. The performance on an iPhone 4 should be significantly better, but I don’t have access to one at the moment. Mobile Safari also won't load the sound files correctly as it seems – the game is stuck in the preloader. I will look into it a bit closer in the coming days.
It's worth noting that – regardless of the browser – JavaScript performance was never an issue. The real bottleneck is the Canvas API. All browsers spend about 90% of their time drawing into the Canvas. Especially Firefox is a bit on the slow side, but with the upcoming hardware acceleration in Firefox 4, performance shouldn't be a problem anymore.
Biolab Disaster formulates the playable truth that it makes sense to create games for HTML5. Not only is the result on par with current Flash games, but also is the development process incredibly smooth and satisfying. The hurdles that a new technology such as HTML5 sets, were already overcome by the game engine. For the development of the game itself, I didn’t have to deal with any browser or platform issues at all.
With Microsoft delivering some HTML5 support in Internet Explorer 9 and JavaScript and rendering performance steadily increasing, I can’t see any reason why JavaScript and Canvas would not be the gaming platform of the coming years that finally removes Flash from its quasi monopoly.
See for yourself.
More than two years ago, I created a Flash Animation for my university class. Today, I converted the whole thing to plain Javascript and HTML5, using the new <canvas> tag to draw and the <audio> tag for music playback. It now runs smoother than it ever did in Flash.
Without further ado: Venetianization / HTML5 Animation
Some technical notes: For the original Flash Animation I used ActionScript 3 and created my own classes. Javascript doesn't have classes per se, but you can build something that looks and feels exactly like it. MooTools did an awesome job at that. Converting my ActionScript classes to MooTools classes was a no-brainer.
I was able to reuse most of the code with some basic search and replace throughout the source. One thing however, that is (to date) completely missing in Javascript, is the ability to analyze the current sound spectrum of an audio file. I ended up extracting the raw values of the spectrum with a sampling rate of 15Hz (which is enough for an animation that initially ran at 30Hz) and put them in a large array in one of the source files.
The thing that annoyed me the most however, is that I now have the music in two different formats: OGG Vorbis for Opera, Firefox and Chrome, and MP3 for Safari. I totally understand that Firefox, being open source and all, can't include MP3 support. What I don't get, is that Apple doesn't support OGG Vorbis – an audio format that is clearly superior to MP3 – instead, they choose to sit on their high horse and twiddle their thumbs. This is exactly the behavior that made Internet Explorer a laughable side note.
Side note: Of course none of this works in any version of Internet Explorer.
