For some time now I have been working with WebGL and have developed a sort of love/hate relationship with it. I love the ability to instantly target millions of people with GPU accelerated code without any plugins or barriers (excluding the targets that dont support it). However as a developer, writing code that takes advantage of WebGL kinda sucks.

Procedural Based

First off is the way you have to structure your GL calls. For example take a look at the following generic bit of webGL harvested from the net:

Source code

texture = gl.createTexture();
   gl.activeTexture(gl.TEXTURE0);
   gl.bindTexture(gl.TEXTURE_2D, texture);
   gl.pixelStorei(gl.UNPACK_ALIGNMENT, 1);
   gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGB, 64, 64, 0,
     gl.RGB, gl.FLOAT, new Float32Array(pix));
   gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_MIN_FILTER, gl.NEAREST);
   gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_MAG_FILTER, gl.NEAREST);
 
   texture1 = gl.createTexture();
   gl.activeTexture(gl.TEXTURE1);
   gl.bindTexture(gl.TEXTURE_2D, texture1);
   gl.pixelStorei(gl.UNPACK_ALIGNMENT, 1);
   gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGB, 64, 64, 0,
     gl.RGB, gl.FLOAT, new Float32Array(pix1));
   gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_MIN_FILTER, gl.NEAREST);
   gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_MAG_FILTER, gl.NEAREST);
 
   FBO = gl.createFramebuffer();
   gl.bindFramebuffer(gl.FRAMEBUFFER, FBO);
   gl.framebufferTexture2D(gl.FRAMEBUFFER, gl.COLOR_ATTACHMENT0,
       gl.TEXTURE_2D, texture, 0);
   FBO1 = gl.createFramebuffer();
   gl.bindFramebuffer(gl.FRAMEBUFFER, FBO1);
   gl.framebufferTexture2D(gl.FRAMEBUFFER, gl.COLOR_ATTACHMENT0,
       gl.TEXTURE_2D, texture1, 0);
   if( gl.checkFramebufferStatus(gl.FRAMEBUFFER) != gl.FRAMEBUFFER_COMPLETE)
     alert(err + "FLOAT as the color attachment to an FBO");

All it does is create a couple of textures, setting their starting values and creates two frame buffers for rendering to. Its just it looks complicated and difficult to understand.

GL works on a procedural basis, so you tell GL that you are about to work on something by calling a function like “bindTexture()” then on the next line you perform an operation on it such as “pixelStorei()”. Now this may have made perfect sense back when we were writing everything in C which is procedural anyway however this is Javascript (or haXe in my case) which is an Object based language, code like this is difficult to understand and follow.

The procedural nature of WebGL means you have to be much more careful about unsetting things you have previously set. For example if you bind a texture to perform some operation, you must then remember to unbind it else you could inadvertently cause operations to be applied to it on subsequent calls elsewhere in your codebase. It this ‘hidden state’ that has caused me alot of headaches when developing my samples.

The principal behind WebGL was to provide a very low-level library which other developers can build upon to build more complex and abstracted libraries. And there are numerous libraries out there. I personally have tried several of them including the very popular three.js. Three.js is great for doing common things like loading models and putting quads on the screen. I however encountered a problem with render targets which I struggled with for days before I discovered that you had to set “needsUpdate” to true on your texture before using it. In the end I decided to drop three.js beacuse of another issue I encountered and instead attempt to reduce my complications by working with webGL directly.

Flash11′s Stage3D has the same philosophy as webGL, to provide a low level API for other developers to build libraries upon. The thing is Flash11′s low-level API makes more sense and is more readable. For example the following to me is much more readable than its webGL equivalent:

Source code

texture = c.createTexture(logo.width, logo.height, Context3DTextureFormat.BGRA, false);
texture.uploadFromBitmapData(logo);

The Stage3D API also uses language like “upload” to let you know when you are transferring data to the GPU, for a new comer to GL you have no clue when things are going to the GPU. Its small things like this that reduce the “WTF?” factor when tackling the tricky world of hardware-accelerated 3D programming.

