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.

More shaders

I wrote two new Shaders today. One is for a screen that's not in the game yet, which the Shader will be a fundamental part of. As the Shader is rather complex I wanted to write it first to see if what I wanted to do was possible. It seems to work, so now I need to write the code for that screen.


The second is much simpler. It does edge detection on the layer I added yesterday, to highlight the boundary of the region indicated. The Shader code is very straightforward and it took much less time than either of the other Shaders I've done for this game.

Screenshots

Catching up today after spending much of yesterday performing my civic duty, and spent some time adding a new graphical layer that slots between existing layers in just the right way. I had to re-work a few things to get it right, but the result not only looks better and helps a lot in the gameplay but is a little more efficient to draw.

Review: Triple Town

Triple Town by Spry Fox started out on the Kindle, but I first noticed it on Facebook and subsequently on Google+, one of the first game on that platform. Most recently it has been released for iOS devices. 

Linked lists + screenshots

I moved some of my data structures over to linked lists today, in preparation for adding more functionality and gameplay. I was once fairly sceptical of their applicability in Flash but I've been persuaded around by the performance work I was doing a few months ago. In particular the overhead of accessing array (Vector or Array types) members is non-trivial, comparable to other function calls. I may do some performance tests to confirm this but I'm pretty sure this is an optimal solution for what I'm doing.

Ball-ball collisions

In this post I discussed how to handle collisions in general, at least when one of the objects is a ball for collision purposes. My intention was to follow it up with an example but I never got around to it. Well now I have, and it shows how to turn the theory in that post into practice.

Trig performance test

I have asserted that trigonometry is slow in a number of posts. The whole point of a post on Trig-free rotation blending is that trigonometry is so slow that it should be avoided. My reasons for this are my experiences on previous platforms, where trigonometric functions are often tens or hundreds of times slower than arithmetic operations.



But such assumptions often prove false on new platforms. Flash in particular does not have the highly optimised arithmetic operations of modern CPUs, so rather than trigonometry being especially slow it could be that maths in Flash is slow enough that there's no need to avoid Flash. This is certainly worth knowing, as there's no point avoiding particular functions if they are as fast as other ways of doing the same thing.

New screenshot

A lot more circles in this one, and more colours, or at least it's making much more use of them. The game's not fundamentally different to last time, it's mostly a lot of subtle changes.

Update: another screenshot, below the fold, after another small change

More on Flex

Just a short update, but it's on an important point as I discovered something to make my life a whole lot easier.

Screenshots

New screenshots; three of them this time so they're below the fold

Shader vs. ActionScript

It was pointed out to me that the shader I used as an example last week did something that could be done with ActionScript, in particular a ColorMatrixFilter. This was something I was aware of, as I described how to use a ColorMatrixFilter in exactly that way a month ago in this post. But it's interesting to compare them to see the difference.

Screenshot and update

