So I have been working on my "[Terraria like Terrain](/posts/hxaria-terraria-like-terrain-in-haxe-and-webgl/)" project "Hxaria" again.



Following on from the last post, I have now made it so that each particle can have its texture changed. This completes the functionality required to render each tile as a point sprite, as talked about in my[ previous post](/posts/hxaria-terraria-like-terrain-in-haxe-and-webgl/).

The way it works is that the entire world is recorded in a 2x2 array Tilemap. This 2x2 array holds a single Tile object for every single tile in the world:

[code lang="actionscript3" lines="normal"]

<pre>class Tile
{
public var x : Int;
public var y : Int;
public var type : Int;

    public function new(x:Int, y:Int, type:Int) { this.x = x; this.y = y; this.type = type; }

}</pre>

[/code ]

&amp;nbsp;

When the TileRenderer needs to render it asks this Tilemap for a Tile that represents that screen coordinate, the Tilemap then offsets the position due to the camera movement and returns a tile. So it looks something like:

<a href="/wp-content/uploads/2011/11/tm.png"><img class="alignnone size-full wp-image-1795" title="tm" src="/wp-content/uploads/2011/11/tm.png" alt="" width="600" height="357" /></a>

The tile type is then passed to the shader in attribute buffers per point sprite / tile along with all the tiles which are stored on a single texture:

<a href="/wp-content/uploads/2011/11/tilescompressed.png"><img class="alignnone size-full wp-image-1803" title="tilescompressed" src="/wp-content/uploads/2011/11/tilescompressed.png" alt="" width="256" height="352" /></a>

The shader then performs the neccessary calculations to work out what the UV coordinate in the texture. The Vertex Shader:

[code lang="glsl" lines="normal"]

<pre>uniform float amplitude;
uniform float tileSize;
uniform float texTilesWide;
uniform float texTilesHigh;
uniform float invTexTilesWide;
uniform float invTexTilesHigh;

attribute float size;
attribute vec3 customColor;
attribute float tileType;

varying vec3 vColor;
varying vec2 vTilePos;

void main()
{
vColor = customColor;

    float t = floor(tileType/texTilesWide);
    vTilePos = vec2(tileType-(t*texTilesWide), t); // +(.5/tileSize)

    gl_PointSize = size;
    gl_Position = projectionMatrix * modelViewMatrix * vec4( position, 1.0 );

}</pre>

[/code ]

&amp;nbsp;

And the Fragment Shader:

[code lang="glsl" lines="normal"]

<pre>uniform vec3 color;
uniform sampler2D texture;
uniform float invTexTilesWide;
uniform float invTexTilesHigh;

varying vec3 vColor;
varying vec2 vTilePos;

void main()
{
vec2 uv = vec2( gl_PointCoord.x*invTexTilesWide + invTexTilesWide*vTilePos.x, gl_PointCoord.y*invTexTilesHigh + invTexTilesHigh*vTilePos.y);

    gl_FragColor = texture2D( texture, uv );

}</pre>

[/code]

So it works in a way very much like a raster engine. You only have to render as many particles as the screen can contain.

If the screen area moves beyond the extent of the Tilemap then more tiles are randomly generated:

[![](/wp-content/uploads/2011/11/22222.png "22222")](/wp-content/uploads/2011/11/22222.png)

The new tiles are randomly selected from 4 different types, Dirt, Gold, Diamonds and Rock. I have added some controls to the demo that allow you to tweak these values to demonstrate the random tile generation:

[![](/wp-content/uploads/2011/11/Shot_041.png "Shot_04")](/wp-content/uploads/2011/11/Shot_041.png)

