Racing the Beam Explained - Atari 2600 CPU vs. CRT Television

Here’s a detailed video by retro game mechanics that shows how the logo graphics of the infamous E.T. game is rendered: ▶ this video It seems incredible, very difficult. And remember, back then cartridges only had 8KB of memory. This means even more hacks are required, if your game needs more than a few levels. Theres a recurring hn post how jungle hunt encoded levels in a single byte (bitfield), then used some sort of sequence generator to allow going back and forth among the 255 levels.

in “Atari 2600 Hardware Design: Making Something Out of (Almost) Nothing” · View on HN

Keeping in mind how ridiculously primitive and cumbersome Atari 2600 was to program on, I think it's actually remarkable how functional E.T. is (adding in the time pressure and all). I never got around to read Racing the Beam [1] but Retro Game Mechanics Explained on YouTube has a good demonstration [2] on how the graphics programming seemed like a nightmare compared to later computers and game consoles. Just positioning things on screen required calculating machine cycles of other preceeding instructions. Refactoring must've been fun. [1] [link] [2] ▶ this video

in “The man who made the “worst” video game in history (2019)” · View on HN

While I'm really happy we have faster systems now, there was something fun about about having to subvert constraints in games, and so satisfying and lovely when you did it right. HN folks are probably familiar with raster interrupts ( [link] ) and "racing the beam." I always associated this with the Atari 800. You weren't "supposed" to be able to do stuff like [link] , but Display List Interrupts made that possible. What I didn't know until recently was how much Atari 2600's games owed to this kinda of craziness: ▶ this video It's stuff like this that makes me think that if hardware stopped advancing, we'd still be able to figure out more and more interesting stuff for decades!

in “Palette lighting tricks on the Nintendo 64” · View on HN

Kinda cool, I've never seen these techniques all in one place before. Growing up, I thought that SNES mode 7 scaling was so cool: [link] The article mentions about halfway down the page that what made the 80s road rendering technique possible was racing the beam. Where say an Atari 2600 would toggle the color at certain pixel counts as the TV's electron beam swept the screen, producing graphics that seemed otherwise impossible from such underpowered hardware: [link] ▶ this video Some engines allowed for say 8 hardcoded sprites this way by toggling colors at each sprite's position, with various rules about overlapping, so sprites would flicker sometimes when they were next to each other.

in “Lou's Pseudo 3D Page (2013)” · View on HN

Well, if you think it's possible, try coming up with even the core of an architectural basis for 1. a declarative language for describing the same things PostScript describes, 2. which allows the rasterization of arbitrary shapes at arbitrary DPI (PostScript is DPI-oblivious — it's up to the printer what DPI it's printing at!); 3. and which also works for vector plotters , that will never rasterize the data you're sending at all, but will actually follow the bezier curves, like the 2D version of 3D-printer GCODE; 4. and which enables the implementation of this rasterization and/or plotting on a variety of affordable hardware architectures in the 1980s — where the 1980s was a time where CPU power wasn't too expensive, but where memory prices were at an absolute premium. So your printer might have had a CPU as powerful as your computer's in it, to crunch PostScript — but definitely wouldn't have had the memory to buffer a full rasterized page. --- To put that last constraint another way: PostScript was designed to be rasterized in a way that enabled printers to do something much akin to "Racing the Beam" ( ▶ this video ). In both the display-rendering and printing cases, this was done in 1980s hardware, because 1980s memory was too expensive for most systems to be dedicating it to hold a buffer to asynchronously pre-render into and then read from when drawing. So instead, in both cases, you must render+rasterize in one motion, programmatically and extremely efficiently. And the obvi

in “Insecure Features in PDFs (2021)” · View on HN