New shader, new screenshots

Not got much done this week for family reasons, but the things I did do are rather visual so easy to show off. First I changed the width and height of the game, to 640 x 480. This is not as that will be the final size (though having it non-square does make the gameplay a little more interesting), but more so I could track down any dependencies on the screen size that shouldn't be there. I want to be able to change two numbers and everything updates.

Angle between two 3D vectors

This is something I noticed the other day. Someone had posted a method for finding the angle between two vectors in three dimensions, using the dot product and inverse cosine. But there is better approach, i.e. one that is generally more efficient, is certainly more accurate for some vectors, and can be more informative.

Another Pixel Bender bug

For those interested I've created a test app to demonstrate a Pixel Bender bug (or at least a very strange behaviour) I encountered this week:


http://wonderfl.net/c/dLHH


And started a thread on Adobe's forums about it:


http://forums.adobe.com/thread/1003124

Two more screenshots

I took a bit of a break this week for the bank holiday, but otherwise have kept working on the game. The front end is in, though not working, and I've been adding code to handle starting and restarting the game without it falling over or running out of memory.


Mostly though I've been working on graphics, trying to fix a glitch in the way the gradient shaded circles are drawn. This was a subtle glitch in game but rather more obvious in the front end so it was time to fix it.


I tried creating two new shaders for it but that didn't work as expected, because of some oddity in how Pixel Bender shaders handle alpha in Flash. So I decided used a different approach relying on an existing shader and some BitmapData API calls, especially copyPixels.


It was a subtle glitch, probably only visible to me as I knew it was there, but it's now hopefully fixed. The rendering code becomes a little more complex but it's not code that runs every frame or few frames; at most it runs a few times a game.

Shader bug update

I made another shader today. Nothing that interesting as it's a variation on one I'd done before, but as I added it I uncommented out a line in the game which I must have disabled while trying to fix the shader bug two weeks ago. And the bug re-appeared. Thankfully as I knew it was a shader bug and knew the last change I'd done it was easy to undo, but it was surprising as I thought I'd fixed it in the shader code.

Two more screenshots

Two more screenshots, showing two different levels, in the much improved inverted colour scheme. I still haven't decided how to use this, so am alternating between it and the normal, light lines on a dark background, mode to make sure it works as well and get some idea of how to fit it in. Currently they are the second and fourth levels; early levels which accounts for the simple colour schemes.

Update, new screenshot

I've been quiet on my game for a week (except for discussing a shader I made for it) but I've still been busy, on two main things. One is a graphical overhaul, involving the shader but also a new way of drawing filled rings and a lot of tweaks to make it work, which I finished last week.

Pixel Bender bug

The circular gradient fill shader I wrote yesterday took more time than expected as for a while it would not work: more specifically it worked fine in Pixel Bender Toolkit but not in Flash. And it failed in a particular way: on use it would instantly lock up rather than fail with an error or produce the wrong result.

Circular gradient shader

This is something I started coding today before I realised it wasn't available in the BitmapData APIs: the gradient fill available comes in two varieties, linear and radial. But the latter is always based on the distance from the centre, never the bearing from the centre as I wanted. So I wrote a shader for it, to generate a result like this:

Quaternion rotation shader

After writing yesterday's post I wondered how easy it would be to use the mathematics in a shader. This would be a natural way to extend my cross product shader, replacing the simple product in that with a more general geometric product.

Multiplying two vectors

In mathematics there are a number of ways to multiply two vectors. The most common is the dot product, which works for any two vectors of the same size. In three dimensions there's the cross product, while in two dimensions there's the perp dot product, sort of equivalent to the cross product.

But they all have the weakness that they are not invertible. Given the cross product

and knowing c and another vector it isn't possible to calculate the third vector (c × c = 0, so given a solution all points on a line through this solution parallel to c are also solutions).

Oops

I've been working on the front end, which also means I've been deciding how many levels, what distinguishes them etc. It's very different from Bug Tunnel Defense where every level was designed individually. Here the levels are mostly numbers. But at the same time I've been changing and adding things to make it easier to introduce elements progressively, and make for a more varied experience.

While testing some of these changes I generated the above screenshot, which is a really bad way to start a game (hence the title), but is also more aesthetically pleasing than the usual cluttered mess of the screenshots the game produces. It shows off some elements of the game much more clearly than usual, although they really need to be seen in motion to appreciate.

Shader vs. ActionScript revisited

Last week I created a shader based on the cross product. This was a simple experiment, done mostly as it was very straightforward: the shader code has only three lines of simple vector maths. But since I realised that it should be possible to recreate it using ActionScript, in particular using a ColorMatrixFilter.

Five new screenshots

It's two weeks since I lasted posted any screenshots. Lots of changes since then, most of them graphical. All of the core gameplay is in now, although much needs to be done, not least a front-end.

100th post

According to Blogger I've written ninety-nine posts to date, making this the one-hundredth, a good point to look back and review my progress so far. All of the lists are in date order. These are based on the tags but not exactly so, and there's some overlap with some posts linked more than once, so they don't add up to ninety-nine.

3-channel Game of Life shader

Following on from yesterday's post I decided to act on my own suggestion and make a 3-channel version of the Game of Life shader. The result is here on Wonderfl and embedded below, with the full shader code as a comment at the end of the source on Wonderfl.

Game of Life shader

This is another simple and quick shader, this time done to see how easy it would be to implement Conway's Game of Life after seeing the same logic implemented using filters. It's an ideal fit for shaders not only as the code that runs on each pixel is identical but also as the 'game' is essentially a graphics algorithm. Turned out to be every straightforward, taking only an hour to write, test and deploy here at Wonderfl.

Practical optimisation

While browsing on Wonderfl to see how my cross product shader was doing I came across someone else's code, the evocatively named "forked from: flash on 2012-3-23". Running it I noticed it was slow: it was not doing much but got slower and used more CPU as it ran. So I decided to look into it.

Cross product shader

This is something I did to try out the mathematical functions in Pixel Bender's shader language. I also wanted to work out how to upload an image to Wonderfl, and upload another more interesting shader example to there. Seeing how its turned out I can't imagine using in game though with a bit of work it could produce some interesting effects which might be useful.

Radial gradient fill

I first tried using gradient fills (via the beginGradientFill method of the Graphics class) in Bug Tunnel Defense. I wanted to use them for shading along the tunnels but could never get them to work, and eventually did it the long way by drawing a series of differently coloured rectangles. The problem was the createGradientBox Matrix function, which no matter what I passed to it would never return the right matrix for a linear fill.