4 ms·

I don't buy it either. Showing something that came out 30 years after the time in question is not supportive of the argument. People wrote games and developed g

I don't buy it either. Showing something that came out 30 years after the time in question is not supportive of the argument. People wrote games and developed games and made game art on CRTs. They just developed on what they had. No one was sitting down and factoring in blur, scanlines, phosphor persistence, or etc.

mrandish 2y ago
> They just developed on what they had Correct. > No one was sitting down and factoring in blur, scanlines, phosphor persistence I get why you'd assume that from today's digital context. But analog video was different. I created video games in the 1980s and I know a lot of other people who did too. We still get together and hang at places like the Hacker's Conference and reminisce about hand-coding composite video pixels on 8-bit processors in assembly language. Good times. Back in the day, we not only considered how the pixel data we put in memory would be displayed differently on screens, we had to iteratively test it because analog video output circuits weren't always consistent between platforms (Woz made things a lot trickier by saving a nickel on the video output of the Apple II). Take a look at this http://nerdlypleasures.blogspot.com/2021/10/apple-ii-composite-artifact-color-ntsc.html http://nerdlypleasures.blogspot.com/2021/10/apple-ii-composi... Part way down the page you'll see a clear example of how we could put a specific pattern of black and white pixel data in memory that would cause the monitor to display 15 different colors. What we put in memory was not what the monitor displayed. And we wrote whole games this way. It also wasn't just the Apple II. Every arcade board and computer system could have it's own quirks. So, thinking about the blur, scanlines, and phosphors you mentioned was actually the easy part. The hard part was manipulating the display circuit in unnatural ways by hand-counting CPU cycles to display pixels in the "off-limits" overscan area or to switch display modes in the middle of a raster. There's even a book about programming the Atari video system that's literally called "Racing the Beam" (as in racing the electron beam scanning the CRT raster 59.94 times every second with the CPU). Most 80s games programmers had to know a lot about analog video signals. In fact, that's how I eventually crossed over from computer programming to video engineering.
- crazygringo 2y ago
  But these are different things -- color hacks and overscan or switching display modes are about circumventing known hardware limitations in predictable and clever ways. The topic under discussion here is the pixel art -- the idea that the artist would be relying on a fixed amount of horizontal blur to get the amount of glint in the eye "just right". And that's what you couldn't do, because that blur would be dramatically different on different CRT's. The art was designed to be robust under blurry conditions that had extreme variation. It wasn't designed for some kind of ideal CRT so it would look "just right".
  - mrandish 2y ago
    You're assuming that in the analog era content creators wouldn't bother because different analog TVs and monitors had differing fidelity and quality (or could be mis-adjusted). But we did bother. Most of us cared a lot about the pixels we made - maybe too much. We worked our asses off to make them as good as we could. It's no different than when I worked in an audio mixing studio. We had four different sets of stereo speakers sitting on the console and tied to a switchbox. When we were getting close to the final mix, and certainly during all of the mastering process, we'd switch between the audiophile grade speakers to the K-Mart speakers to the shitty car speakers. Of course, it sounded better on the better speakers and there was much less clarity in the cheap speakers. But we needed to make sure it sounded good enough on the bad speakers. This was just the normal way content creators in the analog distribution era worked. When making games I'd check the graphics on a good composite monitor but also on a TV through an RF switchbox. In the Amiga/Atari ST era we checked on analog RGB too. Commodore 64s had optional S-Video output which looked very good compared to composite video and light years better than RF. We checked it all and created content with it in mind. In the analog era I worked in games, video production and audio production. And in all three I can recall specific instances where we worked on aspects we knew would probably only ever be appreciated by those with better gear. This was especially true with visual effects work we did for broadcast television. We added detail that we saw on the studio master tape but which a lot of people never saw at home (at least until home DVD re-issues became a thing). We hated the limitations of the current distribution standards and of the gear we authored on (even though it was the best money could buy at the time). And we struggled mightily to overcome those limitations and preserve every shred of quality we could. Also, keep in mind that arcade cabinets weren't variable like consumer TVs. They used very specific monitors which had specific, sometimes non-standard, refresh rates. I never worked at an arcade company but I knew people who did and they often had the bare monitor tube that would be in the cabinet right on their desk during development. And in that era we only ever saw our game graphics on composite displays. All our monitors were composite video, unless you were senior enough to have a 80x25 serial terminal (which were amber or green text only). On the quad-sync analog RGB display I have now in my arcade cabinet, I've installed around 40 specific modelines so that they exactly match the original vertical and horizontal frequency of the monitor in, for example, a Williams Joust cabinet when I'm playing Joust. The CRT I have was made by Wells Gardner, a company that specialized in making CRTs for arcade cabinet manufacturers like Atari, Sega, Namco, etc.
