Hxaria, Infinite Terrain [HaXe, WebGL,dat.GUI]

So I have been working on my “Terraria like Terrain” 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.

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

<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 ]

&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="http://mikecann.co.uk/wp-content/uploads/2011/11/tm.png"><img class="alignnone size-full wp-image-1795" title="tm" src="http://mikecann.co.uk/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="http://mikecann.co.uk/wp-content/uploads/2011/11/tilescompressed.png"><img class="alignnone size-full wp-image-1803" title="tilescompressed" src="http://mikecann.co.uk/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:

1
<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 ]

&nbsp;

And the Fragment Shader:

1
<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>

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:

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:

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

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:

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: http://mikecann.co.uk/projects/hxaria/02/
(Click and drag to move the camera about)

I have also uploaded a quick video too:

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

Next up, lighting!

New Blog Host & Face-lift


Just a quick post to say I have finally moved away from my old hosting on WebFusion and now im on the cheaper (and hopefully) more reliable hosting by STRATO.

Its the first time I have had hosting on a windows machine and I must say I really like it. I feel much more at home on a windows machine, I know where everything is and im more familiar in a graphical OS. I had a couple of permissions problems related to uploading new images on wordpress but a quick Google turned up this post:

http://wordpress.org/support/topic/weird-permissions-with-iis7-and-uploaded-images

Apparently WordPress sticks new uploads in the c:windowstemp directory, before it moves them to the usual wp-content folder, so you have to ensure that temporary folder has the correct permissions for IIS_IUSRS too else it wont work correctly when the file is moved to the content folder.

You may also notice that I have decided to give the blog a little face-lift too with a new theme. I decided this time to go for a paid theme, as they aren’t that expensive (compared to hosting costs) and the quality and customization with paid themes are go much better than their free counterparts. I found it on the excellent themeforest site, the theme is called PixelPower.

Anyways if you find any broken links or anything off with the site then let me know!

Hxaria, Terraria like terrain in HaXe and WebGL

I woke up the other day thinking about Terraria. No idea why as I haven’t played it in ages, but its the type of game I really enjoy so it must have snuck into my dreams during the night.

Anyways, it got my thinking if it would be possible to make something similar to it in the browser using WebGL. For those not aware of Terraria, it looks something like this:

To produce the above you need several layers of tilemaps (background, water, foreground etc) that can potentially change every single frame (due to lighting environment effects etc). To do that at 1680×1050 at 16×16 per tile with only one layer changing each frame will be 6800 tile draws per frame.

Having calculated that I got thinking about the best way to render lots of tiles.

My first thought was to render each tile as a separate quad. That would certainty work, however it would mean that for each tile I would need 4 vertices, times that by say 4 layers that’s 108,800 vertices. Its not a massive massive amount but sizable enough for me to wonder if there was a more efficient way.

My next thought was that I could share vertices by using vertex indices in a triangle-strip, that way at best each tile will only require just over one vertex per tile then arrange them in a lattice so that the vertices are shard between tiles:

This would then only require about 27,200 vertices which is really nice. I was hover having difficulties imagining how I would reference each tile individually in the shader so I could apply texture and color transformations and started wondering if another technique might work..

Having recently done some work with Point Sprite Particles I knew that the GPU was really good at rendering Point Sprites. So I thought to myself, why not just make each tile a point sprite. That way I could then represent each tile as a vertex then I could pass custom properties such as texture and color to the shader as vertex buffer attributes. Doing it this way means that you only need as many vertices as there are visible tiles (about 27,200 for 4 layers) and I can reference each tile individually in the attribute buffer.

So armed with the theory I set to work bashing out some code. Having worked with raw WebGL in haXe on my last few experiments I decided I didnt want to go through all that pain again just for the sake of a little more performance, so I decided to give Three.js another go in HaXe. Thankfully this time I was treading a known path so I could learn from existing threejs point-sprite particle samples. The bulk of the custom particle system logic I took from this rather excellent sample:

(http://alteredqualia.com/three/examples/webgl_custom_attributes_particles.html)

So once I had the project setup it took me no time at all to bash out a sample that showed that I could easily have 27k+ tiles changing size and color each frame:

http://mikecann.co.uk/projects/Hxaria/01/index.html

Pretty aint it?

What you are looking at is 40,000 point sprites changing to a random colour and size every frame, well above the 27k needed. As part of my testing I found that it can actually handle a lot more (hundreds of thousands) of individually updating tiles!

Im planning to continue work on this sample, my next step is to get each particle using a different tile type and changing each frame.

I have uploaded the source to github for your perousal: https://github.com/mikecann/Hxaria

Enjoy!