3 ms·

To be fair, I didn't ever look at the code. I took the word of Dave Sherman, the guy who designed the hardware for it (though the "math box" was lifted from ano

To be fair, I didn't ever look at the code. I took the word of Dave Sherman, the guy who designed the hardware for it (though the "math box" was lifted from another game, probably Battlezone). Here is one more interesting thing about the display that Dave told me. DRAM was expensive, and at the time the I, Robot game was much more expensive than most of the arcade machines they put out. To save on DRAM, they used fake double horizontal resolution. This is a memory from a conversation 30 years ago, but there is 3b per pixel to specify color, and one bit to indicate if the edge should be pushed out half a pixel. That is, when rasterizing the polygons, they saved one fractional X bit in the pixel. In the interior of polygons it had no effect, but when generating video, if pixel at offset (x+0) and pixel at offset (x+1) had a different color index, the fraction bit from pixel (x+0) was used in the video timing generator to place where the color transition would happen, doubling the apparent horizontal resolution. When more than one edge crossed a pixel the information isn't that useful, but such pixels are a tiny fraction of all edge pixels, so overall it was a big win.

phkahler 4y ago
I had read about that fractional pixel online, and the bit does seen to exist in the vram (3 bits color, 3 bits intensity, one other bit). I don't think it ever got implemented all the way through. If it works as described, it should cause the right edges of polygons to appear with higher resolution than the left edges, particularly on black (blank) background. I've got an I, Robot in my living room and have looked for this visual difference and can not see it. Doodle City even provides the opportunity to move and rotate objects, so even with direct control of object and orientation I can't see it. Apparently there were other things that never got finished with the game too.
- lordfrito 4y ago
  See my reply above... there is a 1/2 pixel being kept track of... looks like it indicates the pixel is "wide" and takes up at least half of the neighboring pixel to the right. This seems to delay the latching of the color to the monitor guns by a half pixel cycle. I agree that if it's there, its hard to see (I found some actual arcade footage online). I wonder if that's due to issues with the lower res monitors? Would be interesting to ground the 1/2 pixel signal pin and see if that has a noticeable effect on the screen visuals.
lordfrito 4y ago
You know reading this caused some forgotten neuron in my brain to fire. When I was reverse engineering the thing, I seem to remember there being a bit related to color/shading that I couldn't figure out what it did (I could see that it was being used). The system had a 64 color palette. The software broke that up into 8 sub-palettes to give you for 8 main colors with 8 shades each (0-7 first color, 8-15 second color, etc.) Polygons could call out colors directly using full palette index. Most polygons "faked" shading, they really just specified different shades of the same color for effect. For example, the dodecahedron / meteors in the space waves aren't real-time shaded, just colored to look that way. However the hardware could do shading, which cost an expensive dot product. So it was used sparingly. To do shading, the polygon used a 3 bit color "index" to call out one of the 8 sub-pallets. Then you add an offset of 0-7 based on the dot product of the normal vector to apply shading (I used 8 x dot product to get you an offset from 0 to 7.9999). I recall there being an extra bit there (4 bits instead of 3) but couldn't figure out what that last bit was for (it seemed like a "1/2 bit" to me). It looked like it was being used, but didn't make sense, so I stripped it off, and it didn't seem to affect anything so I forgot about it... till now. If I'm remembering correctly, this might literally be a "1/2 step" to add between shades? That can't be right can it? Another way I read what you wrote is that it could be considered an "anti-aliasing" bit to do some alpha blending at the edge of a polygon to fake higher resolution? Maybe that's a better way to read it? My memory is probably not 100% here... Would love to hear more.
- tasty_freeze 4y ago
  I don't think it was for antialiasing (to interpolate between shades at adjacent pixels), it affected the horizontal timing. I don't recall the actual resolution, but say it was 256 pixels per scan line. If the color for pixel 100 was index 5 and for pixel 101 it was index 3, the straight forward way would be to send the right RGB phase for whatever index color was throughout the interval pixel 100 and then send the right RGB phase for whatever was the right color for pixel 101. The half bit modified the timing to delay the transition from pixel 100 to pixel 101, somewhat doubling the horizontal resolution. It made polygon edges less chunky. Or another way to conceptualize it: each row had 512 pixels, but memory for only 256 pixels. By default each memory location would be used to fill in the color for pixels X and X+1. But the half bit would modify it to say whether the transition should be shifted out one more pixel. If the transition was from red to blue, the default way would be to generate four pixels out (R, R, B, B), but if the half bit was set, the video generator would output (R, R, R, B).

