Christian Heilmann

Author Archive

Helper functions: Resize images to a variable thumbnail size

Wednesday, February 1st, 2012

As part of the “Creating thumbnails with drag and drop and HTML5 canvas” post on MDN today, I spent some time creating a short and working resizing function that takes an arbitrary image and re-sizes it to fit into a thumbnail of a certain width and height. After a few failed attempts I googled around and actually found one of my old PHP/GD tutorials I thought I had deleted years ago. Well, the function still works :)

Without further ado, here is the resize() function (also available as a gist).

function resize( imagewidth, imageheight, thumbwidth, thumbheight ) {
    var w = 0, h = 0, x = 0, y = 0,
        widthratio  = imagewidth / thumbwidth,
        heightratio = imageheight / thumbheight,
        maxratio    = Math.max( widthratio, heightratio );
    if ( maxratio > 1 ) {
        w = imagewidth / maxratio;
        h = imageheight / maxratio;
    } else {
        w = imagewidth;
        h = imageheight;
    }
    x = ( thumbwidth - w ) / 2;
    y = ( thumbheight - h ) / 2;
    return { w:w, h:h, x:x, y:y };
  };

The returned data is the width and the height of the image and the x and y position in the thumbnail – ready to use in HTML5 canvas.

You can test the function in this Fiddle:

TTMMHTM – HTML5 Synth, women in tech, the return of JS, remote tilt, and deploying kittens

Tuesday, January 31st, 2012

Things that made me happy this morning:

One reason why HTML5 gaming is limping along

Thursday, January 26th, 2012

TD;TR: Converting games to HTML5 is hurting the cause. We need more games written in web technologies.

OK, I might be a bit late to the party but the latest “web version” of Angry Birds, “subtly” advertising this time not itself but Wonderful Pistachios was the talk of the day on some of my mailing lists.

The main thing was that it requires Chrome to run. This is nothing new, but I really enjoyed the ingenious way of testing for Chrome in the first place:

