Artificial – Argon [Tech, House, Progressive]

First part in a two part mix, see “Iridium” for part 2.

What I have tried to do with these two mixes is present two sorts of music that are really floating my boat at the moment. This first part is a much lighter, techhyer, houseyer affair than its counterpart, hence the noble gas Argon.

Argon by Artificial on Mixcloud

01. Nathan Fake – The Sky Was Pink (James Holden Remix)
02. Petter – Everyday Balloon
03. Delavari & Rouzbeh – LaLaLa (Ozgur Can Remix)
04. Who’s Who – Klack (Inpetto Remix)
05. Matt Lange – Bad Year Blimp
06. Gui Boratto – No Turning Back
07. Second Left – Traffic Lights
08. Butch – Amelie
09. Deadmau5 & Kaskade – I Remember

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:

[codesyntax lang=”glsl”]

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;
}

[/codesyntax]

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.

From Dust

Its not often these days that I post about games I have been playing, usually I leave that sort of stuff in the realms of Twitter or social networks.

For “From Dust” however ill make an exception. It’s also not often these days that I see some tech in a game and wonder to myself “how the hell did they do that?” or just “wow I have never seen that done before”. From Dust made me think both those things this week.

From Dust is a god game that follows in the heels of other god games such as Populus and Black and White. The reason why it has attracted my attention so much is the incredible tech that the game employs.

Check out this tech-demo / trailer for the game:

When I watched that earlier in the week I was amazed but skeptical that everything shown was actually how it was in game. After downloading and playing it on xbox this week however I can confirm that everything shown in the above video is in game and more. Not only that its actually fun!

The water flows from the top of the mountains realistically, over time it erodes the landscape to form rivers. Water pressure builds up need harder rock causing bends in the river that threaten your villages. You have to think ahead about how to divert a river one way but making sure not to flood an area downstream. More often than not it takes several tries to get it right.

Lava is great. Several missions have volcanoes that you must be swift to tame else they can easily threaten your villages. The great this however is that there are many ways you can choose to solve a particular problem.

You could just manually suck up all the lava and drop it somewhere else, a somewhat temporary solution. You could try to build a channel for the lava to follow however lava has a habit of melting through any channels you build. You could use one of the spells your villagers to supply to aid you. You could divert the course of a river to cool the lava as it nears your village. You could use a “water tree” to cool the oncoming flow of magma. The choice is yours.

I have been pondering over the tech and thinking how they managed to get such a complex liquid simulation to run in realtime. Infact, how they managed to get several complex liquid simulations to run in realtime. The sand, the water, the lava and the rock all act as liquids with different properties, however they all interact with each other in different ways. Not only is the liquid tech impressive, the vegetation propagation and the fire mechanics are all seamless, and from what I could tell not a single frame was dropped.

It must be a GPU based liquid simulation (particularly as the xbox CPU is weak), however I didn’t think they were good enough to do something like this. Perhaps they are using some optimized Smooth Particle Hydrodynamics such as that employed by Fairlight from the scene: http://directtovideo.wordpress.com/2011/05/03/numb-res/

Anyways, the game is available for download right now on xbox or if you are like me and are pc-inclined then it should be available on PC from the 17th of August.