The UI may look familiar to people that have seen any experiments anyone who has worked with Three.js before, its the very popular [dat.GUI](https://code.google.com/p/dat-gui/). Its a really simple library written in javascript for creating controls that can be used to tweak experiments, perfect for me!

To get dat.GUI to work with haxe, I used the awesome [Extern feature of HaXe](https://www.google.co.uk/url?sa=t&rct=j&q=haxe%20externs&source=web&cd=1&ved=0CBwQFjAA&url=http%3A%2F%2Fhaxe.org%2Fdoc%2Fjs%2Fexterns&ei=Gu_QTvK8IYP4sgbo15TzDA&usg=AFQjCNEQvrXVfGjjQNO-yHhZ6HRTKlcmYw). This means that all I have to do is provide a stub interface to dat.GUI rather than a full implementation in haXe. This is great as it allows me to rapidly begin to use the library but also have the type safety of HaXe. It didnt take long to stub out the bits of the library I needed in an extern:

[code lang="actionscript3" lines="normal"][/code]

package dat;

/\*\*

- ...
- @author Mike Cann
  \*/

extern class GUI
{

    public function new(options:Dynamic) : Void;
    public function add(options:Dynamic, name:String) : GUI;
    public function name(value:String) : GUI;
    public function min(value:Float) : GUI;
    public function max(value:Float) : GUI;
    public function step(value:Float) : GUI;
    public function onFinishChange(f:Void -> Void) : GUI;
    public function listen() : GUI;

}

[/code ]

Then I used it like:

[code lang="actionscript3"][/code]

package ;
import dat.GUI;

/\*\*

- ...
- @author
  \*/

class GUIManager
{
public var goldChance : Float;
public var rockChance : Float;
public var diamondsChance : Float;
public var mapWidth : Int;
public var mapHeight : Int;

    private var gui : GUI;
    private var game : Game;

    public function new(game:Game)
    {
    	this.game = game;

    	gui = new GUI( { height : 5 * 32 - 1 } );

    	goldChance = game.tilemap.goldSpawnChance;
    	rockChance = game.tilemap.rockSpawnChance;
    	diamondsChance = game.tilemap.diamondsSpawnChance;
    	game.tilemap.mapResized = onTilemapResized;
    	mapWidth = 0;
    	mapHeight = 0;

    	gui.add(this, 'goldChance').name("Gold").min(0).max(1).step(0.001).onFinishChange(function() { game.tilemap.goldSpawnChance = goldChance; } );
    	gui.add(this, 'rockChance').name("Rock").min(0).max(1).step(0.001).onFinishChange(function() { game.tilemap.rockSpawnChance = rockChance; } );
    	gui.add(this, 'diamondsChance').name("Diamond").min(0).max(1).step(0.001).onFinishChange(function() { game.tilemap.diamondsSpawnChance = diamondsChance; } );
    	gui.add(this, 'mapWidth').listen();
    	gui.add(this, 'mapHeight').listen();
    }

    private function onTilemapResized(mapW:Int, mapH:Int):Void
    {
    	mapWidth = mapW;
    	mapHeight = mapH;
    }

}

[/code ]

Simples!

Anyways you can check the final result out on this page: [/projects/hxaria/02/
](/projects/hxaria/02/)(Click and drag to move the camera about)

I have also uploaded a quick video too:

<iframe width="650" height="471" src="https://www.youtube.com/embed/Hw1bntVoNmU?hd=1" frameborder="0" allowfullscreen></iframe>

I have also uploaded the source again to my github page: [https://github.com/mikecann/Hxaria](https://github.com/mikecann/Hxaria)
(I have also created a tag, incase the source changes in the future)

Next up, lighting!

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](/posts/5000000-chrome-crawlers-why-not-haxe-webgl/). The intention from the start was to replicate some of my [very early work](/posts/xnagpuparticles-1000000-dynamic-particles/) (from 2007) on state preserving particle systems in WebGL.

**Before I go any further, you can check it out in action here:
\*\***[/projects/HaxeWebGLParticles/](/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](/posts/5000000-chrome-crawlers-why-not-haxe-webgl/)), where the position for each particle is calculated each frame based on a fixed algorithm.

A [fairly reccent addition](https://code.google.com/p/angleproject/issues/detail?id=95) 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](/posts/xnagpuparticles-1000000-dynamic-particles/). 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](/posts/5000000-chrome-crawlers-why-not-haxe-webgl/). 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](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.

Following on from my previous experiments into the world of [haXe and HTML5](/posts/more-html5-haxe-speed-tests/) 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](/posts/chrome-crawler-haxe-three-js-webgl-and-2d-sprites/) 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](/posts/xnagpuparticles-1000000-dynamic-particles/) 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:

