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?
"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."
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.
> 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 Detail — https://youtu.be/0RPHS1dlh_g (Only 4168 views, WTF?)
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.
One of the original design documents mentions a 90°/16 division operation: https://arcadeblogger.com/2018/10/24/atari-asteroids-creatin...
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)
CMP reg, #0x10
AND REG, #0x0F
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
C code for asteroids: https://github.com/unoti/webasm-concept/blob/master/asteroid...
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.
Best one I did was with WebGL http://60fpsordie.com/asteroids/ (sorry doesn’t work on mobile)