When the code reaches the first boundary (c1 == 255.1, c2 == -0.1), both c1dir and c2dir are negated, but c1 and c2 retain the values 255.1 and -0.1 which will be passed to fill() on the next call to draw(). Similarly for each colour variable heading in the other direction.

Including “c1 = c1 + c1dir;” in the first conditional will repeat the boundary value, so a nice crisp bounce is produced with “c1 = c1 + 2 * c1dir;” or equivalent code.

I might also suggest using variable names other than c1dir and c2dir since they are rates of change, not merely (or perhaps not even) “directions”.

A similar problem exists in the “bouncing ball” (Example 5-6) code, but is arguably less “critical” (the ball doesn’t “bounce” until the centre passes the edge anyway). The bouncing ball problem is one that I still find tricky – for example, a bouncing ball under “gravity” that eventually comes to rest, and that looks good, is not so easy!