dahart 2y ago
> No one was sitting down and factoring in blur, scanlines, phosphor persistence, or etc. Sure they did, implicitly, as a byproduct of using what they had and developing game art on CRTs. That’s the whole point; using the CRT affects your choices, and things would come out different if they’d used LCDs. We know that for a fact, because things are coming out differently now that people develop game art on LCDs. :P

mrandish 2y ago

> They just developed on what they had Correct. > No one was sitting down and factoring in blur, scanlines, phosphor persistence I get why you'd assume that from today's digital context. But analog video was different. I created video games in the 1980s and I know a lot of other people who did too. We still get together and hang at places like the Hacker's Conference and reminisce about hand-coding composite video pixels on 8-bit processors in assembly language. Good times. Back in the day, we not only considered how the pixel data we put in memory would be displayed differently on screens, we had to iteratively test it because analog video output circuits weren't always consistent between platforms (Woz made things a lot trickier by saving a nickel on the video output of the Apple II). Take a look at this http://nerdlypleasures.blogspot.com/2021/10/apple-ii-composite-artifact-color-ntsc.html http://nerdlypleasures.blogspot.com/2021/10/apple-ii-composi... Part way down the page you'll see a clear example of how we could put a specific pattern of black and white pixel data in memory that would cause the monitor to display 15 different colors. What we put in memory was not what the monitor displayed. And we wrote whole games this way. It also wasn't just the Apple II. Every arcade board and computer system could have it's own quirks. So, thinking about the blur, scanlines, and phosphors you mentioned was actually the easy part. The hard part was manipulating the display circuit in unnatural ways by hand-counting CPU cycles to display pixels in the "off-limits" overscan area or to switch display modes in the middle of a raster. There's even a book about programming the Atari video system that's literally called "Racing the Beam" (as in racing the electron beam scanning the CRT raster 59.94 times every second with the CPU). Most 80s games programmers had to know a lot about analog video signals. In fact, that's how I eventually crossed over from computer programming to video engineering.

crazygringo 2y ago
But these are different things -- color hacks and overscan or switching display modes are about circumventing known hardware limitations in predictable and clever ways. The topic under discussion here is the pixel art -- the idea that the artist would be relying on a fixed amount of horizontal blur to get the amount of glint in the eye "just right". And that's what you couldn't do, because that blur would be dramatically different on different CRT's. The art was designed to be robust under blurry conditions that had extreme variation. It wasn't designed for some kind of ideal CRT so it would look "just right".
- mrandish 2y ago
  You're assuming that in the analog era content creators wouldn't bother because different analog TVs and monitors had differing fidelity and quality (or could be mis-adjusted). But we did bother. Most of us cared a lot about the pixels we made - maybe too much. We worked our asses off to make them as good as we could. It's no different than when I worked in an audio mixing studio. We had four different sets of stereo speakers sitting on the console and tied to a switchbox. When we were getting close to the final mix, and certainly during all of the mastering process, we'd switch between the audiophile grade speakers to the K-Mart speakers to the shitty car speakers. Of course, it sounded better on the better speakers and there was much less clarity in the cheap speakers. But we needed to make sure it sounded good enough on the bad speakers. This was just the normal way content creators in the analog distribution era worked. When making games I'd check the graphics on a good composite monitor but also on a TV through an RF switchbox. In the Amiga/Atari ST era we checked on analog RGB too. Commodore 64s had optional S-Video output which looked very good compared to composite video and light years better than RF. We checked it all and created content with it in mind. In the analog era I worked in games, video production and audio production. And in all three I can recall specific instances where we worked on aspects we knew would probably only ever be appreciated by those with better gear. This was especially true with visual effects work we did for broadcast television. We added detail that we saw on the studio master tape but which a lot of people never saw at home (at least until home DVD re-issues became a thing). We hated the limitations of the current distribution standards and of the gear we authored on (even though it was the best money could buy at the time). And we struggled mightily to overcome those limitations and preserve every shred of quality we could. Also, keep in mind that arcade cabinets weren't variable like consumer TVs. They used very specific monitors which had specific, sometimes non-standard, refresh rates. I never worked at an arcade company but I knew people who did and they often had the bare monitor tube that would be in the cabinet right on their desk during development. And in that era we only ever saw our game graphics on composite displays. All our monitors were composite video, unless you were senior enough to have a 80x25 serial terminal (which were amber or green text only). On the quad-sync analog RGB display I have now in my arcade cabinet, I've installed around 40 specific modelines so that they exactly match the original vertical and horizontal frequency of the monitor in, for example, a Williams Joust cabinet when I'm playing Joust. The CRT I have was made by Wells Gardner, a company that specialized in making CRTs for arcade cabinet manufacturers like Atari, Sega, Namco, etc.

dahart 2y ago

> No one was sitting down and factoring in blur, scanlines, phosphor persistence, or etc. Sure they did, implicitly, as a byproduct of using what they had and developing game art on CRTs. That’s the whole point; using the CRT affects your choices, and things would come out different if they’d used LCDs. We know that for a fact, because things are coming out differently now that people develop game art on LCDs. :P