1. Good point, and something I hadn’t considered. Though, do you mean the line “tree.x = tree.x + (2 * treeBreadth)” rather than “treeContainer.x = (275 – car.x) * 1/5)”?

I guess the simplest way to get around this would be to use the treeContainer’s x-position as the base point that you mentioned, then, yes, add on some multiple of the car’s position. Nice solution.

2. Great idea! I do like to repeat myself in tutorials in order to hammer certain points home, but you’re right, this could become a great re-usable system. Perhaps you could pass the distance (from the camera), x-pos, and then a list of sprites and their corresponding breadths to the function, so that you could make a tiled background instead of just repeating the same sprite.

Cheers for your comment

Yeah, I guess it is lengthy… the final code isn’t that long though, it’s the explanation more than anything.

It’s up to you whether you make the pictures first or the symbols first — it doesn’t matter as long as you end up with some symbols that have images inside them.

Really enjoyed the tutorial. Top-class intro to a very cool old-skool technique. It’s amazing how simple this technique is and yet how effective and uber it looks. Using Flash’s built-in support for animation you can do wondrous things with this.

Just a couple of things I noticed:

1. Adding fractional numbers continuously in the way used above (i.e. treeContainer.x = (275 – car.x) * 1/5) will eventually result in floating point precision errors that could lead to “cracks” appearing. This will only happen under specific circumstances. The easiest one to prove off the top of my head would be if this system was used in a game where the player could move back & forward at will with the car. Over time discrepancies would build up in the numbers due to accumulated floating point inaccuracies being multiplied against yet more floats!

The solution to this is to use the base position of objects and then compute a TOTAL offset from the origin of the container. I won’t go into too much detail here, but suffice to say that you would need to store a “base” x & y pos for each parallax object and then add the car’s position as a large offset, multiplied by the parallax factor (1/5 in this example). This would prevent floating point inaccuracies from piling up (multiply is particularly demonic for this type of bug)

2. The code used to determine whether objects need to be “moved” across could easily have been turned into a function taking the “breadth”, x pos and sprite and re-used. The code would have been a lot shorter and easier to understand. However I understand that you are not trying to create the greatest parallax system EVA so that is perfectly fine and the way you have introduced the concept will allow users who read the tutorial to most likely reach the same conclusion and optimize it themselves.

All up, very good work, I enjoyed the tutorial and now I’m going to mess around with this stuff for a game of my own