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?

## Wednesday, 29 February 2012

## Tuesday, 28 February 2012

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

## Monday, 27 February 2012

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

fSin = Math.sin(fAngle);

fCos = Math.cos(fAngle);

can be done more efficiently.

## Friday, 24 February 2012

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

## Thursday, 23 February 2012

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

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.

## Wednesday, 22 February 2012

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

## Tuesday, 21 February 2012

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

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:

## Monday, 20 February 2012

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

## Friday, 17 February 2012

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

## Thursday, 16 February 2012

### 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?

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?

## Wednesday, 15 February 2012

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

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.

## Tuesday, 14 February 2012

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

## Monday, 13 February 2012

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

## Friday, 10 February 2012

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

## Wednesday, 8 February 2012

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

## Tuesday, 7 February 2012

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

## Monday, 6 February 2012

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

## Friday, 3 February 2012

### 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.## Thursday, 2 February 2012

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

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.## Wednesday, 1 February 2012

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

Subscribe to:
Posts (Atom)