Naked on Pluto: Starting work on a “live world” projection

Following on from the VIDA win, we need to work hard on Naked on Pluto’s gallery installation presence. Although we now have the news website style front page, we need to take the game externalisation to another level, and one of the things required is a realtime projection of the game world. This represents the unfiltered behind-the-scenes view of the game as seen by the bots as they attempt to keep track of what is going on. Technically we decided to do this work using HTML5 canvas, in keeping with the web based themes of the game it needs to work on a browser, which has the added bonus of making gallery setup quite simple.

My first approach was to write a scheme bricks representation for Javascript objects, and see how bits of the game looked if rendered in this way.

This is part of the ArrivalLobby, and all the internal information is present with no explanations, which is great, but it results in very large images. The next thing was to try filtering the objects to remove most of this information:

function node_filter()
{
    this.filter=function(obj)
    {
        return {objects:obj.objects.map(function(object) {
            return object.name;
        })};
    }
}

This code provides a single method for filtering locations in the game – it simply returns an object consisting of a list of names of things found at that location. These filters can be easily changed over time, to include different information or process it in different ways. Rendered with the same code as before, this makes the location diagrams much smaller:

Add a few more locations, put them together in a circular formation (the projection will be onto the floor space in the gallery), add some bezier curves to indicate paths between locations and it looks like this:

There is also some relatively complex jiggery-pokery to detect when bots have moved from one location to another and animate them. The moving bots display more detail including what they are wearing and who has ‘liked’ them. In this image you can see the AdverBot004 moving to the HelpDesk, and the HyperClock and GreenwichClock on the upper right as they move from the Palace Garden.

PS2 vu1 rendering

Some more work on upcycling second hand PS2’s into cheap fluxus machines. The next step is to embrace the vector units – strange little processors for doing things with points lines and colours extremely fast.

This is quite a daunting task for various reasons, not only can you run floating point and integer calculations in parallel, the VU’s also have instruction pipelining where a calculation can take a number of instructions to finish. The advantage of this is that you can interleave work that you are doing while you wait for things to complete, and make extremely fast programs – but it takes some time to get your head around.

Luckily it’s made a whole lot easier by a free software tool called OpenVCL. This lets you write fairly straight forward assembler and it at least makes sure it should run correctly by spacing it out for you – future versions may also start optimising the code automatically.

This is my first very basic renderer, which simply applies the world->screen transform to each vertex in an object. It’s job is to load data put in it’s memory by the CPU, process and send it to the “graphics synthesizer” to draw the gouraud shaded triangles. It’s not only much faster than doing the same job on the CPU, but it leaves it free for other processing (such as running a Scheme interpreter).

        .syntax new
        .name vu1_unlit        
        .vu
        .init_vf_all
        .init_vi_all
        --enter
        --endenter
        ; load the matrix row by row
        lq      world_screen_row0, 0(vi00)
        lq      world_screen_row1, 1(vi00)
        lq      world_screen_row2, 2(vi00)
        lq      world_screen_row3, 3(vi00)
        ; load the params and set the addresses for
        ; the giftag and vertex data
        lq      params, 4(vi00)
        iaddiu  giftag_addr, vi00, 5
        iaddiu  vertex_data, vi00, 6
        ; move the vertex count to an integer 
        ; register so we can loop over it
        mtir    vertex_index, params[x]
vertex_loop:
        ; load the colour (just increments vertex_data)
        lqi     colour, (vertex_data++)
        ; load vertex position
        lq      vertex, 0(vertex_data)
        ; apply the transformation
        mul     acc, world_screen_row0, vertex[x]
        madd    acc, world_screen_row1, vertex[y]
        madd    acc, world_screen_row2, vertex[z]
        madd    vertex, world_screen_row3, vertex[w]
        div     q, vf00[w], vertex[w]
        mul.xyz vertex, vertex, q
        ; convert to fixed point
        ftoi4   vertex, vertex
        ; overwrite the old vertex with the transformed one
        sqi     vertex, (vertex_data++)
        ; decrement and loop
        iaddi   vertex_index, vertex_index, -1
        ibne    vertex_index, vi00, vertex_loop
        ; send to gs
        xgkick  giftag_addr
        --exit
        --endexit

Wilderness in html5 canvas

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

    Impasto

    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.

    Voxels in fluxus

    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 30x30x30 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: