Browser Share, and WebGL support. Is it worth using?

As it's been a while since I last wrote here, I thought I'd ponder some of the things I've been doing lately. At YoYO Games, we have just released an update to GameMaker:HTML5 that contains the first Beta of WebGL. Now, WebGL is pretty cool, and the support inside GameMaker:HTML5 has turned out really nicely. At first, I was going to do a very simple port, getting it "working" and nothing else, but it soon became clear that this would be a crime! That I'd leave SO much on the table, that I should either do it right, or not do it at all.

So I did it right.

The great thing about how we created GameMaker:HTML5 is that it already does a LOT of the hard work required to do good hardware batching, and but making up highly compressed texture pages we were halfway there already! You see, the thing about hardware, is that they don't like to draw a few triangles at a time, they get really upset about it in fact. What they really want, is for you to submit the WHOLE scene in one go, then they can ignore the world and just get on with it! Now batching textures into large texture pages is the first step to doing that, because it allows you to draw many different sprite images, from the same texture page. You see, whenever the CPU has to change something; textures, blend mode, rotation/project matrix, render state, then it has to stop rendering, and when it does this, it just gets in the way. So removing unneeded texture state changes, is one of the big obstacles out the way. Sure you probably can't use a single page, but packing them means there will be minimal changes, and that's exactly what you need. We've had lots of requests to not load pages, but load everything in single images - for a load of reasons, but we've always refused, mainly for download and bandwidth speed, but also because we know graphics, and we know going forward, this is what you want.

So with this step out the way, I could start to collate triangles to draw. But there's a trick here too. So in native code when you use a vertex object, you can't partially fill a buffer, draw using it, then fill it some more as this (usually) causes a stall. You need to fill the whole thing, then you can set it, and then draw whatever you need from it. So we've created a system that builds up whole game frames of data, and then submits it at the end, and what this does, is allows us to completely pack some very large vertex buffers, which in turn, means we don't have to keep setting buffer streams, vertex constants and the like. Again... this is all good.

Lastly, the whole recorded scene is submitted in a tight loop with minimal state changes, and then we're done.

So.... What does this give us exactly? Well, in terms of raw throughout, we have an increase of about 10-15x!! On Chrome using canvas drawing only, we could achieve around 7000 sprites (30fps), where as with WebGL, we can now achieve around 110,000 sprites! That's a little over 15x speed up! Now, at this point we have two choices, first we could decide to use WebGL ONLY, and ignore all IE, Safari (PC) and current Opera users, or we can use WebGL as an upgrade only to help smooth things out - more on this later.

Now, if your like me, you would try and find some stats to help you decide. There are issues with getting stats, in that depending on where you look, you'll get significantly different ones! As a project for the reader, go and google browser share november 2011, and you'll find heaps of different pages all telling you different numbers, and this is because these sites simply record who visited THEM, and what browser they used. Now sites like apple, will mainly be visited by Mac users, while Linux sites may well be visited by Firefox users (just examples, no proof of this). This means each site has its own "view" as to what the share is. But lets take one view... the w3schools.com numbers.

IE:21.2
Firefox 38.1
Chrome: 33.4
Safari: 4.2
Opera: 2.4

I suspect IE is higher and Firefox/Chrome lower, but lets run with these for now. If I were to decide that I couldn't afford to lose the 27.8% of the market for my game, then I'd have to decide to simply use WebGL to smooth things out only, but lets take a closer look at these figures. Of the 21.2%, only 5.1% is actually IE9, and so HTML5 capable!

IE9: 5.1
IE8: 11.5
IE7: 3.4
IE6: 1.2

Now, this puts a different spin on things, because if your doing an HTML5 game, you only really care about users who have capable browsers, and that means IE9, Chrome, Firefox, Safari and Opera.

So, if we remove the IE8,IE7 and IE6 numbers, we get a different picture:

IE9: 6.1
Firefox: 45.7
Chrome: 40.1
Safari: 5.0
Opera: 2.8

