Hacker News new | past | comments | ask | show | jobs | submit login
Asteroids: By the Numbers (retrogamedeconstructionzone.com)
44 points by rbanffy 20 days ago | hide | past | favorite | 16 comments

>In 1979, arcade cabinet screens were limited to a few hundred pixels on a side, so the player's ship was only connected graphically by about 20 points. This meant, in turn, that there were only a limited number of orientations that they could render for the ship, in this case intervals of 5 degrees.

I don't know if it is a mistake, but it's strange to talk of pixels, because this game uses a vector monitor, not a bitmapped display. There are no pixels really. The 5 degree rotational step may have been due to some other limitation, perhaps of integer arithmetic, or limited storage space for a pre-calculated look up table, or using an 8 bit variable?

You’re correct, pixels is the wrong term there. Vector monitors were limited in where they could put points, however, so there was still an effective resolution limit. I’ll correct the entry.

Along with the addressability (effectively deflection DAC's resolutions), the other big limitation of vector displays was the number and length of vectors they could show (itself a function of beam intensity and how fast the deflection mechanism could point it) without the display flickering. Some terminals from that time used very long persistence phosphor to allow more lines to be drawn. Even then, sometimes, the amount of information shown forced them to flicker in seizure-inducing ways. The CDC 6x00 consoles packed so much information the fonts themselves ended up deformed by the inability of the deflection coils to keep up with the data.

Thanks! Didn't know that. Gamasutra had an interview with Ed Logg last year where he talked about hardware limitations. A portion from it:

"Logg: There were no difficult or technical issues. Of course there were limitations such as the amount of stuff I could draw and still update the game at 60Hz. The limited RAM also limited the number of asteroids I could draw so you may see some large asteroids go away with a single shot if the screen if full.

There was issue of the spot killer that was interesting. The spot killer was a feature added so that if the game crashed when the beam was on that it did not burn a hole in the phosphor on the screen. Thus I needed to have enough deflection on the screen so the spot killer did not turn off the beam. Therefore I put the copyright on the bottom of the screen and the scores at the top.

However, no one told me how much deflection was actually needed and I found out later this was not quite enough, so on some games the screen would dim if the player ship and the3 remaining asteroids were at the right spots on the screen."


Another notable feature about those CDC 6600 vector graphics displays was the way that the system would shrink the vector fonts to fit long command lines. Most of the time the fonts were quite big and could be read from a distance without sitting down in front of the displays, but if you entered a long line the letters would suddenly get smaller so that you could fit more on a line. (These displays were two round side by side displays—perfect for playing lunar lander after hours at the comp center).

This was around 1973 and up until that time I had used very few systems that used video displays. Even the time sharing systems I had used up until then were usually hard copy devices that printed on rolls or fan fold paper. Even video terminals were usually line oriented devices and used line editors like sed or teco.

I remember teaching a programming class the following year in grad school and spending a lot of time teaching my students to use line editors like sed since it was so much better than the more commonly used punched cards.

Thanks; seems like a superb analysis (in my extremely non-expert opinion†).

> addressability (effectively deflection DAC's resolutions)

So I guess from the perspective of how precisely a programmer could position vectors — and therefore how many distinct rotations would make sense — this limit in resolution was the ultimate deciding factor. There's a limit where more fine-grained angles/positions would have been pointless. But then, in turn, the DAC wasn't necessarily limited to that many bits because more wouldn't have been feasible, but because trying to position a vector more precisely would have been defeated in practice by the error introduced by the deflection coils, which can only be so accurate when you yeet the beam all over the place.

My working hypothesis is that it would have been possible to make a display with more precise positioning, but only for the rare case when you wanted to display extremely little information, such as a single moving dot, which was too niche and silly to spend resources on.

Does that sound about right? Just curious if I'm understanding the issue somewhat correctly.

† I know almost nothing about the topic but it seems analogous to aiming lasers with mirrors on computer-controlled actuators. Which was a rare treat in my childhood and has recently become accessible to modestly prosperous hobbyist hackers. Check out https://youtu.be/tozuzV5YZ7U for a quick taste. You'll probably want to watch the BTS next: https://www.youtube.com/watch?v=8YONOexk0Eke .

Oh and look, here's a thing that exists: Recreating Asteroids with lasers - Seb Lee-Delisle at An Evening of Unnecessary Detailhttps://youtu.be/0RPHS1dlh_g (Only 4168 views, WTF?)

> My working hypothesis is that it would have been possible to make a display with more precise positioning

Tektronix DVST terminals started with 1024x1024 addressability and went up to 4094x4096. The difference is that they didn't have to refresh the screen ever 1/60 second.

The rotation step may be 5.625 degrees. That would be equivalent to a division of 90° by 16, which could be accomplished by a simple 4 bit shift

One of the original design documents mentions a 90°/16 division operation: https://arcadeblogger.com/2018/10/24/atari-asteroids-creatin...

I don’t see where “a division of 90° by 16” would be used in the game.

Given the CPUs of the time, I would think they wouldn’t compute angles, but use a lookup table of sines and cosines (possibly in a single table, and scaled by a convenient factor).

I would guess they used a lookup table to look up sines and cosines, and picked a power of two for the number of different angles because increasing the angle with wraparound is faster that way. Compare (made up assembly language)

    INC reg
    CMP reg, #0x10
    BNE dontWrap
    CLR reg

    AND REG, #0x0F

What you've said sounds more likely. The original code can be seen here: http://www.ionpool.net/arcade/astcode/asteroids_code_project...

The rotation code apparently starts at 0x7086, which adds or subtracts 3 from a one byte variable. If that 8 bit variable maps to a full 360 degrees of rotation, that would result in steps of about 4.2 degrees, but I don't know because I couldn't follow the code after that

Reaching back in some ancient memory from 35+ years ago I recall that the rotation tables were sin/cos and the cos table overlapped the sin table by 180 degrees. I think there was 256 entries in When the ship rotated it stepped through the rotation table by three entries at a time, and took advantage of the 8-bit accumulator wrapping around. Then the value was used as a look-up in a table. The ships direction was a value of 0x00 to 0xFF, and that was used as an index in to the rotation table. I would need to read through the disassembly again to refresh my memory.

My son just happens to be playing Scramble (Defender) on my old Vectrex as we speak! Of course, it comes w/Mine Storm (Asteriods/Space War) built-in. (Though I think it needs some new capacitors, as the vector retrace isn't as seamless as it used to be.) There is still something magical about vector gfx to me -- I much prefer "notional" graphics to realistic ones, but I guess 'cause I'm old...

I started experimenting with WebAssembly a while back, and started writing Asteroids in C, hosted in a web page via webassembly. It's not done yet, but it's a real fun way to experiment both with asteroids and with C, and with webassembly:

C code for asteroids: https://github.com/unoti/webasm-concept/blob/master/asteroid...

Javascript code for the X/Y vector display device that the C code talks with: https://github.com/unoti/webasm-concept/blob/master/asteroid...

This is a fun game to implement. You get a lot of varied gameplay for a small amount of code.

You need an event loop, and a basic object-oriented model where all game objects have movement operations, shape vector lists, hit boxes, and object transitions upon death. Typical object state is position and velocity, and possibly an age counter. So, the player, each asteroid, the bullets, and the attacking aliens all have the same prototype. Very clean.

I did it in assembler on a PDP-11 with bitmap graphics a long time ago. 100% fun.

Great in-depth breakdown. Wish I had seen this while working on the different clone versions I made a while back. Could have made them a lot more accurate to the original.

Best one I did was with WebGL http://60fpsordie.com/asteroids/ (sorry doesn’t work on mobile)

Here is a deep dive into the circuits used by Asteroids and other vector games. Digital & analog vector generators, gate arrays, the Math Box, and more.


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact