Augmented reality videogame
In the decade where videogames were born, everything virtual looked like rectangular blocks. From today’s perspective, the representation of a tennis court in the earliest videogames is hard to distinguish from a soccer or a basketball field.
‘PING! – Augmented Pixel’ is a seventies style videogame, that adds a layer of digital information and oldschool aesthetics to a video signal: A classic rectangular video game ball moves across a video image. Whenever the ball hits something dark, it bounces off. The game itself has no rules and no goal. Like GTA, it provides a free environment in which anything is possible. And like Sony’s Eyetoy, it uses a video camera as game controller.
What I found interesting when I developed this game, is, that it could have been made already in the seventies. The technology that I used for it is (in a way) similar to what Atari used for the first Pong. It becomes even more awkward, if you think that the electronic components for capturing and evaluating a video signal are cheaper than the rotary game controllers that Atari used. But still, from an economic point of view it makes sense that Eyetoys weren’t the ultimate controllers of thirty-something years ago, as a video camera was probably very hard to afford back in the days.
For those who want to know how it works:
The game is programed with AVR-GCC on an ATmega8 microcontroller that runs with 16MHz. The controller gets basic videosignal synchronisation information from an LM1881 sync separator that triggers two hardware interrupts. One for a new image, the other one for a new line. The controller evaluates the brightness around the pixel (/ball) via its comparator input. Drawing the white image overlay is realized with a simple pull-up resistor in the signal line.
Since several people in the Interwebz told me that they want to rebuild the game, here are some more photos of it. I also uploaded the schematics, the perfboard layout and a parts list in this pdf.
And opened. Nothing special here: There’s a 9V battery, a little circuit board and all the switches.
A closer look on the circuit board.
And the board seen from the bottom.
Remember: You can find drawings of this all here.
Here’s a trick: The power supply lines of the Atmega8 are criss-crossed. I always go with the +5V wire over the IC socket in order to connect the left and the right power pins. That avoids a messy circuit design on the solder side of the board.
When you want to build your own “PING!”, you have to program the microcontroller. I use this cheap ISP programmer that I bought here.
If you just get started and want to know in detail how to program an AVR – here’s a great tutorial. Sorry folks, this link is German only. But Google will also find you a good English source.
(Here’s a hint: Once you’re the proud owner of an ISP programmer, you will likely never spend money anymore on Arduinos, as you can make them yourself, then. But there’s another thing: Once you’re familiar with programming your Atmel using straight AVR-GCC, you’ll probably never want to use an Arduino anymore.)
The Fusebit settings for the controller are clear: Just tell the controller to use the external crystal as clock. (SUT_CKSEL)
For the case, I used a U-shaped extruded aluminum profile. The different metal parts are all built out of the same profile.
And a look from the other side.
That’s it so far about the hardware. Concerning the firmware: Be aware, that the program is for PAL video systems only. If you want to play this game on your NTSC system, you have to adapt the timing parts of the source code.
A big congratulations goes out to the first one who emails me a functionning code for NTSC videosignals. I’ll link it here with name and credits and all. If you regard sending me emails as a too private action, you can also post a link to your code in the comments of Creative Applications. Don’t forget to proove that your code works with a little video!
To help you understand both, the source code and the schematics, I’ve explained it already in the comments on Hackaday:
… here’s how it works:
Drawing onto the signal/image:
One output of the AVR is connected via a 1K resistor to the video signal. Switching this output to HIGH rises the signal about a few mV -> the image becomes brighter, then.
Digitizing the video image:
Doesn’t happen. Instead, only the brightness of the area around the pixel is captured. Imagine a grid of 3×3 squares. The square in the middle is the pixel. When the signal is at this middle position, the output that draws on the video is switched to HIGH. If the signal is within one of the eight areas surrounding that pixel, the AVR compares the specific brightness (Voltage level) of that area with a threshold. That’s how an obstacle and its position in relation to the position of the pixel is detected.
Calculating the animation:
When the beam (or signal) has finished drawing the lower white bar, there’s plenty of time to calculate the new position of the pixel until the next image has to be drawn. As it is all synced with the video signal, this animation happens smooth. Couldn’t happen more smooth. An animation ‘pixel by pixel’ is also no problem, as it is all about counting video lines (y) or delaying within a specific video line (x).
This also explains why the starting animation is rendered smooth.
And it also means, that there is a delay until the pixel reacts: It reacts in the next image that is drawn. No magic here.
Speed of the processor:
The AVR is clocked with a 16MHz quarz. The duration (only image content) of one PAL video line is 64uS. => There are 1024 clock cycles per visible part of each video line. That’s really sufficient for what the program has to do: Which is mainly waiting, a bit of counting and sometimes reading the internal comparator bit or switching an output.
Ok, that’s enough of information. With all those tips, you should be able to build your “PING!”, now. Send me some photos of it, when you’re done!