Busy today, so so just enough time to do another screenshot. This includes the text I wrote about yesterday (though I've rewritten that code to make it more flexible), the lives indicators, and some more gameplay elements that are too complex to describe.

It's still is missing some major elements before it's really a playable game, though those in a way are the easiest bits to put in. Then lots of tweaking and improving, not least of the graphics which I've been adding to but haven't looks at changing.

Text revisited

Three months ago I described the class BTDText I created for Bug Tunnel Defense to replace the built-in TextField class. I used it again today to add some progress text to my game, and learned a couple of things in the process.

A simple shader

I wrote this shader a few days ago, but didn't want to write about it until I was able to demonstrate it working, which I did in yesterday's post. Now that's done I can describe the shader it used in more detail. It's a very simple shader, that desaturates whatever it's applied to on a scale between 0 (no effect) and 1 (greyscale).


I wrote it for this blog, but it's likely I will use it or one based on it in the future. It could be used at the end of a game or when a game is paused to indicate the game has stopped while still showing gameplay or the game state, or could be used as part of a fade-out between levels.

Shader from string

I wanted to write a bit more about Flash shaders, but was constrained by being unable to show my workings: I can post screenshots and could even host a working demonstration but I could not upload a shader to Wonderfl (images can be uploaded but not other data). Nor could I easily load one from elsewhere because of Flash's security model: I would need to load it from a server where I could edit the Crossdomain.xml file.


But a search of Wonderfl and a further web search turned up the solution: the data can be embedded in the source as a Base64 string.

New screenshot, Flex update

Another screenshot, with the newest additions called at the moment 'snakes'. As always none of this is final, with the colours easily changed by changing a single line. It doesn't show any actual gameplay.

Drawing a pie chart

This is something I wrote for the game I'm working on but removed a few days ago as I went in a different direction in the design. As the code is fairly self-contained I thought it might be of interest.

Another screenshot

This is a screenshot of my latest code with the Shader in effect. It's a bit of a cheat actually as I had to slow it down 10x so I could take a screenshot. Which is a way of saying a static screenshot doesn't really give an idea of how it looks in action, at 60fps with everything moving.

 Also the game now uses no art assets: everything is procedurally generated. I don't rule out using art in the final game but for now it's quicker and easier to work in code where I change a few numbers to completely change the look and feel of things.

Flash isn't slow

Flash has a reputation for being slow, but one I think that is largely undeserved. It is not as fast as native code but is not that far behind, and compares favourably with other interpreted cross-platform environments.


But why does it have a reputation for poor performance? I think there are a number of reasons, all of which are pitfalls developers can fall into when making Flash games. Avoid these and it becomes much easier to make games which perform well across a wide range of platforms. So what are these pitfalls?

Shaders

I tried writing a shader today (Monday). Shaders have been part of Flash for a while, but as far as I know hardly any games use them. This is a shame as they can do things that are impossible in ActionScript, often with very little programming.

Half-angle formulae

The half-angle formulae are formulae from trigonometry with a variety of uses. One important use is for optimising trigonometric calculations, of the sort often used in 2D geometry. In particular calculations of the form


fSin = Math.sin(fAngle);
fCos = Math.cos(fAngle);


can be done more efficiently.

Another screenshot

Busy again, so just another screenshot. This maybe gives a better sense of some of the things in yesterday's screen shot. Lots of fun figuring out how to do [dozens of] smooth, multicoloured particle trails without killing a 60fps frame rate.

New screenshot

Another screenshot from the work in progress, currently called "Rings".

One distinguishing feature so far is there's very little art: it's almost all procedural, and what art there is may be dropped eventually. The lack of colour is temporary: because it's all code I can add colour by just changing a line. The black and white is mostly for contrast so I can see what's going on.

Collision theory

My last two posts have shown how to do basic collisions without explaining why they work. In many cases it's not important to know why, and a lot can be done with just bouncing balls off walls and the floor. But the theory shows where the results come from, how they fit together and most important how to use it to solve other collision problems.

More ball-wall collisions

The observant among you might have noticed that the ball in my last test app was only bouncing off the floor not the wall. I've fixed this in a new version of the app, which improves on the previous version in another significant way.


It now bounces off both both walls as well as the floor, using essentially the same code, which is compact enough to reproduce in full:

ball-wall collisions

Collisions between a ball (in two or three dimensions) are perhaps the simplest to code. This is one consequence of the mathematical simplicity of ball physics, as discussed in my last post. As long as certain assumptions are made the code for such collisions is only a couple of very simple lines.

Why circles (and spheres)?

One interesting question is: "Why are circles (and by extension spheres) better for games?". I don't just mean computer games but a wide variety of games and sports use balls: marbles, billards, tennis, pétanque and football. Still more use circles: curling, shuffleboard and air-hockey.

On framerate

In recent discussions I've been involved in I've noticed that developers have a lot of ideas about the best frame rate for a game. Unfortunately many of those ideas are wrong, often for very straightforward reasons. As I've been thinking about this again for the game I've started I thought it worth a post on this.


The main point is there are only two frame rates you should consider: 30fps and 60fps. And 90% or 95% of the time you should choose 30fps. Why?

Flex

I got Flex working yesterday. It was something I tried with Bug Tunnel Defense but never got working; the best I managed was it building without errors but without finishing. I.e. once I'd fixed all the compiler errors the compiler would take forever. This was impossible to diagnose, I could not share the project with anyone else to see if they had any insights, so I had to give up.


This time I tried it with a relatively small and new project, that consists of only ten mostly small source files and one graphic asset. I eventually got it working, but it took much more time than it should have.

Quadratic curve through three points

Flash has a couple of curve drawing functions in the Graphics class, curveTo and cubicCurveTo, but they can be difficult to use as they use control points. Control points are points off the curve which the curve tends towards. They are intuitive to use when editing in a graphics app but less useful in code when a curve through a point is needed.

drawCircle is slow

This is something I discovered at the weekend. I already knew that the drawCircle function of the Graphics class is slow, slow enough that you don't want to be using it to draw too many circles at once at runtime. Instead render them into a BitmapData using BitmapData.draw wherever possible.

BitmapData recolouring

There are at least four straightforward ways to recolour BitmapData. They all work by modifying the data directly, so the resulting BitmapData can be used as any other. Because of this they have no rendering cost, and so can be used fairly freely without impacting runtime performance.

Why BitmapData?

One topic I've seen discussed a few times online is what the best format for graphics in Flash is. And the answer is almost always the Bitmap and BitmapData classes. The overriding reason for this is performance, but it is worth looking at the alternatives to consider why this might be.

More on copyPixels

Yesterday I mentioned that the BitmapData function copyPixels can be used to combine image data and alpha data from two different sources. This function has a number of uses, in addition to adding transparency to images that don't have any.

JPEG data with alpha

The GIF and PNG graphics formats have alpha channels but JPEG does not. There may be times though when it's useful to load JPEG data with an alpha channel. Here's how.

Drawing a bitmap

This is something I've found very useful for both prototyping and making final art. The idea is to use vector drawing commands to create a bitmap, or more precisely a BitmapData. This can then be instanced hundreds or even thousands of time very cheaply, much more so than using drawing commands.

Circle-circle intersection

Intersecting circles can be done in a number ways. One approach is algebraic: take the formulae for the circles and solve them to obtain values for the x and y coordinates. Another approach derives the line that joins the points of intersection then intersects that line with the circle.

But the method I use is more direct, and I think mathematically more robust. By direct I mean it calculates the result directly and does not depend on intermediate results, such as calculating the line or one of x and y first. As such there's much less chance the order of calculation will affect the result.

Perp dot product

I have used the perp dot product in a couple of posts but not explained it. It has a page at Mathworld but no Wikipedia article so I should perhaps explain it here.



The perp dot product is a product between two vectors in two-dimensions, and is obtained by taking the dot product of one vector with the perpendicular of the other. The perpendicular is simply a vector at right angles to the vector it is based on with the same magnitude. It is obtained by rotating through 90° or π/2 radians, or by multiplying by the complex number i in the complex plane.

Lines

One problem that's been touched on in previous posts is how to deal with straight lines. In particular how to represent them efficiently and accurately. Making the wrong choice is not that disastrous but it can cause problems in some situations.

Angle between two vectors

Another use for inverse trigonometric functions is finding the angle between two vectors. Again there is more than one way to do it, and again the most straightforward approach is often not the best.

Inverse trigonometry

The functions asin, acos and atan are together the three principal inverse trigonometric functions; that is they are the inverse of the sine, cosine and tangent functions, the commonest trigonometric functions that describe all the ratios of the sides of a right-angled triangle.

New screenshot

A screenshot from something I'm working on. Yes, it has circles in it.

And a tip, if you're developing on a Mac. Turn on Web Sharing (under Sharing in System Preferences), then set the path Flash builds the SWF and HTML to something like "../../Sites/xxx", where xxx is the file name of each. Then you can access it in the browser using the IP address of your machine and the HTML file name, as above. No need to upload it to a separate site for network testing. It's still a local file so will work locally in the debugger or standalone Flash player just fine.

Circle-line intersection

Yesterday's method for determining whether a circle crosses a line can also be used to find where the crossing points are. The approach uses the distance calculated in the hitLine function with some simple circle geometry.

Circle-line incidence

Problems involving circles and lines can be straightforward, if handled the right way. The main reason for this is the fact that the distance from a circle to a line is just the distance from its centre to the line minus the radius. I.e. if a circle radius 100 touches a line the circle's centre must be 100 units from the line.

More on circles

Yesterday I described circle-point and circle-circle intersection tests. These are very straightforward to do, and it is interesting to look at why this is so, as it can help solve other problems with circles.

Circles

Circles are used for many things in 2D games. Not only for things that are inherently circular (wheels, balls) but for many effects and to describe many situations. For example the range of a gun is often a circle, or at least circular.

Fast path member access

I noted on Wednesday that accessing members by repeatedly doing a lookup in a Vector is slower than doing that lookup once. But it was slower even than I expected. The code was doing the lookup eight times more than necessary, but was over twelve times slower (i.e. it took over twelve times as long). So I forked the code and re-wrote the tests to find out what was going on. The results of this are especially interesting.

Notes on testing

A couple of notes on the performance tests I've been doing.

Dereferencing array members

The title refers to code like this


iSum += aData[iIndex];


Looking up in an Array (or Vector) requires the code to find the address of the object or value requested then retrieve whatever's at that address. It might also check whether it exists, and whether it is in range (and if not whether it should grow the Array or Vector to accomodate it).

Accessing members by name

One sometimes misunderstood feature of ActionScript is that as well as accessing members of a class directly and using accessors it's possible to do so using the name of the member, passed as a String to the class. Misunderstood as there is a right way to use this and a wrong way to use this. And the wrong way is incredibly slow, so much so it should be avoided at all times.

More on angles

In a recent post I asserted that angles are rarely needed for game mathematics. There are a few exceptions but far fewer than many people realise. But it's easy to doubt this assertion. What is there theory behind it? Is there a way to check when angles can be avoided? Not only can both questions be answered but the answer to them is the same.

setter perfomance test, conclusions

So far the accessor tests I've been doing have only been of getters, or more generally of accessor functions for retrieving members from classes. The obvious question is whether setters have the same performance penalty. The answer is yes, they do.

getters and built-in classes

Following on from yesterday's post, an obvious question is whether getters and setters are used for built in classes. The answer is yes, but not for all of them, and it is important to know which.


I won't post code for this, as the code is straightforward but lengthy, and is easily inspected at wonderfl where I've created this program to demonstrate it. It defines two classes, one derived from Vector3D, one derived from Bitmap. The purpose of each is to compare accessing the built-in members of the classes with members added by the derived classes.

getters and setters are evil

ActionScript has a feature which I have not seen in any other programming language: getters and setters. These are special member functions which when used can be called like direct member access. In some ways this is like operator overloading in C++, except C++ does not allow the '.' operator to be overridden. Having seen how this works in ActionScript it seems like one innovation other languages should not copy.

Accessors are slow

This is the most important performance optimisation I learned writing ActionScript. It provides a significant performance boost, and in class-based code arises more often than almost all other optimisations. It also flies in the face of what I learned as a C++ programmer.


In C++ accessors are key to good programming practice. Their main use is to hide the implementation from the interface of a class, so the class can be updated without code using it having to be re-written. They make it easy to add code to record accesses for e.g. ref-counting or debugging purposes. Making members private and providing accessors for them documents the code as it indicates which members are safe to access directly which are not because they e.g. have side effects.

Variable speed rotation with complex numbers

I wrote only last week that complex numbers are best for mostly fixed or uniform speed rotations. This is true in general, but there are ways to use complex numbers when the speed varies, as long as it varies in a straightforward way. In particular if the speed increases linearly, so with uniform angular acceleration, it can be modelled with complex numbers.

Angles

Recent posts have focussed on how to avoid angles when programming. The reason for this is simple: angles are slow to work with. In particular the trigonometric functions used to work with angles are expensive compared to arithmetic operations. There are times though when it is impossible to avoid angles.

Accuracy

I came across a few issues related to accuracy in my ballistics app, both expected and unexpected. As these have wider application than ballistics simulations and are interesting in their own right I thought them worth their own post.

Varying the rotation speed

One objection to rotating using complex numbers instead of angles is that it works best with a fixed rotation speed. This is correct: if the speed needs to vary from frame to frame then the 'delta' needs to be recalculated each frame, and it may be easier to just use the angle to calculate the rotation each time.

But as long as the speed is mostly fixed complex numbers work well. If for example the rotation speed changes in steps, but between these is constant, then the 'delta' needs only be recalculated at these steps.

Trig-free rotation blending

As mentioned yesterday complex numbers can be used to do rotations in two dimensions, by just multiplying by a suitable (complex) value. One particular application is rotation blending or interpolation, where the direction of something is blended smoothly over time. An example would be aiming a gun, where having it move over time to aim is more realistic and interesting.


Normally this would be done by blending angles, so an angle is updated in steps from one direction to another. But this is expensive as two trigonometric calculations are required each frame to update the direction or to transform whatever is being rotated. It is quicker to use complex numbers and avoid trigonometry altogether, except at the start.

Complex numbers

Complex numbers are a much under-appreciated topic in mathematics, or at least that's how it seems to me looking back on them. Very often they are introduced almost as a mathematical exercise, as a way of solving mathematical problems such as quadratics which are otherwise insoluble. But once this is done all it gives is an impossible solution.


For example in my ballistics application complex number solutions to the quadratic formula in it (given by a negative discriminant) arise when the target is unreachable. And many applications of complex numbers seem like this. Except the more you study mathematics and physics the more useful they become, arising in diverse areas such as dynamics, electro-magnetism, and quantum mechanics.