Programming

Recursive, Nuts & Bolts Part 1 – A Typescript Chrome Extension (1 of 3)

screenshot_04

As promised I have decided to write a few blog posts on some of the technology behind my recently release Chrome extension Recursive.

Because there is quite a lot to cover, the discussion is going to be split over three posts. The first part is about the structure of the extension, Typescript and other tools and tech employed. The second will cover the actual recursing / crawling part of the extension. In the final part i’ll talk about how I went about representing, laying out and rendering all the data that the crawling part generates.

With that out the way lets get on with the show..

General Page Layout

When a user open a new tab or browses a new page in Chrome a background script in Recursive inspects the URL you are visiting and so long as it is of type http:// or https:// it will add a small icon to the omni bar:

screenshot_02

Clicking this button opens up a new tab with the Recursive app inside. The app consists of a single HTML document “app.htm” with all of the logic split up into multiple Javascript files which mirror the Typescript files that were used to generate them (more on that below).

Twitter Bootstrap

Recursive is the first project I have had the opportunity to use Twitter’s Bootstrap. Bootstrap takes much of the pain (I tend to suffer from) out of generating a decent looking HTML interface. Because of it ubiquity it can cause a lot of sites to look very samey, for Recursive however I wasn’t interested in spending all that much time making a unique looking interface so the default style suited me just fine.

General Code Structure

There are three main parts of the application; the HTML and its associated controlling logic (jQuery stuff), the crawling logic and the rendering logic. I have attempted to keep the three parts of the application as separate as possible. The reason being that hopefully it will make things easier in the future should I ever wish to swap out one of these features, for example swapping the canvas2d renderer with a 3d one.

Typescript Code Structure

I have already mentioned in a previous post that I took advantage of the new language Typescript from Microsoft to build Recursive. I won’t reiterate the reasons I really like Typescript (I should be paid for my evangelizing :P ), go check out my previous post if you are interested in hearing my thoughts on the language.

The way I have structured things in Recursive is to have a central context / entry point in the form of a file called app.ts. This file lives in the root of the project and I use it as a sort of globals file. I know, I know what you are thinking, “Globals! Mike, you should know better!”. In this instance however I think because Recursive is a standable app inside an extension it is unlikely to conflict with any other JS (supposing the libraries I use dont declare any global variables). Besides I don’t like the alternative that involves using RequireJS or AMD due to all the magic strings and non-type safety involved.

screenshot_03

App.ts also contains references to every other typescript file in the app. This means that when a new TS file is created I only have to add a single reference back to app.ts and all the classes and types contained in the other files will be available (this solution actually feels kind of icky, much in the same way as globals do, but one of the samples on the Typescript homepage uses this ‘driver’ method so I guess its okay!).

One thing you have to remember with this ‘driver’ method is that every time you create a new TS file, you must also manually add the generated JS file to the html page. Also you must insert the JS files in the correct order in the page head else the types won’t be available when the script is loaded. It would be nice if I could just have included app.js in the html page and then have all other .js files automatically added in the correct order for me. This is what RequireJS is supposed to do for you I guess. Another solution would be to use source-maps to map to the original Typescript code (when debugging in chrome) however I had a great difficulty with getting this to work in Chrome so decided to move on.

One important lesson I learnt while working with Typescript on Recursive and with working with JS in general is to try not to fight it too much. Just because you have type safety doesn’t mean you HAVE to make everything type safe all the time, particularly if its going to take you hours to implement it in a type safe way. Just because you can separate all your classes out into separate files doesn’t mean you have to, sometimes it makes more sense and is easier to implement if a few enums or helper classes sit inside the same file.

L-System

Finally, as a little extra I decided to put in a splash screen when you first start up Recursive:

screenshot1

While designing this I was also trying to come up with a logo and name for the app. I was toying with the name Recursive and it got me thinking about fractals and L-Systems. As I am easily distracted I decided to quicky have a go at writing an L-System for the splash screen. It wasn’t hard to implement but tweaking all the parameters turned out to be a lot more fun than I was expecting so I spent most of one Sunday evening just playing with it :P

Finally

Well that’s about it for the first part of my discussion on the internals of Recursive. This post didn’t didn’t contain too many details on what Recursive actually does and how it does it rather it was intended to lay the groundwork for those topics in the next two posts. So stick around for those coming up in the next few days!

3 Weeks of Progress on a Mobile Game

As usual you can have a play with the game in its current form above. (Up to jump, left and right to control the player).

The first new thing to notice are there are now menus, yey! Incredibly poor, made by a toddler, looking menus, but menus nonetheless. My artist and collaborator on this project, Moh, has been away for the last week so the game has had to suffer at the hands of my terrible programmer art. Now that he is back however, he will be whipping the visuals into shape.

Again this week I have had far less time to work on the project that I was hoping for (damn real life). With the little time I have afforded myself, I mostly concentrated on menus, resolutions, DPIs and aspect rations. These topics are the rather unglamorous side of mobile programming but are a necessary part of writing a game for multiple devices.

First a note on my testing environment and devices:

PC (flash) – 1024×683 @ 72 DPI
iPad3 – 2024×1536 @ 264 DPI
iPhone 4 – 960×640 @ 326 DPI
iPhone 3G – 480×320 @ 153 DPI

(I currently don’t have access to an android device but I hope to test on it soon.)

As you can see there is a rather large variation in resolutions and Dots Per square Inch (DPI). There is also two different aspect ratio’s there 4:3 for the iPad and 3:2 for iPhone. The iPhone 3GS is the same aspect ratio but half the resolution as the iPhone 4 and the iPhone 4S is the same aspect and DPI as the iPhone 4. The iPad 2 is half the resolution of the iPad 3 but has the same aspect ratio.

