Eyecandy

Assembly

I got a few more switches for the fan and the pseudo-random number generator seeder, got them mounted (I still need to mount the pseudo-RNG switch somewhere), and gosome felt glued to the back side of the pegboard. This last part was an attempt to protect the boards somewhat from the outside elements. It should stop small stray debris, small amounts of liquid, and thin metal rods (e.g. screwdrivers) from coming in direct contact with any of the boards or the terminal strips.

I also bought some hanging brackets and started working on a way to secure the pegboard to the wall. Currently, I'm planning on securing (Liquid Nailz) several pieces of wood on the back side and just using velcro to secure the pegboard. Some larger pieces of wood and a few holes cut into the pegboard should be sufficient to mount the hanging brackets, in case I want to bring it up off the floor at all.

Coding

This is the real reason for the post, however.
Behold, lots of eyecandy!

4.1MB QT	4.0MB QT
4.0MB QT	4.0MB QT

I'm sorry about the short videos; my camera can only take up to 16 seconds at a time.

These videos show the 6 still images I've designed (from this directory), as well as the single generator I've got coded up (edge emitter). Also shown are several of the transforms in action.
For the still images, it picks between two different transforms:

• fade
• neighbor average

Fade works like I described in my previous posting: simply fading from the current color to either black or white (exclusively black in these videos).
Neighbor average takes the value of each pixel plus the 3 adjacent pixels, and averages them to compute the pixel's value. Over time, the whole board turns to black because there is a certain amount of information lost with each average computation that takes place.

For the edge emitter, there are two transforms that are being used at the same time:

• fade
• translate

Both work as I described before, and the translate always works in the direction opposite where the emitter is positioned; if it's generating pixels on the left, the translation happens to the right.

Right now, I'm using about 5.2kB of codespace. Each of the still images takes up a moderate amount of space (~600-800 bytes), so I can't have a huge amount of them. However, I'm still well under the 32kB of available space.

The bigger issue currently is speed. The neighbor average function is very expensive, mainly because I have to keep an equal-sized pixel map to calculate the new values and then copy the new pixel map over to the old one.