I tried to kill it, officer, really
Not actually dead, Jim
I was really looking forward to a Bones pic for this post. So I’m going to put one up anyway, because I’m stubborn like that.
The latest update of the HTML5 iPhone test app introduces touch events to the app. Yes sir, that’s right, the user now has an interface. Of sorts, anyway. The purpose of this update, and the reason why I thought it was going to allow me to blast the app into oblivion, was to add a new goblin token every time the user touched the screen and start sliding that token back and forth with all the tokens that have already been added. With the amount of JavaScript processing going on to move and render each individual token, I wondered if I’d be able to get 20 or so tokens moving before my iPhone 3GS started to show some serious stutter. Yeah, that didn’t happen.
THIS IS CANVAS!
At one hudred tokens, I finally got the iPhone rendering to drop below 50 FPS. At three hundred tokens, all animated to slide back and forth with every heartbeat tick, the FPS on the iPhone drops to 24FPS, but honestly if it wasn’t for the number printed at the top of the screen, I don’t think I would have realized it.
Now is probably also a good time to point out that on my desktop, I haven’t seen the slightest dip in FPS no matter how many tokens I add to the screen. You desktop HTML5 developers are in really, really good shape.
The extra code that I mentioned in the last update to make this piece a snap to add worked swimmingly. Thanks to the wonders of OO programming, pretty much all I needed to add to get hundreds of tokens rather than a single token was the following:
tenbyten.CanvasApp.prototype.touchStart = function(event){
var touch = event.changedTouches[0];
var token = new tenbyten.Token("images/token.png");
token.setCoordinates(touch.clientX , touch.clientY);
this.tokens.push(token);
event.preventDefault();
};
As an aside or three, in the process of adding the touch event, I learned a few tricks to getting an iPhone web application to behave more like a native application.
Trick the first: as soon as the app is loaded in the browser, call window.scrollTo to move the location bar out of the way. This both makes the screen look more like a native app with less of the browser UI in the way and provides your app with more precious screen space. Like so:
if(!window.navigator.standalone){
window.scrollTo(0, 1);
}
Trick the second: did you catch that test for whether navigator was in standalone mode in there? If a user bookmarks your app and saves it to their home screen, several nifty features open up. 1) You can specify an icon and loading image for your app. 2) You don’t have any of the Safari UI in your way, granting you even more valuable screen real estate. 3) You can even cache all of your resources on the device so that even if the device goes offline, a user can still run your “web” app.
Trick the third: use event.preventDefault() to keep Safari from panning up and down as the user “drags” the canvas element up and down with their finger. Again, this allows your web app to behave more like a native app and gives you the opportunity to support drag events from the user across your canvas. Note: the only way I was able to disable the standard panning behavior when the app was running both within the browser and in standalone mode was to add a preventDefault() trigger to the body element in the HTML page:
<body ontouchmove="function(e){e.preventDefault();}">
At this point the web app is running strong and feeling an awful lot like a native application. I wasn’t sure when I started this project that this would be the result, and to be honest I’m thrilled with the results so far. So come on you HTML5 developers, lets see some apps for the iPhone!
Next step: multiplayer.
Minor update
Still merrily cranking along
As you can see, the test app has been updated to support a wee bit of image rendering for today’s iteration. Things you can’t see are A) the image is animated to slide back and forth across the screen, and B) there’s probably three times as much JavaScript code now under the hood as I add a whole bunch of object oriented design to the implementation of the app. This will help make tomorrow’s update super easy (or so he says now…).
The FPS numbers are still hearteningly very, very high. However, I will admit that the human eye can detect a bit of stuttering every couple of seconds or so as the image slides back and forth across the screen. This is true on the desktop as well, so it seems to be more of an HTML5 engine thing than an iPhone platform thing. We will see as things progress whether it ends up being too distracting for the player or if it ends up being unnoticeable in the end.
Plan for tomorrow? Kill the app dead and dance on its sticky bones. More soon!
It’s…alive!
The first question we need to answer when exploring HTML5 development on a mobile device is whether the hardware is going to be powerful enough to create the experience we want our users to have in an interpreted language like JavaScript. Towards that end, the first test app I built was a very simple JS application that did the least I felt I could get away with:
1) Created a 2d Canvas the size of the screen resolution of a bookmarked webapp on the iPhone (320×460) and grabbed the context
2) Started a heartbeat timer that would optimally go off every 10 ms with setInterval()
3) Every time the heartbeat fired, change a random RGB value one point either up or down (also randomly)
4) Repaint the screen with the new value to show animation working and display the number of times the heartbeat fired in the past second (Frames Per Second)
In other words, I wanted to measure the FPS I could crank out of the iPhone without doing anything else. If the FPS was in the 10-20 range, the type of animations I’d be able to support in a game would be much more limited than if the FPS was in the 40-60 range. Here’s what I got on my iPhone 3GS:
Yeah. That'll do.
83 frames per second. Which is about 5FPS slower than my Chrome desktop can put out. And conventional wisdom for PC game development is that anything beyond 60FPS hits the diminishing returns curve pretty hard.
Of course, this is with ABSOLUTELY NOTHING else the app has to handle, so it’s not time to pop any champagne corks yet. But a critical first hurdle has been passed. Hooray!
Breaking news
Surprise!
Yes, Universe, you’re absolutely right. We should consider Android devices as well.
The world works in mysterious ways. Literally as I was in the middle of writing up that last post, my Google+ feed exploded with the news that Google has released a version of Chrome for Android. This is supergreat news for HTML5 development on Android and I’m thrilled. Really. I’m not at all upset that I probably need to go get myself an Android phone now, and neither is my wallet. More to come, this is a pretty major development for HTML5 mobile apps, seriously.
[UPDATE] Mashable is pointing out that only about 1% of Android devices have Android 4.0 on them and thus can support (this release of) Chrome. At least that makes the device testing simpler, doesn’t it?
HTML5 on the iPhone? Are you crazy?
I loves me my HTML5. I’ve been a JavaScript lover for, gosh, approaching 15 years now (no backtalk, young whippersnappers!). Long before Google Maps showed us how versatile the web environment could really be and began to usher in the age of web apps, I was fascinated with the idea of programmatically controlling parts of the browser behavior. It was a bizarre little proto-programmer fetish, but it stuck. Over the years, as I grew into a professional software developer, I’ve had the occasional opportunity to return to JavaScript. As an embedded engineer for the CableTV industry, I wrote some of the native code that runs under the hood of those JavaScript APIs and learned a lot about how a JavaScript engine really works. On my own time I dabbled into a couple of silly Konfabulator apps (now Yahoo! Widgets). I was pretty excited that one of those managed to pay for my lunch for a couple of months. More recently I’ve written a graphical dice rolling gadget first for Google Wave and then for Google Hangout. And now, for the first time, I’m looking to write a full game in HTML5, and the iPhone is the target platform.
This may be crazy. The little computer in my pants is possibly the best thing ever invented, but it’s not exactly the speediest processor available. Full games are beginning to show up in HTML5 for modern browsers like Cut the Rope or Fieldrunners, but it’s a long way from a PC desktop browser to the mobile platform. However, if all goes well, for reasons that will be quite clear later, the iPhone is the clear platform for this game.
Why HTML5 instead of native code? There are several reasons. As mentioned above, I really do like the JavaScript language (though whether I continue to feel that way at the end of the project remains to be seen!), I’m super excited about how the language is maturing into a genuine application layer, and I’d like to help however I can to make that happen. Conversely, while I’m confident as a user, I’ll be clinging to my iPhone with my cold, dead fingers as a developer there are many, many things Apple has done with the iOS development ecosystem that I dislike. I want to keep things in this blog positive as much as possible, so I’ll go through a few of the issues I have with Apple real quick and then be done with it:
1) Requiring developers to learn Objective C to write applications for iOS. Come on, Apple. No one uses Objective C except you guys. Everyone else in the whole wide damn world moved on from C to C++ to Java/C#/JavaScript/Ruby/Flash/Python/whatever and we’ve never looked back. Requiring developers to learn a brand new language just for your platform is stupid.
2) Setting up the App Store as a required gateway for users to download or buy iOS applications. I know Steve Jobs was notorious in his micromanagement, but this is absurd. Let the users decide which apps they do or do not want on their phone. Apple should give their developers access to the OS and get out of the way. Let app developers build for your platform and let your users decide which apps they want without interference. By inserting the App Store as a middleman, Apple sets itself up as censor for all content on the device, which adds a whole new layer of repugnancy to the system. Oh, but that’s right, Apple has…
3) Profit motive. At the time of this writing, Apple had just released an obscenely impressive earnings report, showing that the company is now sitting on a pile of cash which, all by itself, is worth more than all but 52 companies on the planet. Which, you know, great! Good on Apple. They build a good product and should be rewarded for it. But when you’re sitting on all that money and raking more in every quarter, it makes it hard for me to sympathize with the 30% pound of flesh Apple requires of all iOS developers and publishers. As much as we hear it from GOP millionaires running for public office, I really am a small-time indie developer trying to earn a living for my family. Honestly, I’ll consider myself lucky if I can get that far. I literally can’t afford needing to earn 30% more in order to break even. Apple obviously doesn’t need it either, so at the end of the day they’re just being greedy jerks. Screw ’em.
So! Hostility aside, that’s why we’re here, writing about HTML5 on Apple devices. This is the brave new world of giving iPhone users the choice of which applications they want to run on their iPhones and give iPhone developers a better chance to earn a sustainable living writing for the iPhone ecosystem. The reason I started this blog in the first place was because I wanted to share my discoveries with other developers so that more developers can follow. I want more apps for my phone, too. I want to pay the developers of those apps their fair share for their work. Let’s figure this out together.
Hey howdy hey
Merlin is the best mage
Hello there and welcome to my shiny new blog. You’ve discovered the obligatory first post where I tell you a bit about myself and what I’m planning to write. There are, as it should happen, a few different purposes for the blog, and I’m afraid they serve a few different audiences. Wiser people than I would say this is a terrible idea and that if I have multiple audiences I should write multiple blogs that cater to each audience. To which I say, bugger that, we’re going to be lucky if we get through a single blog together, you and I, let alone several. Moreover, this is not the first terrible idea I’ve ever had and certainly won’t be the last. Perhaps things will work out all the same. I, for one, am excited to find out.
However, my heart is not entirely closed to those who may come to this blog for one purpose and find some of the entries in here completely uninteresting to them. For you, dear friends, I will provide tags and/or categories that I will be strict about using with every post. (Not least of which because I love breaking things down into little categories. A lot. Quite possibly too much. But mostly for you!) And if I am clever enough and have time enough at some point in the future, I hope to introduce a schmancy color scheme that will allow folks to be able to tell at a glance which category any particular post may fall in. I can’t say the categories will be neat and perfect, as I am living evidence that one category of stuff can bleed into another, but it seems like a decent enough starting point.
Get to the point
But enough of that. (Really. Yikes. The fingers, they just keep going, don’t they?) What, exactly, was going to be the point (or points, not unlike a shuriken) of this blog again? Threefold, my friends! You may know I’m a regular user of Twitter. Sometimes, especially right now, I have a few thoughts in my head that may take a little more than 140 characters to communicate. This will become the repository of those big thoughts. Said grand thoughts tend to come in three basic flavors:
1) work thoughts – Usually programming, possibly sometimes other thoughts about being the cofounder of a very small game development company.
2) game thoughts – I play games. I like to talk about things. I probably want to talk about games.
3) life thoughts – As the parent of two young boys, there are likely going to be stories to tell from the family arena.
I bet you can see the problem here. Some friends and family are going to (I hope!) stop by from time to time to see how we’re getting on and what trouble the kidlets are getting into these days. The chances of these folks being interested in the latest HTML5 discovery I made is probably pretty slim (though non-zero), and vice versa. Well, hence the tags and categories and eventually the colors and hopefully all will be well. We’ll find out together.
So! Now that all that is out of the way, I can start posting about all the HTML5 stuff I’ve been uncovering, which was the catalyst for me finally taking the time to kick off the happy fun times. Let’s begin!
10×10 Room
My company
Conclave
Our first game
archmagus 