Cross-domain textures

This one cropped up around July time this year and took me ages to work out what was going on. For some inexplicable reason (or so it seemed) my code one day stopped working. When I looked for demo code online it all worked fine, however when I downloaded it and run it locally it also didnt work. I was getting errors like the following:

Uncaught Error: SECURITY_ERR: DOM Exception 18
Uncaught Error: SECURITY_ERR: DOM Exception 18
Uncaught Error: SECURITY_ERR: DOM Exception 18
Uncaught Error: SECURITY_ERR: DOM Exception 18
Uncaught Error: SECURITY_ERR: DOM Exception 18 

I was so baffled that I posted about it on the HaXe mailing list asking for help, thinking it was something I was doing wrong with HaXe. It turns out (after much wall-head-butting) this was a change that they brought into Chrome 13 and Firefox 5 to combat a security problem when using shaders that use textures from a different domain to the one running the code:

http://blog.chromium.org/2011/07/using-cross-domain-images-in-webgl-and.html

Now I have no problem with cross-domain issues, im used to this from Flash where we have the same sort of setPixel() restrictions on cross-domain BitmapData’s. The thing is, it appears that this restriction applies when running code locally too. So If you are developing something on your local machine and trying to access a texture from disk it throws the same security errors because the browser thinks you are reaching across domains to access the image.

At the time the only way to get around this was to create your own webserver that you run on localhost to server up the files. So to do that I had to download python so I could run a simple localhost commandline webserver from my bin directory. What an effort! There may be easier ways these days to solve it but at the time it really frustrated me and formed yet another barrier to developing webGL.

No Error Messages

This is by far the most annoying thing about developing for WebGL. So many times I have been trying to write something that I know SHOULD work but for some reason it doesn’t. I dont get any error messages, nothing. It makes writing something from scratch neigh on impossible.

In my last post “GPU State Preserving Particle Systems with WebGL & HaXe” I started with an idea. I attempted to code it ‘bottom-up’. That is start with nothing and then add more code until I reached what I wanted. Unfortunately having no error messages in WebGL makes this very difficult indeed. I would spend some time writing something really simple, like trying to get a textured quad to render on the screen only to find I get nothing. I double check my camera matrices my vertex and texture buffers, my shader and still nothing. Eventually I found that I hadn’t bound something first before trying to operate on it *sigh*

In the end I found the best way to get anywhere is to go from the other direction, a ‘top-down’ method. Start with something kind of simmilar to what you want then cut bits out one line at a time until you get what you want. Its extremely time consuming and frustrating, but its less frustrating than going from the other way.

There are tools out there that help with debugging what is going wrong. Namely the WebGL Inspector (see above) is intended to provide gDEBugger / PIX like debugging information about what is going on inside webGL. Its a clever bit of tech, it lets you inspect buffers and traces each gl call, however it suffers from the same underlying problem of having no errors. You setup a buffer incorrectly and what you get is “INVALID_VALUE”. No indication as to which of the values is invalid or what part of the call you messed up on

Googling Doesn’t Help

If you do happen to get an error message (unlikely) or you word your problem in a sufficiently succinct and googaleble way you will then run into the next big problem with WebGL; theres very few people using it. Now I know I am likely to be flamed for that comment, but it just seems that way to me. Whenever I tried to google my problem, or google for what I was trying to achieve (because working bottom-up doesnt work) there would be a very sparse smattering of relevant posts. Usually the results are forum posts and are OpenGL not WebGL related and are from 5-10 years ago.

But..

Now having just ranted on for several hundred words about why it sucks im going to finish it off by saying that im going to continue to develop for WebGL using haXe regardless. Why? Well I just like making pretty things that run fast and GPGPU programming appeals to me for some unknown (likely sadistic) reason.

The second day of try{harder} was dedicated to a single topic; test driven development (TDD).

The group was split into pairs and given the task of using TDD to write a solver for the game of life in AS3. After an hour we then threw away everything we had done, swapped partners and repeated the process.