Now, this means that WebGL capable browsers have just taken up 85% of the market - that's a lot! But there's more to this story, first is this Safari on Mac or Windows? Who knows, but Safari on the Mac also has WebGL (although it's off by default). Now no one in their right mind uses Safari on the PC as it's pants, but let 1% does. Aside from being mad, that adds another 4% to the WebGL market giving us 89% Lastly, Opera 12 (the next major release) also supports WebGL, and while there's no release date yet, if your planning a future game, it makes sense to include these numbers as it won't be far off, not with the speed browsers are currently being updated! So that's another 2.8%, tipping us over into 92.6%! That's a hell of a large audience for a WebGL only game! If it was reversed, and IE9 had that share, you can be sure folk would ignore the rest and write dedicate IE9 apps. There are also a couple of extra things to help tip the balance. First, most folk wanting to play games like this will happily install a browser that lets them, only real casual "mas market" gamers (Facebook types) will stick with what they have, but as Chrome has a nice plugin (even for IE6 users!) then you could prompt them to install this plugin and get them as well. which would increase your market share again!

So, taking the raw numbers, it would seem that - depending on the game - you could justify doing WebGL only... but first, a realistic view of these numbers.

So... yes, this is taking it to extremes. First, it's a single site that may well have biased viewing that skews the numbers in the first place, and that may lower your overall numbers by (say) 10-20% or more, which is a lot. Second, the Firefox and Chrome numbers ALSO include old versions which don't include WebGL (or they are too buggy or slow to be of any use anyway), although now that Chrome auto updates, most Chrome users are actually on the latest version - which is great news. Firefox is a different story, there are still FF3 users out there, and that sucks.

Lastly... Microsoft is about to change the way it's own browser is updated, meaning that everyone (pretty much that matters) will be upgraded to the latest that their OS can handle. This means Windows XP users will move to IE8, and Vista/Win7 users will move to IE9, and that brings a LOT of new potential customers to your game. Windows7 has (according to Microsoft), finally overtaken WindowsXP as an installed base, but even if its 50/50, that means only half would upgrade to IE9, while the other half would wither be stuck on IE8, or have Chrome/Firefox installed anyway, it's hard to tell.

So while there's lots of reasons to doubt the various figures, if you take what you see at face value (and in the wc3schools link above, you can click on each browser type to see the uptake of each version), then WebGL is now a viable gaming platform. Unless your doing facebook games (in which case your stuck with using WebGL to just smooth things out), you can assume the people coming to play your game WANT to play your game, and that means they either have, or will get the right tools for the job, and that'll be a WebGL compatible browser. Now, I obviously don't mean you should throw everything away and JUST use WebGL, that would be nuts. If the game can easily run in Canvas mode, then switch on WebGL as an option, but get the compatibility as well!

But.... if you have something special, that "works" in WebGL, then you should no longer feel you can't exploit it because IE9 can't do it, it's actually in the minority (no matter WHICH numbers you look at), and you'll still get most of the market being able to play your game - particularly gamers - and not JUST hardcore gamers, but more casual ones that WANT to play games, and aren't just looking.

So finally, a quick word about using WebGL to smooth things out. Well, if you are doing a facebook game, then you'll need to use Canvas, but the problem with that is while it's pretty quick, it's not ballistic. What that means is that it WILL take time to render your scene, so if the PC is busy (however briefly), your game will suffer. That is to say, if your game needs 75% of the time, and all of a sudden a background process needs 40%, then there simply isn't enough time around to keep it smooth.

Enter WebGL: Stage left.

All of a sudden, a game which used to require 75% of the machines time, now only requires (say) 20%, and that means when that pesky background task requires 40% of the time, there's still spare capacity, and your game won't hic-up nearly as much (or at all!), smoothing out the game play experience for the user. So, if it's an easy job to do (as it is in GameMaker:HTML5), switch it on and get the benefits whenever possible.

So there you go...Some things to think about. Now all we need is Microsoft to implement WebGL (or do a DirectX style interface like the WebL one), and we can move past canvas altogether and truly enter a world of smooth browser based gaming!

This post was brought to you by: bored ramblings on a Friday night! :)