<iframe width="100%" height="400" src="https://www.youtube.com/embed/KhIT9yNEb8g" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

You can play with it here: [/projects/HTML5SpeedTests/HaXeWebGL/bin/](/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 1x1 you can render a very large (5million) points at interactive framerates (18fps):

[![](/wp-content/uploads/2011/08/000000000000002.jpg "000000000000002")](/wp-content/uploads/2011/08/000000000000002.jpg)

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](https://github.com/mrdoob/three.js/issues/293) on how large you can make them currently it differs between graphics cards and browsers, a safe minimum is 64x64 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:

[![](/wp-content/uploads/2011/08/Shot_07.png "Shot_07")](/wp-content/uploads/2011/08/Shot_07.png)

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:

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

```

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:

[/projects/HTML5SpeedTests/HTML5SpeedTests_2.zip](/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.

[![](/wp-content/uploads/2010/12/Shot_0031.png "Shot_003")](/wp-content/uploads/2010/12/Shot_0031.png)

Just thought I would share this little thing I was introduced to by a friend.



[https://grantkot.com/MPM/Liquid.html](https://grantkot.com/MPM/Liquid.html)

Its a liquid physics simulator written in Java.

Apparently its creator, Grant Kot has been playing around with particles for some time. Theres more of his work on youtube, here is one:

<iframe width="100%" height="400" src="https://www.youtube.com/embed/BIQRhOFkvQY" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

Pretty!

Edit: Didnt realise but this is the same guy that did Polluted Planet that I covered almost 3 years ago -> [/posts/polluted-planet/](/posts/polluted-planet/) thats some awesome particle based dedication right there, I think I need to buy him a beer ;)

[![](/wp-content/uploads/2010/08/ScreenHunter_01-Aug.-31-14.04.jpg "ScreenHunter_01 Aug. 31 14.04")](/wp-content/uploads/2010/08/ScreenHunter_01-Aug.-31-14.04.jpg)

So I have [written about Mr Joa 'The Flash God' Ebert before](/posts/funk-ioc-a-new-dependency-injection-framework/). 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](https://blog.joa-ebert.com/2010/08/31/so-i-recorded-a-new-video/) shows:

<iframe width="100%" height="400" src="https://www.youtube.com/embed/atzHF7YGp6Y" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

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_.

[![](/wp-content/uploads/2010/08/ScreenHunter_01-Aug.-22-09.36.jpg "ScreenHunter_01 Aug. 22 09.36")](/wp-content/uploads/2010/08/ScreenHunter_01-Aug.-22-09.36.jpg)

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:

<object style="width: 600px; height: 500px;" classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" width="600" height="500" codebase="https://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0"><param name="src" value="https://www.mikecann.blog/DumpingGround/ld/18/04/LudumDare18.swf" /><embed style="width: 600px; height: 500px;" type="application/x-shockwave-flash" width="600" height="500" src="https://www.mikecann.blog/DumpingGround/ld/18/04/LudumDare18.swf"></embed></object>

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.

[![](/wp-content/uploads/2010/08/ScreenHunter_01-Aug.-21-19.31.jpg "ScreenHunter_01 Aug. 21 19.31")](/wp-content/uploads/2010/08/ScreenHunter_01-Aug.-21-19.31.jpg)

Okay its been about 6 hours since my last update, and I have been working pretty much solid apart from an hour lunchbreak when I went for a wander into town.



Ive made quite abit of progress with the core bits of the engine including the physics particle systems and the destructible terrain.

Dont believe me? Take a look for yourself:

<object style="width: 600px; height: 500px;" classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" width="600" height="500" codebase="https://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0"><param name="src" value="https://www.mikecann.blog/DumpingGround/ld/18/02/LudumDare18.swf" /><embed style="width: 600px; height: 500px;" type="application/x-shockwave-flash" width="600" height="500" src="https://www.mikecann.blog/DumpingGround/ld/18/02/LudumDare18.swf"></embed></object>

Theres still no game really, just a pretty tech demo. Im hoping the gameplay will come next :)

Im going to have abit of a break now, get some food wind down a little then its going to be a loooooong night ahead for me!

It was the massive annual Assembly gathering last week. Traditionally its a place for the [demo scene](https://scene.org) to gather and present their demos and to hack out new ones.



For those not in the know the demo scene or "scene" is where a team of people come together and compete to make a music video. Except that they arent videos in the traditional sense as its all generated using code and runs in realtime. This means that you have to be super efficient with your code. Some of the competitions are "64k" or even "4k" competitions which means that the whole demo must fit in 64kb or 4kb! The music is also produced by the groups and often excellent.

I have been checking out some of the demos produced by the teams this year and they are simply stunning. Every year they get better and better.

This one from CNCD and Fairlight particularly caught my eye as it has massive numbers of particles and a stunning soundtrack kinda reminiscent of glitchy Radiohead. Therefore I thought it essential I share it here.

Enjoy:

<iframe width="100%" height="400" src="https://www.youtube.com/embed/vQ2iQQvofCE" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

Oh while im at it check out this one from last year:

<iframe width="100%" height="400" src="https://www.youtube.com/embed/ezltebzdgjI" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

If you are interested in more demos from assembly you can get them all here: [https://scene.org/newfiles.php?dayint=7&amp;dir=/parties/2010/assembly10/](https://scene.org/newfiles.php?dayint=7&dir=/parties/2010/assembly10/)

Oh I have also posted about the demoscene before here: [/posts/andromeda-software-development-lifeforce-2007/](/posts/andromeda-software-development-lifeforce-2007/)

Saw this [post on Gizmodo](https://gizmodo.com/5591613/incredible-physics-engine-yields-some-seriously-jaw+dropping-dirt) and thought I would share on my blog as I think its incredible.



Its a a physics engine called Lagoa and its by Thiago Costa, check it out:

<object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" width="640" height="360" codebase="https://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0"><param name="allowfullscreen" value="true" /><param name="allowscriptaccess" value="always" /><param name="src" value="https://vimeo.com/moogaloop.swf?clip_id=13457383&amp;server=vimeo.com&amp;show_title=1&amp;show_byline=1&amp;show_portrait=0&amp;color=00ADEF&amp;fullscreen=1" /><embed type="application/x-shockwave-flash" width="640" height="360" src="https://vimeo.com/moogaloop.swf?clip_id=13457383&amp;server=vimeo.com&amp;show_title=1&amp;show_byline=1&amp;show_portrait=0&amp;color=00ADEF&amp;fullscreen=1" allowscriptaccess="always" allowfullscreen="true"></embed></object>

[Lagoa Multiphysics 1.0 - Teaser](https://vimeo.com/13457383) from [Thiago Costa](https://vimeo.com/thiagocosta) on [Vimeo](https://vimeo.com).

[![ScreenHunter_02 Jan. 10 20.13](/wp-content/uploads/2010/01/ScreenHunter_02-Jan.-10-20.13.jpg "ScreenHunter_02 Jan. 10 20.13")](/wp-content/uploads/2010/01/ScreenHunter_02-Jan.-10-20.13.jpg)

I have immense respect for some of the flash developers out there and Quasimondo is one of them. He has just released a little particle related experiment.

Whenever I see these kind of things it inspires me to bash out my own little experiments.

I wont talk too much about it but check it out on this lab page: [https://incubator.quasimondo.com/flash/galactose.php](https://incubator.quasimondo.com/flash/galactose.php)