Basically all this equates into a few days of headaches while I try to wrap my brain around how to handle this mess. My solution to this conundrum is set my default target to the iPhone aspect ratio of 3:2 as it is more restrictive in the Y direction than the 4:3 ratio of the iPads. If I can build menus that work in 3:2 then they should look okay (if a little bit more spaced out) in 4:3.

To handle the various resolutions within an aspect ratio I then need to provide various versions of the assets that would roughly take up the same amount of screen space at that resolution. So for example if the screen is 1000px wide for example and the title for a menu is 800px wide when I design it on my PC, I would then need to provide a 1600px wide title image when running on a screen 2000px wide.

So the question is now how to provide these various sizes of my title? Well I could make a PNG for my title 800px wide then when I need one 1600px wide I just scale it up by two. The problem with this as anyone who has played around in Photoshop will know is that you will end up with a blurry up-scaled image. The other solution is to start at the other end with the highest quality 1600px then scale it down when you need one 800px wide, the problem with this is that you are wasting a whole load of memory by supplying and loading an image twice the size of whats required. The third method is to provide a different size for every single resolution required, this is not ideal as it would take alot of time to make all these PNGs and there are a great many device resolutions out there.

Haxe and NME however give me an alternative solution. Using the SWF library I am able to design my menus in Flash then at runtime pull out the vector graphic and scale it to the required size to display on screen. What this means is that I only need supply a single resolution of an asset in flash then it is scaled up as a vector and looks great no matter the resolution.

So to work out the correct size for the various parts of the menus initially I created a few “mock screens” in flash and laid out the various parts in the mocks:

By designing the mocks to 960×640 (3:2) I need only then at runtime divide the screen width by 960 to work out the correct scale for the game. Simples!

Well not quite as simples at that. There were a coupple of issues. Firstly the vector rendering performance of NME on mobile is pretty poor. To get around this problem you must pre-raster your vector to a Bitmap first. This should be fairly normal to anyone having worked with Blitting engines in AS3 before. This step however raised another issue.

I noticed it was taking a long time to raster the background for my menus to a bitmap. I did a few experiments and posted the question on the NME mailing list. It turns out that NME currently doesnt handle Radial gradients too well, also performance is generally poor when building in debug mode on iOS. With both this issues rectified however the performance was alot better. There is still a small lag between different menus when on iOS but its acceptable for now.

There also appears to be another issue regarding TextFields on iOS. It appears as if the text is being cut off half way. I have also posted about this issue on the mailing list and am awaiting a reply. My solution for now is to provide a background behind my text set to alpha 0, this forces the width and hight to be correct:

Well with that boring stuff out of the way onto the changes in the game itself.

As mentioned previously the gameplay changes have been fairly minimal. I have made some small changes to how the player is controlled to make it more fun. You can no longer scale vertical cliffs and jumping has been modified. The largest gameplay change has been to how the player is eased into the game.

After watching people play the game on the iPhone and iPad I noticed that alot of the time people didnt seem to understand how to control the player. They assumed the game worked like one of those “move a ball around a maze” type games. So understandably they kept turning the device on its side in an attempt to make the player “go up”. With the world constantly rotating too, the person was trying to keep the world level, so they kept twisting the device in odd directions to keep it level. This problem is difficult to explain if you haven’t tried it out on a device for yourself.

Once you understand whats going on however (the world is rotating, you tap to jump and tilt to move the player) it all becomes alot more clear and you can play the game normally. So with that in mind I have decided that the first few levels the world will not rotate. I hope this will ease a player into the control system a little better rather than just throwing them at a strange control system in a continually rotating world. Fingers crossed this will do the trick.

So that’s that for this week. This week we hope to get as much of the art work in as possible. Hopefully menu systems, and the various bits of artwork for the stages will all go in this week. In addition I want to get audio and testing on Android in. Alot to cover in very little time!

GPU State Preserving Particle Systems with WebGL & HaXe

Well this is the post I didnt think was going to happen. I have been struggling for weeks with this little bit of tech, ill explain more about why it has been so difficult in another post. For now however, ill just talk about this sample.

So the idea was to build upon what I had been working with previously with my stateless particles systems with WebGL and HaXe. The intention from the start was to replicate some of my very early work (from 2007) on state preserving particle systems in WebGL.

Before I go any further, you can check it out in action here:
http://mikecann.co.uk/projects/HaxeWebGLParticles/ 

First a quick reminder. The difference between a stateless and state-preserving particle simulation is that in the latter we store and update the positions, velocities and other properties of each particle per frame, allowing us to interact and control the simulation. This differs from the stateless particle simulation (detailed in my previous post), where the position for each particle is calculated each frame based on a fixed algorithm.

A fairly reccent addition to WebGL made this possible, namely texture lookups in the vertex shader (aka Vertex Texture Fetch). I wont go over the exact details how this makes state preserving particle systems possible as I have already documented it in my earlier work. A brief explanation is that it allows you to use the fragment shader to perform the updates on particle state stored in textures then use the vertex shader to map those states to a point-sprite vertex buffer.

Basically what this means is that the entire particle simulation can be contained and updated on the GPU, which means no read-back. This allows us to achieve simulations of millions of particles without too much difficulty (depending on GPU ofcourse).

I have uploaded the source for people to perouse at their leisure:
https://github.com/mikecann/HaxeWebGLParticles

As usual it was written using the JS target of HaXe so it should be fairly easy to understand whats going on if you have written any Ecma-script-like-language. Im going to detail this in my next post, but the code isnt the best I have ever written as its a result of a mish-mash of various samples and examples I have found on the web. If anyone has any comments on things that are wrong or could be done better I would be very happy to hear about them.

1 2 3 … 6  Scroll to top