if (Modernizr.testProp('-webkit-box-shadow')) {

So the CSS box shadow (which will soon be deprecated with the vendor prefix in Chrome) is the main identifier. Not bad. So let’s hack around the detection with:

var l = document.createElement('link');l.rel = 'stylesheet';
l.href = 'http://wac.5DC0.edgecastcdn.net/805DC0/site/static/css/style.css';
document.getElementsByTagName('head')[0].appendChild(l);
GetCrackin.init();

Which leads us to a JSP file that detects on the server side and writes out a lot of inline webkit only code OK, never mind.

I am less annoyed that this is Chrome only. It was never claimed that this game runs everywhere (other than the Angry Birds released on Google IO). I am more annoyed about the bad performance the game has in Chrome and Safari on this Macbook Air. And I know the reason for this: conversion instead of dedicated development.

A look back in time – games on Commodore 64

As I have mentioned before, I used to work on some games on Commodore 64. In its heyday there was no way to have a game without writing it by hand – in assembly language and knowing what all the chips do. Perusing the memory map and the ROM allocations was part of the game of writing one.

When computers got more ubiquitous and better in terms of sound and graphics a lot of companies started building games on the other machines first – Amiga mostly. And to make extra money and sell even more copies, they also made C64 versions as conversions afterwards. These were most of the time shoddy at best and weren’t tested much. The C64 was the machine that is not where the money was made – the new hardware was the one to support.

The thing that got lost – and later on even more so – was the tinkering with the hardware and finding tricks to work around limitations. Out of the box the C64 had 8 sprites and a resolution of 160×200 pixels in 16 colours or 320×200 in 2 colours per 8×8 pixels. Using interrupts (executing code whilst the screen was painted by the TV or monitor) people came up with multiplexers that allowed for hundreds of sprites. With overlaying techniques we produced 256 colors at a interlaced 640 pixel resolution and so on.

A few of those tricks made it into the conversion tools from the “higher” computers to C64 code, but most were deemed too costly and time consuming and didn’t make sense to do any longer.

HTML5 gaming without the web stack?

This is happening now with “HTML5” games, too. Angry Birds is done with Google Web Toolkit, converted from Java I presume. It is made to work quickly and not show off what a web game can do, but instead how easy it can be to convert a game from Java to the “web”. And when that fails to bring the results it should, then we limit the web to one browser. And even fail at that as Angry Birds – in this case created to promote Chrome as a HTML5/games platform – doesn’t work on my Chrome book – the hardware dedicated to the browser.

Seeing this makes me frustrated, and it causes a lot of sniggering up to outright laughter from the Flash community. And they have all the right to. Flash games perform well, and showed that they can be easily changed and rebranded and extended when you build them the right way.

The HTML5 game engine vanishing act

Of course there are great minds on the case already and a lot of people build great demos and JavaScript frameworks to build HTML5 games in the technology rather than converting to it. The interesting thing about that is that every games engine released open source very quickly gets bought and un-opensourced and then vanishes from sight. The optimist in me thinks that this means there is great stuff afoot. The cynic in me sees the talent behind and the engines rotting away in a corporate environment as they were seen as a threat instead of an opportunity.

What HTML5 gaming needs to impress

I would love to see more real web games. Built in open technologies, with source available (or not, this is a nice to have) and really using the web. A web version of Angry Birds to me wouldn’t have a very long loader and ask me to sign in to Google to use it. It would be snappy and load the levels on demand, storing the ones I played and the next one locally in my browser while I am playing the current one. It would also allow me to build my own levels and share them on Twitter to see if I can build awesome stuff in the game that other people enjoy. All of this would be a total pain to make work on a mobile and a 3G connection, but is very much fine in a browser on a laptop with a good connection.

In other words, HTML5 games should be fit for the environment and use it to its strengths.

What about WebGL?

WebGL is an awesome opportunity for game developers to get into web gaming without needing to learn a new skillset. It is pretty obvious that an openGL developer could take it up much easier than a web developer would. Right now, WebGL is great for demos, but we have the issue of hardware access. If the biggest sound of the game is the fan of your processor and video card then this diminishes the experience. I for one never started gaming on PC as every new game coming out told me I need to buy new hardware in order to play it. This is not what I could afford. And this is not what we should force onto people on the web. A web app saying I need a certain browser or that my video card is not good enough to use it is not much better than the old “best viewed in IE4 with 800×600 pixels”.

We should think less World Of Warcraft and more Doodle Jump when it comes to HTML5 gaming.

Maybe I am a dreamer, and this is so not how the games market works. That is fine, though. A new market could emerge that takes the best of offline gaming and online experiences. But, we need to make that happen.

Some real world browser stats

Thursday, January 19th, 2012

Having pestered someone working on a large healthcare web site in the UK to release some of their browser statistics I got a tweet today that they released an infographic (available here as a PDF). The site has had over 2 million visitors in 2011 and here is what they looked for:

visitors and where they went

Most went to the homepage and then to services. A big part was search and services offered.

In terms of devices used to read the site the web is not really as mobile as we make it out to be:

Devices infographic

Windows rules supreme, followed by Mac, iOS, Android and Blackberry. I was surprised at the low number of Blackberry actually. It would also be interesting to see just how many services like meeting times are done via text message.

The browser share was the real blow here:

browser statistics

Internet Explorer accounts for 55% of the numbers, with Safari at 16% and Firefox at 14% following after quite a gap. Chrome clocks in at 11% and others with 4%.

When it comes to the version the IEs used, the numbers are interesting:

IE versions

With 47% IE8 is the most used browser, followed by IE7 with 24% and IE6 with 19%. IE9 only accounts for 10%.

Of course these are not stats of a common web site, but it shows a few things to me:

  • Web sites that people really need to go to would be wise not to block out older browsers
  • The large numbers of IE8 and Safari shows us that browsers that come with the OS are the weapon of choice
  • IE8 will be a problem to face for a few years to come

I love that the St. George’s trust made these insights available, and I’d love to see much more of these being released. Browser data from counter companies is to me just a very small percentage of the market of sites that provide services to people out there.

Domo-Kun in CSS

Wednesday, January 18th, 2012

And in the “pointless but fun” section and as my preparation for the trip to Japan tomorrow for Mozilla Vision 2012 I thought it would be fun to try to create a Domo-Kun in CSS from two lists of info about it.

I am sure real CSS gods like Lea Verou and Chris Coyier could do it in one element. :)