phkahler 4y ago

I had read about that fractional pixel online, and the bit does seen to exist in the vram (3 bits color, 3 bits intensity, one other bit). I don't think it ever got implemented all the way through. If it works as described, it should cause the right edges of polygons to appear with higher resolution than the left edges, particularly on black (blank) background. I've got an I, Robot in my living room and have looked for this visual difference and can not see it. Doodle City even provides the opportunity to move and rotate objects, so even with direct control of object and orientation I can't see it. Apparently there were other things that never got finished with the game too.

lordfrito 4y ago
See my reply above... there is a 1/2 pixel being kept track of... looks like it indicates the pixel is "wide" and takes up at least half of the neighboring pixel to the right. This seems to delay the latching of the color to the monitor guns by a half pixel cycle. I agree that if it's there, its hard to see (I found some actual arcade footage online). I wonder if that's due to issues with the lower res monitors? Would be interesting to ground the 1/2 pixel signal pin and see if that has a noticeable effect on the screen visuals.

lordfrito 4y ago

You know reading this caused some forgotten neuron in my brain to fire. When I was reverse engineering the thing, I seem to remember there being a bit related to color/shading that I couldn't figure out what it did (I could see that it was being used). The system had a 64 color palette. The software broke that up into 8 sub-palettes to give you for 8 main colors with 8 shades each (0-7 first color, 8-15 second color, etc.) Polygons could call out colors directly using full palette index. Most polygons "faked" shading, they really just specified different shades of the same color for effect. For example, the dodecahedron / meteors in the space waves aren't real-time shaded, just colored to look that way. However the hardware could do shading, which cost an expensive dot product. So it was used sparingly. To do shading, the polygon used a 3 bit color "index" to call out one of the 8 sub-pallets. Then you add an offset of 0-7 based on the dot product of the normal vector to apply shading (I used 8 x dot product to get you an offset from 0 to 7.9999). I recall there being an extra bit there (4 bits instead of 3) but couldn't figure out what that last bit was for (it seemed like a "1/2 bit" to me). It looked like it was being used, but didn't make sense, so I stripped it off, and it didn't seem to affect anything so I forgot about it... till now. If I'm remembering correctly, this might literally be a "1/2 step" to add between shades? That can't be right can it? Another way I read what you wrote is that it could be considered an "anti-aliasing" bit to do some alpha blending at the edge of a polygon to fake higher resolution? Maybe that's a better way to read it? My memory is probably not 100% here... Would love to hear more.

tasty_freeze 4y ago
I don't think it was for antialiasing (to interpolate between shades at adjacent pixels), it affected the horizontal timing. I don't recall the actual resolution, but say it was 256 pixels per scan line. If the color for pixel 100 was index 5 and for pixel 101 it was index 3, the straight forward way would be to send the right RGB phase for whatever index color was throughout the interval pixel 100 and then send the right RGB phase for whatever was the right color for pixel 101. The half bit modified the timing to delay the transition from pixel 100 to pixel 101, somewhat doubling the horizontal resolution. It made polygon edges less chunky. Or another way to conceptualize it: each row had 512 pixels, but memory for only 256 pixels. By default each memory location would be used to fill in the color for pixels X and X+1. But the half bit would modify it to say whether the transition should be shifted out one more pixel. If the transition was from red to blue, the default way would be to generate four pixels out (R, R, B, B), but if the half bit was set, the video generator would output (R, R, R, B).