Posted: 6/5/2014 9:52 PM
Post subject: CRT emulation with scanline and phosphor effects
Quote
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
http://forum.doom9.org/showthread.php?p=1683051 [QUOTE=cretindesalpes;1683051]Download: crt_display v1.0 This function emulates a CRT display using aperture grille (Trinitron) or Cromaclear technologies. It is slow but gives interesting results. Could be nice to chain after a NTSC defect emulator like dotcrawlplus. It implements various features like:
  • Works at any (non-integer) upscaling factor
  • Various way of adjusting the scanline thickness and beam shape
  • Low-pass filtering of the input signal
  • Specific gamma target
  • Beam glow
  • Optional colored phosphor effect and shadow mask
  • Automatic contrast adjustment
  • Halation
  • Very large upscale is possible, showing the grid of phosphors.
Requirements: Dither 1.26.0 or above and its dependencies, Avisynth 2.6, RGB colorspace. Detailed instructions in the .avsi file. Prototype: 
Function crt_display (clip src, float sw, float sh, float "voff", float "ppp",
\	float "cutoff", float "scandist", float "sharpv", float "sharph",
\	float "blurh", float "glowgain", float "glowh", float "glowv",
\	float "glowsens", float "contrast", float "gamma", float "softclip",
\	float "mix", float "beamshape", bool "phosphor", bool "pgrid",
\	float "vcs", float "cromaclear", float "maskpp", float "gainb",
\	float "halgain", float "halrange", string "pixel_type")
Examples of real NTSC footage with aperture grille (left) and cromaclear shadow mask (right): 
ar = 10.0 / 11.0
crt_display (2*ar, 2, ppp=1*ar, blurh=2.0) # Left
crt_display (2.5*ar, 2.5, ppp=1.25*ar, maskpp=1.25, cromaclear=1.0, voff=0.25) # right
It works very well for upscaling old-school videogame captures: Sources, point-resized: I don’t know at which gamma these pictures should be viewed so I kept them untouched like if they were in standard sRGB. Cromaclear display type: 
ar = 8.0 / 7.0
crt_display (5*ar, 5, ppp=2.5*ar, blurh=1.0, maskpp=2.5, cromaclear=1, scandist=1.5, cutoff=0.9, glowgain=0.125, halgain=0.03)
Aperture grille display type: 
crt_display (5*ar, 5, ppp=2.5*ar, blurh=0.75, maskpp=2.5, scandist=1, cutoff=0.9, glowgain=0.125, halgain=0.03)
Simple scanlines without phosphor effect: 
crt_display (5*ar, 5, ppp=2.5*ar, blurh=1.0, maskpp=2.5, phosphor=false, scandist=3, cutoff=0.8, glowgain=1.0, glowh=6, glowv=0, halgain=0.03, sharpv=2)
More screenshots here. Default settings are generally OK, but tweaking the parameters can improve the results a lot. My 15 kHz CRT is gone for a long time and I only have half-decent monitor photos for reference, so advices based on real CRTs are welcome to improve the emulation.[/QUOTE]
Posted: 6/6/2014 8:41 AM
Quote
Warp
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
Why would you want to deliberately introduce defects into the video that were originally caused by limited display hardware? (Other than, maybe, nostalgia.) I do understand that the graphics of a few games were actually designed with the NTSC artifacts in mind (I believe Castlevania 2 is an example), but still...
Posted: 6/6/2014 8:50 AM
Quote
Patashu
He/Him
Joined: 10/2/2005
Posts: 4017
Warp wrote:
Why would you want to deliberately introduce defects into the video that were originally caused by limited display hardware? (Other than, maybe, nostalgia.) I do understand that the graphics of a few games were actually designed with the NTSC artifacts in mind (I believe Castlevania 2 is an example), but still...
Kind of like saying 'Why deliberately emulate lag that was caused by the limited processing power of the original console, and not the intentions of the developers?'
My Chiptune music, made in Famitracker: http://soundcloud.com/patashu My twitch. I stream mostly shmups & rhythm games http://twitch.tv/patashu My youtube, again shmups and rhythm games and misc stuff: http://youtube.com/user/patashu
Posted: 6/6/2014 10:32 AM
Quote
Warp
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
Patashu wrote:
Kind of like saying 'Why deliberately emulate lag that was caused by the limited processing power of the original console, and not the intentions of the developers?'
It's not the same thing at all. NTSC artifacts have no effect on the timing of the run. The only thing they do is decrease visual quality for no purpose. (And the vast majority of games were not designed around those artifacts, so there is no reason to subject the games to them.)
Posted: 6/6/2014 11:06 AM
Quote
Bisqwit
Editor, Active player (296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
I just like the one on the left better, and it's not because it's from an emulator I wrote in QuickBASIC...
Posted: 6/6/2014 11:30 AM
Quote
RGamma
Joined: 2/3/2013
Posts: 320
Location: Germany
Warp wrote:
... nostalgia ...
There's your answer. We wouldn't pick this for usual encodes because it makes encoding the video less efficient. Other than that, I like what it's looking like. If you then can somehow disguise the fact, you're playing on a flatscreen monitor with a modern gamepad (which is the usual setup, I assume), one can get a very authentic feeling even without authentic hardware. The CRT filter helps this a lot IMHO. Edit: This is an AVISynth filter, so above paragraph doesn't really apply.
All syllogisms have three parts, therefore this is not a syllogism.
Posted: 6/6/2014 4:42 PM
Quote
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
Raw emulator output is not very useful for players - you only really need it if you are debugging the emulator or related software (like savestate tools), hack ROMs, or want to do things like sprite sheets. (Technically the raw output doesn't even include things like display width or height, it's just a really long list of color values. If emulators would simply just render each value to a pixel, games like Secret of Mana would appear like this. NES / Vectrex games can't be displayed directly at all, because they're not using RGB color channels / pixels.) The next step is aspect ratio correction. Games on a TV are stretched to a 4:3 ratio (unless you have a widescreen one) and games expect that. On a PC you'd need a 1792x1344 display for SNES games (512x448) to avoid any kind of interpolation or uneven rows/columns. So there's the usual choice from bilinear to spline interpolation where you end up somewhere on the blurry <-> haloing/ringing scale. CRT filters are a step up because they add accuracy and can look better. Games like Jurassic Park and Kirby's Dreamland 3 need some sort of filter to render their graphics correctly. Some systems like the NES look off without NTSC and/or CRT emulation - NES "palettes" can never be 100% accurate. And finally, the CRT emulation adds some "texture" to the pixels that makes them look much more interesting, imo.
Posted: 6/7/2014 10:19 AM
Quote
amaurea
Former player
Joined: 2/19/2007
Posts: 424
Location: UK
creaothceann wrote:
The next step is aspect ratio correction. Games on a TV are stretched to a 4:3 ratio (unless you have a widescreen one) and games expect that.
I'd say that non-square pixels is also a hardware defect, and not necessarily what the developers were looking at when programming the game on their computer screens. For example, the morphing ball in Super Metroid is 16x16 pixels large, making it exactly spherical if displayed with square pixels. If the pixels are stretched to give the screen a 4:3 aspect ratio, it turns into an ellipsoid. The same applies to the 24x24 neutral wheel sprite from Kirby Super Star. And the ferris wheel from Yoshi's topsy turby. In fact, when searching for wheel or circle sprites from snes games, all the ones I looked at assumed square pixels.
Posted: 6/7/2014 1:23 PM
Quote
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
amaurea wrote:
I'd say that non-square pixels is also a hardware defect, and not necessarily what the developers were looking at when programming the game on their computer screens. For example, the morphing ball in Super Metroid is 16x16 pixels large, making it exactly spherical if displayed with square pixels. If the pixels are stretched to give the screen a 4:3 aspect ratio, it turns into an ellipsoid.
It's not a hardware defect, it's just a property of the system. Btw. developers were working on various systems: - PC (Blizzard's / Factor 5's custom solutions) - Amiga (which has lots of non-square pixel resolutions) - SF-BOX (with PC-9801 / Sony workstation) - SNES Emulator SE (picture) - IS-Debugger - etc. The NTSC standard doesn't even have a concept of pixels, it only describes lines. The TV simply sweeps horizontally over the screen and whatever signal is on the input ends up on the screen. Since this is all analog, you can have 512 equal-sized dots per line - or 511, or even 457 (a prime number). The number of distinct pixels depends on how often the input is changed per line. Developers/artists were looking at both their screens and the TV, and it's hard to miss the non-square "pixels" on TV for large objects. For small objects like the morphing ball it's more important to use all the pixels available in that small space.