This was extremely valuable for me as I had never written a unit test before. Seeing how different people tackled the same problem was fascinating and informative.

After repeating the process three times Stray asked if I was interested in teaming up with another attendee of the conference Alec McEachran to investigate unit testing in haXe. It was a great idea as it meant we both could investigate how unit testing worked in haXe and it would give me another code example for my talk the following day.

After a brief search we decided on Mike Stead’s MassiveUnit for testing as the testing syntax looked similar to FlexUnit and it contained a toolchain for running the tests on multiple platforms.

An example of a test we wrote is:

Source code

package ;
import massive.munit.Assert;
import Grid;
 
/**
 * ...
 * @author MikeC & Alec McEachran
 */
 
class GridTest
{
	public var grid : Grid;
 
	@Before
	public function before():Void
	{
		grid = new Grid(3, 3);
	}
 
	@After
	public function after():Void
	{
		grid = null;
	}
 
	@Test
	public function initiallyThereAreNoLiveNeighbors():Void
	{
		var liveNeighbors = grid.getLiveNeighbors(1, 1);
		Assert.isTrue(liveNeighbors == 0);
	}
 
	@Test
	public function liveNeighborCountIsAccurate():Void
	{
		grid.set(0, 0, true);
		grid.set(1, 0, true);
		grid.set(2, 1, true);
 
		var liveNeighbors = grid.getLiveNeighbors(1, 1);
		Assert.isTrue(liveNeighbors == 3);
	}
 
}

It should look fairly familiar to anyone who has used FlexUnit before. The metatags @Before @After and @Test perform in exactly the same way as they do in FlexUnit. Another benefit of using munit over the built in testing framework in haXe is that you are given a tool to run tests on all platforms simultaneously:

Source code

haxelib run munit test test.hxml

When executed you get something that looks like the following:

Which presents a nice graphical representation of the tests run and which failed (if any).

Once built and tested we decided to give the code a simple visual representation. We wanted to show off the ability for haXe to target multiple platforms. To do this we decided to go with NME which I had been experimenting around with recently.

NME is a library and tool chain for haXe designed to allow the developer to use the flash API on multiple platforms. They achieve this by writing platform targeted version of the flash API. So what this means is code such as the following:

Source code

package ;
import flash.display.Bitmap;
import flash.display.BitmapData;
import flash.display.MovieClip;
import flash.geom.Rectangle;
 
/**
 * ...
 * @author MikeC & Alec McEachran
 */
 
class Render
{
 
	private var _cellSize : Int;
	private var _renderTarget : BitmapData;
	private var _rect:Rectangle;
 
	public function new(container:MovieClip, cols:Int, rows:Int, cellSize:Int)
	{
		_cellSize = cellSize;
		_renderTarget = new BitmapData(cols * cellSize, rows * cellSize, false);
		container.addChild(new Bitmap(_renderTarget));
 
		_rect = new Rectangle(0, 0, _cellSize, _cellSize);
	}
 
	public inline function lock():Void
	{
		_renderTarget.lock();
		_renderTarget.fillRect(_renderTarget.rect, 0xff0000);
	}
 
	public inline function renderCell(x:Int, y:Int, isLive:Bool):Void
	{
		if (isLive)
		{
			_rect.x = x * _cellSize;
			_rect.y = y * _cellSize;
			_renderTarget.fillRect(_rect, 0);
		}
	}
 
	public inline function unlock():Void
	{
		_renderTarget.unlock();
	}
 
}

Will compile down to flash, c++ and Javascript! NME also includes packaging abilities for webos, android and ios. So with a few scripted command lines you can target most app marketplaces:

Source code

haxelib run nme test YourProject.nmml flash
haxelib run nme update YourProject.nmml ios
haxelib run nme test YourProject.nmml webos
haxelib run nme test YourProject.nmml android
haxelib run nme test YourProject.nmml cpp
haxelib run nme test YourProject.nmml cpp -64

What it means for this project is we could very quickly get a view for our game of life running in flash, JS and native desktop.

