Wilderness in html5 canvas

2010.05.16

My exploration of web programming continues, this is a rewrite of the wilderness game world from haxe/flash into javascript and html5 canvas. There are some plans to make this into something more resembling an actual game, but at the moment it’s serving as a good test as I get to grips with these new fangled bits and pieces.

Leaving out all the hot air about small companies beginning with “A”, here are my thoughts on canvas for making games compared with haxe/flash:

Pros:

  • Javascript is much nicer for me than Haxe due to dynamic typing and it’s comparative closeness to Scheme.
  • Immediate mode for graphics allows you to draw a scene how you want with your own containers. The retained mode MovieClip object in Flash is an annoyance for me. Hopefully similar things happen in web graphics as it did in 3D with the early DirectX retained mode, which was eventually abandoned.
  • I’ve started using Chrome for development – the javascript debugger is one of the best I’ve come across, and the Firefox one is pretty good too. When using haxe/flash I ended up completely relying on print statements.
  • It’s nicer to develop in a normal webpage rather than a plugin.
  • Cons:

  • Canvas is currently much much slower than Flash. It’s quite possible I’m doing something stupid, but the canvas version uses about 40% of my processor where as the flash version is 5-10%.
  • Less built in support for text and user interface items like entry dialogs. There is probably much more missing along these lines, and much that will need to be implemented from scratch. Personally speaking I am not too fond of library frameworks implemented by architecture astronauts, so I can live with this at the moment.
  • Update: While I hope HTML5 is the future, it seems on some counts my optimism was premature, it seems it’s still to reach a point where it’s available for the majority of people – and where it is available, the stability and performance is variable. With this in mind : On flash, software art and freedom

    Categories : flash   games   groworld   rendering

    wind shapes

    2010.03.08

    A simple test filling arbitrary shapes with particles:

    Code here

    Categories : fluxus hacking   rendering

    Impasto

    2010.01.03

    For no particular reason, I thought I’d have a go at writing a raytracer 100% in scheme (it actually started as a port of this which I wrote ages ago). I run it in the mzscheme interpreter for development and then compile it using stalin to render stuff. I’m hoping maybe it can serve as a framework for playing with some more esoteric rendering ideas in the future.

    The code is here and while it’s not good enough for any general use yet, it supports all the usual raytracing stuff, plus obj file import and is partly integrated with this voxels renderer.

    Categories : rendering

    Voxels in fluxus

    2009.11.04

    I’ve rewritten the experimental scheme voxel code into experimental C++ fluxus code, using hardware rendering for the sprite ’splat’ accumulation, which makes it realtime for 30×30x30 grids (27000 voxels).

    The last two are a bunch of concentric spheres with the top left corner carved away by a box.

    Part of the fun of this is figuring out a scene description language for volumetric data, currently you can create solid spheres or cubes, spherical influences from points, add/subtract them from each other, threshold and light them. Here’s a test with a million voxels, which surprisingly still leaves fluxus interactive, if not actually workable for realtime animations:

    And a short movie of spheres carving each other up as they move around:

    Voxelism

    2009.10.09

    One day, when we have flying cars and people live on the moon, there will be no more triangles in computer graphics, only voxels. I somehow ended up spending the whole day today playing with the stalin scheme compiler and writing a small voxel renderer. These fuzzy blobs are the results: