Code

Tinkering With Ash

Last October I was fortunate enough to attend the excellent Try Harder conference for the second time. I have spoken before about how inspirational the event is where every attendant must give a talk on something they are passionate about. One of the talks was by David Wagner’s and was on ‘The Value of Tinkering’ and it inspired me to tinker with TypeScript which led to my Recursive Chrome Extension.

Before I go any further I should mention that there is a Try Harder ‘Level Up’ session taking place in April that is open to new attendees, I thoroughly recommend you check it out!

Following on in the same ‘Tinkering’ vein I have decided to investigate an AS3 library by another Try Harder attendee Richard Lord:

logo

 

What is Ash? Well direct from the Ash Website:

Ash is a high-performance entity system framework for game development.

An entity system is a way to organise the code for a game that is efficient for both code execution and code management. It uses composition rather than inheritance for sharing features between game objects and uses a data-oriented approach to separate the game state from the game logic. This makes it much easier to manage the code and to manage the game state.

Im not going to go into the details too much of why composition over inheritance is a good idea as Richard has already done a much better job than I ever could in these two posts:

If you haven’t got a clue what im talking about when I say Entity or Component I strongly recommend checking out his posts first.

The reason why Ash has piqued my interest is because for the last three years I have been working with Entity-Component systems for games but in a totally different way. The way I have been using and developing started with the Push Button Engine (PBE) method and later expanded out to include Dependency Injection culminating in the Swft Framework.

Ill give one example of why am starting to fall in love with Ash:

In PBE and Swft the components contain data and functions. They can also declare dependencies (via [Inject]) which are automatically fulfilled when a component is added to an Entity. The functions in the component are able to act on their own data, other components and interact with the game as a whole.

One problem with this method is that components are largely tied to their entity and once attached aren’t really free be removed or added. The reason is because other component may have dependencies that depend on that component being part of the Entity. Removing the component will cause the game to crash. This becomes a problem when you want to enable a certain chunk of functionality for a certain time then disable it, what you tend to end up doing is adding the component at Entity creation time then inside of it toggling its behaviour with a boolean.

In Ash components are pure data with the bulk of the functionality being contained within systems. Sure you can have functions in a component but they only act on their own data. There are no hard dependencies between components. What this means is that components are much more free to be added and removed from Entities. So how do component function together then? Well that’s where Systems come in.

Systems are classes that contain the logic that makes up your game. When added to the engine they grab one or many lists of Nodes. A Node simply defines a collection of components that must exist on an Entity. In effect it declares the dependencies that this System needs to operate. What’s neat about this is that this list of nodes is constantly changing as components are added and removed from entities. The Ash Engine manages this all for you so all the system need do is iterate over the linked list of Nodes each frame and execute its logic.

Systems also must not declare dependencies between each other. This rule means you don’t end up with large dependency hierarchies between Systems. This frees up systems to be added and removed from the Engine with no side effects! This is rather remarkable as it lets you do crazy things that you couldn’t normally do when there are many dependencies between systems. For example your game could have a Blitting based rendering system, then halfway through a running the game you could swap that out that System and replace it with a Starling based rendering System!

Thus far I have only spent a limited amount of time tinkering with Ash but I am having a whole lot of fun. I have started work on a little game to experiment around with the framework. At the same time I have been exploring Starling, the hardware accelerated 2D rendering framework built on Stage3D. Thus far I have produced this little map editor:


Click to place a block, shift and click to remove, scroll mouse to change block type and hold control and click to zoom in / out.

Its only a tech demo at the moment and as such hasnt got any game play elements. Im not entirely sure what to turn it into but as a platform for tinkering with Ash its been great.

Its too early to share the code at the moment but if you would like to see how some Ash code looks I strongly recommend you check out Richard’s Asteroids example on GitHub. I was really quite taken aback by how neat and modular the code is. The example is provided in 4 different flavours, one using RobotLegs one with Starling one with SwiftSuspenders and one with no dependencies at all. The fact that the code still works and looks simple in all the examples really demonstrates the versatility of the framework :)

Try { Harder } 2012 Levelup

Last year I was fortunate to be one of the lucky 16 to attend the first try { harder } experimental conference / coder retreat in Nottingham. As mentioned in my blog post at the time it was an incredible 4-day event in which I learnt so much from some of the most talented and experienced people in the flash community.

