CRT simulation for Stella

[Keatah]

This is almost one of those 'ineffable' qualities missing from emulated systems vs. the real thing. This is a milestone step towards 'perfect emulation'. Not only are we emulating the discerete logic chips, the cpus, sound synthesizer chips, LC networks, ladder d/a converters, ram, rom, i/o these days we are taking the next step in simulating the output devices. I cannot emphasize enough that we make this as modular as possible so that programmers can implement this in their emulators. It is also important to make as many parameters adjustable. Afterall, my unearthly beautiful AFFS LCD's are probably of a different mfg, that yours is. And yours most likely has a different crystal shape or arrangement (hahah phospohor mask) than that of my girlfriend's monitors. And my friend's 1600x1200 classic UXGA is different than your kid's laptop, which might be a 1440x900 WXGA+ .. Perhaps somebody has a an S-PVA or MVA type.. so you see, tweakability is paramount! And as a side bonus, it would be nice to have a crt.ini profile file that we could post or exchange amongst the user forums. After all, I would want to share my blazing Sony Trinitron aperture grille (O'led enhanced!!) with all of the emulation community! Especially since it would have hundreds of hours of tweaking behind it. So you see.. This is defnitely

[israelg]

I am waiting for this a very long time...

[Herbarius]

In my opinion, the effects demonstrated on the screenshots are too strong (stronger than they appear on a real CRT), but propably they're adjustable...

Also it doesn't look like all like the picture on a TV because of the missing scanlines. Like the sky in Enduro would appear as alternating bright blue and dark blue lines if you go close to the TV...

[Keatah]

There needs to be NTSC noise and waviness and more general imperfections here.

[ibogost]

Yup, lots of improvements we can make. What you're seeing is a snapshot of current progress; we'll be making more adjustments before May. And I'm sure many more will need to be made, but it will be a concrete start.

[MagerValp]

I read this a few days ago, and originally thought it sounded really interesting, but reading further I was disappointed. You appear to be reducing the complex interaction of the color encoding, the color carrier, the bandwidth limits, the electron beam hitting phosphors, and all the other details that make up an NTSC CRT based display system into "let's slap on some texture, delay, blur, and noise filters, and call it a day". It even appears to be done on RGB pixels, and not YUV and the frequency domain.

 

It's also a bit scary to see that people seem to think of modern (i.e. TFT) displays as just "better". CRTs' main disadvantage were sharpness and size, but in nearly every other respect they were actually better: sporting wider color gamut, better contrast, resolution independence, no latency, and supporting a wide range of scan rates. While a modern TFT is better suited to the everyday tasks of users today, they're a major stumbling block when it comes to emulation.

[mos6507]

IMHO, recreating RF with all of its noise and fuzzy edges is not something I'm interested in. I didn't like RF back in the day and have no nostalgia for it now. But the stock look of emulators on an LCD monitor is too sterile as well. I would want to get the CRT emulation to recreate a well tuned composite or S-video mod. So you get the CRT monitor feel, but not an intentionally cruddy picture.

Edited May 1, 2009 by mos6507

[Thomas Jentzsch]

I read this a few days ago, and originally thought it sounded really interesting, but reading further I was disappointed. You appear to be reducing the complex interaction of the color encoding, the color carrier, the bandwidth limits, the electron beam hitting phosphors, and all the other details that make up an NTSC CRT based display system into "let's slap on some texture, delay, blur, and noise filters, and call it a day". It even appears to be done on RGB pixels, and not YUV and the frequency domain.

Ok, it may be far from perfect. But it is a start, isn't it?

[+stephena]

I read this a few days ago, and originally thought it sounded really interesting, but reading further I was disappointed. You appear to be reducing the complex interaction of the color encoding, the color carrier, the bandwidth limits, the electron beam hitting phosphors, and all the other details that make up an NTSC CRT based display system into "let's slap on some texture, delay, blur, and noise filters, and call it a day". It even appears to be done on RGB pixels, and not YUV and the frequency domain.

Ok, it may be far from perfect. But it is a start, isn't it?

I agree. This is a very good first effort, and I fully support anyone who wants to help with Stella development, especially when it's something as complex as this. It hasn't been released yet, and no doubt there's more improvements to be made, but it's 100 times better than what Stella had before in this area (ie, nothing). I thnk it's a little early to be disappointed when we haven't even seen the initial version yet, let alone the final one.

[Keatah]

Yes, we will need to see this firsthand on our own monitors and configurations. Only then can we offer constructive criticism in a manner that will move the project closer to what we expect.

[Keatah]

IMHO, recreating RF with all of its noise and fuzzy edges is not something I'm interested in. I didn't like RF back in the day and have no nostalgia for it now. But the stock look of emulators on an LCD monitor is too sterile as well. I would want to get the CRT emulation to recreate a well tuned composite or S-video mod. So you get the CRT monitor feel, but not an intentionally cruddy picture.

 

You should then be easily satisfied with a simple phosphor mask .png application. And perhaps some good saturation and bleedthrough/glow. The picture will have some semblence of scanlines but continue to be sharp.

 

That is why I say all the parameters of this project must be user configurable. Everyone will have different expectations; and those expectations will be based on how they remember the early system. And as you can guess, there were probably countless variations in the TV hookups, wire lengths, contact cleanliness. etc.. Not to mention the hundreds of differnt TV's. And with those TV's - I'm absolutely certain none of them have been identically adjusted. ANALOG, babycakes!!

Edited May 1, 2009 by Keatah

[israelg]

I use the rendering filters on Mame & Mess and it looks

much better, it's NOT perfect but it has very nice look & feel...

[MagerValp]

I agree. This is a very good first effort, and I fully support anyone who wants to help with Stella development, especially when it's something as complex as this. It hasn't been released yet, and no doubt there's more improvements to be made, but it's 100 times better than what Stella had before in this area (ie, nothing). I thnk it's a little early to be disappointed when we haven't even seen the initial version yet, let alone the final one.

I'm sorry, I don't mean to belittle the improvements to Stella. Anyone that helps development should be supported, and adding post-processing is great. It's just that when I saw something about CRT simulation from a professor at a respected university, I expected more than run of the mill filters. Shouldn't the first steps be to analyze, understand, and document the phenomenon? I mean, take a look at Pepto's article on PAL colors, Blargg's information on sound emulation, or Antti Lankila's research into SID distortion. They did a ton of research and made emulators a lot more true to the original hardware. The filters look pretty neat, but Ian himself set the standard higher than that:

Many of today's players may only experience Atari games in emulation. Indeed, many of my students may have little to no memory of CRT televisions at all. Given such factors, it seems even more important to improve the graphical accuracy of tools like Stella.

[+batari]

If they are going for authenticity, they should also correct the pixel size ratio.

 

I believe Stella uses 2:1 pixels (i.e. horizontal to vertical) ratio, which is correct for PAL but for NTSC the actual pixel ratio is around 1.6:1. This means games will be stretched vertically in Stella compared to real hardware.

 

I haven't brought this up before because I prefer the 2:1 ratio for development since the pixels can be rendered cleanly, and it's important to see individual pixels.

 

1.6:1 pixels would likely require anti-aliasing which would normally result in a fuzzier pixels, but for this project it probably wouldn't, and would look more authentic overall.

[+stephena]

If they are going for authenticity, they should also correct the pixel size ratio.

 

I believe Stella uses 2:1 pixels (i.e. horizontal to vertical) ratio, which is correct for PAL but for NTSC the actual pixel ratio is around 1.6:1. This means games will be stretched vertically in Stella compared to real hardware.

 

I haven't brought this up before because I prefer the 2:1 ratio for development since the pixels can be rendered cleanly, and it's important to see individual pixels.

 

1.6:1 pixels would likely require anti-aliasing which would normally result in a fuzzier pixels, but for this project it probably wouldn't, and would look more authentic overall.

This can be emulated by changing the aspect ratio in OpenGL mode. In fact, a recent release made the aspect ratio setting different for NTSC and PAL modes for precisely the reason you mention; the pixels are different widths. I suspect even with the new filtering modes, we'll just rely on the current aspect ratio settings to get that part to look correct.

 

The default for NTSC and PAL is 2:1, as you say, which is obtained with a gl_aspect(n|p) of '100'. So, since (1.6/2.0)*100 = 80, that's what you should use in NTSC mode. And sure enough, if you bump gl_aspectn down to 85 or so, you'll get a much more authentic image. The extra 5 (or so) comes from the fact that your particular monitor might not have exactly square pixels.

 

The following snapshots from River Raid illustrate this:

 

Normal mode NTSC (100%, 2:1):

 

Aspect ratio corrected, NTSC (87%, ~1.7:1 mathematically, looking more like 1.6:1 in reality):

[+batari]

If they are going for authenticity, they should also correct the pixel size ratio.

 

I believe Stella uses 2:1 pixels (i.e. horizontal to vertical) ratio, which is correct for PAL but for NTSC the actual pixel ratio is around 1.6:1. This means games will be stretched vertically in Stella compared to real hardware.

 

I haven't brought this up before because I prefer the 2:1 ratio for development since the pixels can be rendered cleanly, and it's important to see individual pixels.

 

1.6:1 pixels would likely require anti-aliasing which would normally result in a fuzzier pixels, but for this project it probably wouldn't, and would look more authentic overall.

This can be emulated by changing the aspect ratio in OpenGL mode. In fact, a recent release made the aspect ratio setting different for NTSC and PAL modes for precisely the reason you mention; the pixels are different widths. I suspect even with the new filtering modes, we'll just rely on the current aspect ratio settings to get that part to look correct.

 

The default for NTSC and PAL is 2:1, as you say, which is obtained with a gl_aspect(n|p) of '100'. So, since (1.6/2.0)*100 = 80, that's what you should use in NTSC mode. And sure enough, if you bump gl_aspectn down to 85 or so, you'll get a much more authentic image. The extra 5 (or so) comes from the fact that your particular monitor might not have exactly square pixels.

 

The following snapshots from River Raid illustrate this:

 

Normal mode NTSC (100%, 2:1):

 

Aspect ratio corrected, NTSC (87%, ~1.7:1 mathematically, looking more like 1.6:1 in reality):

Thanks! I stand corrected.

[ibogost]

I'm sorry, I don't mean to belittle the improvements to Stella. Anyone that helps development should be supported, and adding post-processing is great. It's just that when I saw something about CRT simulation from a professor at a respected university, I expected more than run of the mill filters. Shouldn't the first steps be to analyze, understand, and document the phenomenon?

 

I appreciate this sentiment. And actually, a lot more research went into the effects than just eyeballing, but certainly more could be done. This is an ongoing project, as Stella is an open platform, and you're seeing the results of a student capstone done in a few month's time. I'm just now preparing to set up the next round of it for our summer sessions, though. Also, I wouldn't underestimate the rhetorical power of doing a rough-cut on something as a way to build a set of ideas around future work, including the very reactions you're offering.

[israelg]

When do u think the first version (Stella) with this feature will be released ?

 

I.G

[+stephena]

When do u think the first version (Stella) with this feature will be released ?

 

I.G

I think the code is supposed to be forwarded to me sometime this month. After that, I'd have to review and merge with the latest changes from other sources. I'd also need to make sure it's available everywhere (or at least on the 'big 3' systems, LInux/OSX/Windows), since cross-platform code is one of the design goals of Stella. So perhaps later this month or early June.

[SeaGtGruff]

I wonder if you could eventually incorporate some virtual control knobs for adjusting the palette as if we're adjusting our TV set and/or the color pot on our Atari? There's some code in the "Request for screenshots" thread that might be good to use for that. You wouldn't need to calculate the colors all the time, just when the control knobs (brightness, contrast, tint, saturation, red, green, blue, color pot phase angle) are being adjusted, then calculate the new palette and store it in an array. And maybe have an option to let the user save the array to a new palette file and give it a name.

 

Michael

 

PS-- At first I liked the old aspect ratio adjuster better, but I finally realized what the two new ones are-- N is for NTSC, and P is for PAL, right?

[ibogost]

I wonder if you could eventually incorporate some virtual control knobs for adjusting the palette as if we're adjusting our TV set and/or the color pot on our Atari? There's some code in the "Request for screenshots" thread that might be good to use for that. You wouldn't need to calculate the colors all the time, just when the control knobs (brightness, contrast, tint, saturation, red, green, blue, color pot phase angle) are being adjusted, then calculate the new palette and store it in an array. And maybe have an option to let the user save the array to a new palette file and give it a name.

 

Yes, thinking about this seriously...

[+stephena]

I wonder if you could eventually incorporate some virtual control knobs for adjusting the palette as if we're adjusting our TV set and/or the color pot on our Atari? There's some code in the "Request for screenshots" thread that might be good to use for that. You wouldn't need to calculate the colors all the time, just when the control knobs (brightness, contrast, tint, saturation, red, green, blue, color pot phase angle) are being adjusted, then calculate the new palette and store it in an array. And maybe have an option to let the user save the array to a new palette file and give it a name.

 

Yes, thinking about this seriously...

We'd need to think about how to do this properly, as it's something that the software renderer could use as well (vs. the new filtering code, which is OpenGL only). So basically, this would belong at a lower level than the current OpenGL stuff. Put another way, this isn't specific to OpenGL, and really isn't related to the new filtering code at all.

[SeaGtGruff]

I wonder if you could eventually incorporate some virtual control knobs for adjusting the palette as if we're adjusting our TV set and/or the color pot on our Atari?

 

Yes, thinking about this seriously...

Put another way, this isn't specific to OpenGL, and really isn't related to the new filtering code at all.

Yes, I was actually thinking in terms of it being done within Stella at the core level, rather than being a filter.

 

Michael

[Kr0tki]

It would be great if the end results looked like Blargg's NTSC Libraries, here:

 

http://slack.net/~ant/libs/ntsc.html

 

kat5200 has incorporated an NTSC filter - and it really is fantastic. As shown in the link above there has been NTSC filters incorporated in various other system emulators (including Nestopia). It would be great to see an Atari 2600 emulator and an Atari 7800 emulator with such an effect.

 

All the best with this endeavor, ibogost. I'm looking forward to the end results.

 

-Trebor

From what I see, Ian Bogost's effort is completely orthogonal to what Blargg's libraries do. Blargg has concentrated on reproducing quirks of the NTSC television decoding process, and has nothing in common with emulating deficiences of CRT TV sets. On the other hand, Ian's project aims to replicate those deficiences (RGB dot pattern, afterimages, color bleed, RF noise), at the same moment ignoring any intricacies of the NTSC system (or any TV system at all) completely.

 

I think it would actually be better for those two projects to stay separate and don't mix their focuses. No need to duplicate other's work. Both effects could be combined then - applying Ian's filters to a screen processed previously by Blargg's would give interesting results, wouldn't it.

 

Stephen, I advise you to look into Atari800's source. Blargg's filter has been implemented there over three years ago, and it gives really nice results. Both Atari 800 and 2600 produce screen in a similar way (128/256 colours, each pixel is exactly 1 colour clock wide), so copying the code into Stella would give pretty accurate results without any adjustments.

Edited May 24, 2009 by Kr0tki

[+stephena]

It would be great if the end results looked like Blargg's NTSC Libraries, here:

 

http://slack.net/~ant/libs/ntsc.html

 

kat5200 has incorporated an NTSC filter - and it really is fantastic. As shown in the link above there has been NTSC filters incorporated in various other system emulators (including Nestopia). It would be great to see an Atari 2600 emulator and an Atari 7800 emulator with such an effect.

 

All the best with this endeavor, ibogost. I'm looking forward to the end results.

 

-Trebor

From what I see, Ian Bogost's effort is completely orthogonal to what Blargg's libraries do. Blargg has concentrated on reproducing quirks of the NTSC television decoding process, and has nothing in common with emulating deficiences of CRT TV sets. On the other hand, Ian's project aims to replicate those deficiences (RGB dot pattern, afterimages, color bleed, RF noise), at the same moment ignoring any intricacies of the NTSC system (or any TV system at all) completely.

 

I think it would actually be better for those two projects to stay separate and don't mix their focuses. No need to duplicate other's work. Both effects could be combined then - applying Ian's filters to a screen processed previously by Blargg's would give interesting results, wouldn't it.

 

Stephen, I advise you to look into Atari800's source. Blargg's filter has been implemented there over three years ago, and it gives really nice results. Both Atari 800 and 2600 produce screen in a similar way (128/256 colours, each pixel is exactly 1 colour clock wide), so copying the code into Stella would give pretty accurate results without any adjustments.

You must have read my mind. That is exactly the approach I plan to take. Adding Blargg filtering will in no way diminish the work already done on CRT simulation, but nicely complement it, I think. I'll look into the Atari800 source soon, to get an idea of exactly how much work is involved in adding it to Stella.