Atari's Quadrascan Explained

I love the Atari vector games! There’s an excellent video by Retro Game Mechanics Explained on how they work: ▶ this video Recently I stumbled on some Tektronix videos on YouTube. Those vector displays are even more mind blowing than Atari’s arcade games. I hope I can get to see one in person someday.

in “Is the Living Computer Museum Dead?” · View on HN

If anyone is interested further in how vector effects were achieved, there is a good video showing the rendering of frames of Tempest in slow motion [0]. And if you're really interested in how vector effects were achieved, here's another that goes into the nitty gritty of how Tempest encoded point, line, color, etc. data in RAM and then rendered those images [1]. [0] [link] [1] ▶ this video

in “Atari Tempest: Time-Lapse Photography (2016)” · View on HN

Also the Retro Game Mechanics Explained channel on YouTube has a very well put together video about this as well: ▶ this video

in “Raw footage inside Sears with Atari 800 and 2600 (1982) [video]” · View on HN

This is a great look at the hardware and of vector display - if you want to get a good in-depth understanding of how Atari's original vector graphics display systems worked from the software side, though, Retro Game Mechanics on YouTube did an incredible deep dive into how it all worked, including emulating the vector instruction sets and step-by stepping through complete frame renders from Tempest. ▶ this video

in “Vector Games 32c3” · View on HN

Retro Game Mechanics Explained has a video about how the Asteroids vector generator worked and was coded for: ▶ this video Battlezone and later 3D games used different circuitry that generated vectors with analog circuitry and used a “math box” coprocessor based on Am2901 bit slice ALUs to help with the 3D math.

in “Unseen Footage of Atari Battlezone Arcade Cabinet Production” · View on HN

To be clear, I didn't (exactly) mean that the author of a Flash animation has to think in terms of creating a "demoscene demo." I rather meant that the Flash abstract machine is designed to primarily do the types of thing that demoscene demos do — i.e. to use vectors and gradient fills and clipping masks to achieve procedural visual effects. You could say that the SWF abstract machine has a "demoscene-alike Instruction Set Architecture." Most of the work of figuring out how to achieve particular visual effects on that abstract machine, though, is domain-knowledge built into the "Flash compiler" of the authoring tool. In my previous post, I emphasized Flash as a distribution format for a reason. While the authoring tools (and the .FLA project format) do work with clean abstractions of a timeline with keyframes and tweens (and objects with their own swappable animations that have their own sub-timelines), the .SWF export format bakes all that down into an imperative program for an abstract machine whose primitive opcodes involve defining and moving around (potentially texture-filled) vector objects on a canvas. Writing SWF bytecode directly, would be similar to programming against a retained-mode fixed-function graphics API like OpenGL — just without any 3D support. In other words, it would be like writing a demoscene demo. Or, to put that another way: the .SWF export format is basically a cousin of PostScript, but with a finishRenderAndWaitForNextFrame command, and the ability

in “Internet Archive expands Flash support” · View on HN