The event was such a success that not only is it going to run again this year (which I hope very much to attend) but there is also an additional “levelup” conference happening next week. The idea behind the levelup is to provide businesses and freelancers with an intensive 4-day training and motoring session. The mentors are hand picked from the previous try harder members and so represent some of the best in their field.

What’s more Stray, the primary organiser of the event has just announced that Jetbrains the makers of the popular IntelliJ IDEA IDE are going to be sponsoring the event meaning each paying participant will receive a licence to use the IDE!

Interested? Head over to the levelup site and sign up: http://www.tryharder.org.uk/level-up-2012/

 

5,000,000 Chrome Crawlers? Why not [haXe & WebGL]

Following on from my previous experiments into the world of haXe and HTML5 I have been playing around again with trying to get as many 2D sprites on screen as I can.

I started by reading some posts by google on how to render things fast in HTML5, and it got me thinking. Where I was likely going wrong with my HaXe + Three.js experiments was that I was making a separate draw call to WebGL for each and every crawler. Draw calls are expensive and hence I was reaching the draw call bottleneck at just 2000 sprites being rendered at once.

What I needed to do was batch the draw calls together and render them at once. I knew from my work on XNA you could group sprite render calls together quite nicely. So I started off coding up a WebGL equivillant of SpriteBatch from XNA.  I managed to get it kind-of working but as is often the way another thought struck my brain, and I decided to tackle that instead.

My thought was; why not just render everything as 2D point sprites? I remembered from my XNA days you could achieve quite staggering numbers of 2D sprites in DirectX by using point spites.

So after a little bit of fiddling and hacking I managed to get point sprites correctly rendering:

You can play with it here: http://mikecann.co.uk/projects/HTML5SpeedTests/HaXeWebGL/bin/

The great thing about point sprites is that I only use one draw call per frame and the GPU is very good at rendering them. The only bottleneck really is the number of pixels you need to draw. With that in mind if you drop the size of the point sprite down to 1×1 you can render a very large (5million) points at interactive framerates (18fps):

I added a “dont use texture” option just out of interest to see how expensive the texture lookup in the fragment shader was, it didnt seem have much of an effect.

There are a few caveats to using point sprites:

Firstly in WebGL has a limit on how large you can make them currently it differs between graphics cards and browsers, a safe minimum is 64×64 so this means you cant have them and bigger and still want it to work in all situations.

Secondly, and this one is more important I cheated to get the numbers above. In my other experiments with haXe and WebGL I was using the CPU to update the positions of the crawlers each frame, having them bounce off the screen edges. In this point sprites demo however I have the points flowing out of a fountain, the simulation of which is entirely calculated on the GPU. The reason for this I talked about in a paper I wrote for a university project 4 years ago:

If I wasn’t to perform the upates on the GPU but instead just use the CPU to update the crawlers that would mean the javascript (CPU) would need to update 5million crawlers each frame then re-upload the point sprite positions back to the GPU for rendering. This would obviously be a bad idea.

So I kind of cheated. The fountain simulation on the GPU isn’t the same as my other examples. The crawlers don’t bounce off the side of the screen. To make that that happen each crawler needs to somehow preserve its state between frames.

Currently each crawler’s position is calculated in the vertex shader each frame like so:

attribute float maxAge;
attribute float startingAge;
attribute float velX;
attribute float velY;
 
uniform float uTime;
uniform float uPointSize;
 
varying float invAgeRatioSq;
 
void main(void)
{
	float age = mod(uTime+startingAge, maxAge);
	float ageRatio = age / maxAge;
	float invAge = 1.0 - ageRatio;
	invAgeRatioSq = 1.0 - (ageRatio * ageRatio);
 
	gl_Position = vec4((-velX*ageRatio*0.8), (velY*ageRatio)+(-0.4*age*ageRatio)-0.5, 0., 1.);
 
	gl_PointSize = uPointSize;
}

To preserve state between frames I need to use textures to record each crawlers position and velocity, then using Vertex Texture Fetch a vertices position can be calculated.

That however will have to wait for another evening ;)

I have uploaded the source for this project here incase anyone was interested:

http://mikecann.co.uk/projects/HTML5SpeedTests/HTML5SpeedTests_2.zip

I warn you its ugly and uncommented, however it should be enough of a start for anyone looking to do something similar.

1 2 3 4  Scroll to top