Game Graphics: Racing The Beam

Have you ever wondered how the graphics in your favorite video games worked? This is the start of a series on game graphics, and what better place to start than how exactly the original Mario Bros. got those glorious pixely pixels onto the screen. Buckle in, because we’re “racing the beam” with systems like the NES, Commodore 64, and many other classics from the 1980s.

And to understand the 1980’s, it’s important to understand how the televisions of the time worked. Cathode Ray Tube (CRT) televisions work by precisely bombarding a phosphor layer with electrons, which excites the phosphor, which then releases visible light. The beam scans from left to right then top to bottom, giving each pixel a small fraction of a second of time. All of this effectively means that pixel data needs be sent at the same time as when the pixels are being lit up, which is why this type of graphics is often dubbed “racing the beam”.

Continue reading “Game Graphics: Racing The Beam”

Racing The Beam With Super Hexagon

Early game consoles like the Atari 2600 had a very, very limited amount of RAM. There wasn’t even enough RAM for all the pixels on the screen; instead, pixels were generated by the CPU as they were being drawn. It’s playing with scanlines and colorbusts with code, something we’re now calling. ‘racing the beam’ for some reason.

[Sam] is in the middle of an EE degree right now, and for a digital design class he needed to write some Verilog. At the time he was addicted to the game Super Hexagon, and the game mechanics are simple enough for an FPGA. He built his own implementation, but not one with framebuffers. He’s using a pipelined approach where each pixel’s value is calculated just a few clock cycles before it’s displayed. It vastly reduces the memory requirements, on his Altera DE1 board compared to the framebuffer approach.

Video below.

Continue reading “Racing The Beam With Super Hexagon”