5 ms·

>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 m

>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?

retroanalyst 6y ago
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.
- rbanffy 6y ago
  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.
  - retroanalyst 6y ago
    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." https://www.gamasutra.com/blogs/DavidCraddock/20190913/350030/Outstanding_Ideas_Ed_Logg_on_Asteroids_and_Gauntlet.php https://www.gamasutra.com/blogs/DavidCraddock/20190913/35003...
  - n3k5 6y ago
    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 https://youtu.be/tozuzV5YZ7U for a quick taste. You'll probably want to watch the BTS next: https://www.youtube.com/watch?v=8YONOexk0Eke 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 https://youtu.be/0RPHS1dlh_g (Only 4168 views, WTF?)
    - rbanffy 6y ago
      > 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.
      - deleted 6y ago
        [deleted]
    - deleted 6y ago
      [deleted]
  - todd8 6y ago
    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.
- FatalLogic 6y ago
  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-creating-a-vector-arcade-classic/ https://arcadeblogger.com/2018/10/24/atari-asteroids-creatin...
  - Someone 6y ago
    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 dontWrap: RTS with INC REG AND REG, #0x0F RTS
    - FatalLogic 6y ago
      What you've said sounds more likely. The original code can be seen here: http://www.ionpool.net/arcade/astcode/asteroids_code_project.html 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
      - justinlloyd 6y ago
        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.
thelazydogsback 6y ago
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...

retroanalyst 6y ago

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.

rbanffy 6y ago
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.
- retroanalyst 6y ago
  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." https://www.gamasutra.com/blogs/DavidCraddock/20190913/350030/Outstanding_Ideas_Ed_Logg_on_Asteroids_and_Gauntlet.php https://www.gamasutra.com/blogs/DavidCraddock/20190913/35003...
- n3k5 6y ago
  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 https://youtu.be/tozuzV5YZ7U for a quick taste. You'll probably want to watch the BTS next: https://www.youtube.com/watch?v=8YONOexk0Eke 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 https://youtu.be/0RPHS1dlh_g (Only 4168 views, WTF?)
  - rbanffy 6y ago
    > 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.
    - deleted 6y ago
      [deleted]
  - deleted 6y ago
    [deleted]
- todd8 6y ago
  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.
FatalLogic 6y ago
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-creating-a-vector-arcade-classic/ https://arcadeblogger.com/2018/10/24/atari-asteroids-creatin...
- Someone 6y ago
  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 dontWrap: RTS with INC REG AND REG, #0x0F RTS
  - FatalLogic 6y ago
    What you've said sounds more likely. The original code can be seen here: http://www.ionpool.net/arcade/astcode/asteroids_code_project.html 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
    - justinlloyd 6y ago
      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.

thelazydogsback 6y ago

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...