To show just how easy it is I made the following video:

You can see the HTML5 build here: http://mikecann.co.uk/projects/gameoflife/Export/html5/bin/

And the flash build here: http://mikecann.co.uk/projects/gameoflife/Export/flash/bin/MyApplication.swf

I have uploaded the source for the project here: http://mikecann.co.uk/projects/gameoflife/gameoflife.zip

In this post I talk about the challenge of device discovery and networking in the Inputtie app.

Zero Configure Networking

I knew I wanted Inputtie to be as simple to get running as simply starting it up. For this to happen Inputtie would need to discover all other devices on the network also running Inputtie. So how to do this?

Well, as it happened I had been reading at the time about Apple’s Bonjour which was designed to do just what I needed. It is a combination of a multi-cast and DNS lookup service that allows it to detect other Bonjour capable devices on the network. Sounds perfect.

So I got to work on implementing their Java API. After many trials and tribulations I eventually had it working.. kinda. It was detecting other devices sure, but every now and then it would sporadically disconnect from the network. I couldn’t for the life of me work out why. I posted on forums and even tried to read the reams of source to see what was going on but alas to no avail.

After much deliberation I decided to look for another solution to the problem of Zero Conf. networking. Next up were a whole host of other attempts. I tried JmDNS which is was supposedly very similar to Bonjour. I also experimented with JGroups. I had limited success with all of them and in the end only really succeeded in wasting several months worth of development time.

The Solution

In the end the solution (and the one currently employed in Inputtie) was the simplest. After months of messing around with these libraries I had learnt quite abit about how they performed their magic. At the heart of it they either used multi-cast or broadcasting to announce a device on a network. Broadcasting can be thought of as a sort of sonar pulse. The broadcasting computer sends a message on a specific IP address then another device listens for the message and proceeds to open a Socket for a more private form of communication. From Wikipedia:

A broadcast address is a logical address at which all devices connected to a multiple-access communications network are enabled to receive datagrams. A message sent to a broadcast address is typically received by all network-attached hosts, rather than by a specific host.

I decided that if these libraries could use broadcasting for discovery then so could I and if I wrote it myself I could keep it simple. So I set to work coding an example in Java. In no time at all I had it running and surprisingly it worked! Sure it wasnt as robust as the established libraries, it didn’t handle devices disconnecting from the network, different network subnets or IPv6 but it was simple and at least it worked!

Broadcasting in Adobe AIR

As I mentioned in a previous post Inputtie went through many re-writes during development from its original form in Java through C++, C Sharp and finally Adobe AIR. With the latest (it was still in beta when I started development) version of Adobe AIR 2.0 several new APIs were made available for use, one of them being new classes designed specifically for peer to peer (P2P) networking. With these new APIs I believed I should be able to implement network broadcasting much in the same was I was doing in Java. Unfortunately however it seemed that Adobe was restricting the use of broadcast to their new P2P service Cirrus.

There was however another crucial API released with AIR 2.0; the NativeProcess API. With this a developer is able to easily execute and communicate with a program written in another language. What this meant for Inputtie was that I could write the user interface in AIR and then use NativeProcess to call Java code that would perform actions not available in AIR, such as Broadcasting. (incidentally it also is a great way to do multi-threading in Air )

So the current solution in Inputtie is to use NativeProcess from AIR to communicate with a small headless (no user-interface) Java process that does the broadcasting and listening for broadcasts. Once the Java process detects an incoming broadcast it passes the information back to AIR.

EDIT: If anyone is interested in seeing the source to my previous (failed) attempt just drop me a comment or an email and I would be happy to share.

1 Keyboard, 1 Mouse, 1 PC, 2 Laptops, 1 Netbook, 4 Operating Systems.

All systems are go! Almost ready for takeoff!

So overall I placed #21 which is just outside the top 20. Not bad for a first time entry but I thought I would of done better considering some of the game ranked higher than me but oh well.

I actually game second in one category.. Community? Not entirely sure how I managed that but oh well

I think I may have received the most number of votes out of any of the games, it certaintly seems like a lot take a look:

Ratings

So my overall scores in the various categories were:

Innovation: 3.17
Fun: 3.45
Theme: 3.57
Graphics: 4.09
Audio: 2.64
Humor: 3.20
Overall: 3.43
Community: 4.38

The winners in each category are as follows:

Innovation: Switchbreak 4.21
Fun: Invicticide 4.17
Theme: TomBom 4.36
Graphics: NialM 4.63
Audio: Greasemonkey 4.07
Humor: Deps 4.06
Overall: Invicticide 4.07
Community: HybridMind 4.52

Oh well, I enjoyed the competition. Im planning on polishing the game a little more now the competition is over then im going to release it to the wider world.

So I have written about Mr Joa ‘The Flash God’ Ebert before. He is well known throughout the Flash community for his incredible coding skills, particularly his work on low-level SWF optimisation.

His latest project is called JITB and its nothing short of stunning as this video taken from his blog shows:

Basically he has gone and written a Flash Player in Java. What this means is that you get all those awesome speed benefits and optimisations that the Java team has worked hard for years and years to implement but you can write it all in a language already familiar and sexy, AS3! The result? You get about a 30x speedup! (disclaimer: a micro-benchmark taken from Joa’s blog)

This is all great news and very exciting. I cant wait to see a custom browser plugin using this flash player, or even having Pixel Bender shaders running on the hardware *me drools in anticipation*.

The timelapse was produced using 2300 ish screenshots, one taken every 60 seconds by Chronolapse.

Enjoy:

You can play the game here: http://mikecann.co.uk/ludum-dare/ludum-dare-hour-40-complete/#thegame

Okay well its not quite complete, the waves of enemies could do with some more work but I have my mum coming up from London to visit me in 30 mins so im gonna call it quits here.

So, finally it has a name, I have called it “48 Hours Later” Its not technically true as I have only had 40 hours to do it, but oh well!

Overall im pretty happy with my first Ludum Dare entry, im very tired right now and have a banging headache, but thats all part of the fun right?

So onto the game. First some shots:

Okay so if you have been following waaaay back my original intention was to make a game with the same sort of art style as World of Goo but with the game mechanics of Boom Stick. I think I have stayed pretty true to that original idea.

Basically you fight against waves of enemies that float across the screen. There are currently only 10 waves, I would have liked more and with more variety but oh well

The theme of the competition was “Enemies as Weapons”. I have incorporated that theme by having the enemies drop giblets when they die. You then have a certain amount of time to pick up those giblets and fire them back at the enemies. Enemies as weapons!

So as a disclaimer: im sure the game has many bugs and things, I have run out of time to do much in the way of testing and optimising. If you find any bugs however drop a comment I would love to hear about them as I plan to release this to a few flash portals, so would like to get those bugs fixed

Anyways enough jibber jabber. A few more shots then the game is below:

EDIT: I have now made a youtube gameplay video and timelapse of development, check em here.

Tools Used:
Adobe Photoshop CS5
Adobe Flash Builder 4
Adobe Flash CS5
SFXR
Chronolapse

Well its been quite a while since my last progress report. I have mostly been sleeping (well 4 hours of it anyways).

So progress is coming along nicely STILL no gameplay tho :S

So far you can shoot and destroy the enemies and then collect thier giblets before they become part of the terrain. The idea is that you can then shoot those giblets back at the enemies. Take alook if you are interested:

Oh I just noticed I left some debug sliders on there I was using to try and hone the bloom levels. Have a play with them if you want.

Right. Gameplay.

Okay, im starting to get pretty tired. Its not very late (midnight) but I think the lack of sleep last night is catching up with me. Im gonna get a few hours kip now then back up early to start again I think.

As for progress. I have a basic enemy type in, it doesnt do much except bleed, and it doesnt look too good (I really cant draw!) but oh well.

As before I have done a build that you can “play”:

So the next task for me when I wake up is to add some sort of scoring mechanism and ofcourse to add the ability to use the “Enemies as Weapons”