CRT luminofor fading simulation

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

User avatar
mikejmoffitt
Posts: 1353
Joined: Sun May 27, 2012 8:43 pm

Re: CRT luminofor fading simulation

Post by mikejmoffitt »

zzo38 wrote:Is it possible with ImageMagick to make something like this?
I don't know; I could just write down in order what I did to produce the effect but I don't know a thing about shaders or what imagemagick is. Anyone can reproduce this with a batch script for an image editor.

I've tweaked it a little, and it's better. Now the lines do look a bit thicker for brighter areas than dimmer ones:

Image
zzo38
Posts: 1096
Joined: Mon Feb 07, 2011 12:46 pm

Re: CRT luminofor fading simulation

Post by zzo38 »

mikejmoffitt wrote:
zzo38 wrote:Is it possible with ImageMagick to make something like this?
I don't know; I could just write down in order what I did to produce the effect ...
If you please provide such an information then it can help.
(Free Hero Mesh - FOSS puzzle game engine)
User avatar
mikejmoffitt
Posts: 1353
Joined: Sun May 27, 2012 8:43 pm

Re: CRT luminofor fading simulation

Post by mikejmoffitt »

zzo38 wrote:
mikejmoffitt wrote:
zzo38 wrote:Is it possible with ImageMagick to make something like this?
I don't know; I could just write down in order what I did to produce the effect ...
If you please provide such an information then it can help.
Sure, I'll take a little while to write it up.
User avatar
rainwarrior
Posts: 8731
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: CRT luminofor fading simulation

Post by rainwarrior »

mikejmoffitt: In many of my projects after writing a screenshot command, I often write a "perfect 60hz" capture mode that dumps frames and audio (i.e. 44100/60=735 samples of sound per frame) with a fixed internal framerate (disregarding actual display rate), which makes it very easy to make nice clean video (which is also helpful for debugging sometimes). VirtualDub has a way to auto-concatenate a stream of sequentially named images, so you don't even have to funnel it into an AVI stream yourself or anything (though that itself can be pretty easy too, e.g. Windows' crusty VFW API).
User avatar
mikejmoffitt
Posts: 1353
Joined: Sun May 27, 2012 8:43 pm

Re: CRT luminofor fading simulation

Post by mikejmoffitt »

rainwarrior wrote:mikejmoffitt: In many of my projects after writing a screenshot command, I often write a "perfect 60hz" capture mode that dumps frames and audio (i.e. 44100/60=735 samples of sound per frame) with a fixed internal framerate (disregarding actual display rate), which makes it very easy to make nice clean video (which is also helpful for debugging sometimes). VirtualDub has a way to auto-concatenate a stream of sequentially named images, so you don't even have to funnel it into an AVI stream yourself or anything (though that itself can be pretty easy too, e.g. Windows' crusty VFW API).
I probably should implement some form of screenshot into my game, I just have to see if Allegro has an easy way of doing this.
User avatar
mikejmoffitt
Posts: 1353
Joined: Sun May 27, 2012 8:43 pm

Re: CRT luminofor fading simulation

Post by mikejmoffitt »

It continues to substantially improve, after a friend's comment and suggestion made it much more efficient as well as authentic looking:

Image
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: CRT luminofor fading simulation

Post by tepples »

mikejmoffitt wrote:
tepples wrote:If you save every frame of raw RGB pixel data to a file as you generate it, you can pipe it through FFmpeg with zero dropped frames.
This sounds tedious, unless scripts are readily available with little to no setup that will run on Windows. I am not booting linux for this.
My own game engine written in Pygame does this saving as easily on Windows as it does on Linux. FFmpeg does not distribute official binaries for Windows because of patent problems, but they are available if you know where to look.
Plus, I am not aware of a function Allegro has that will let me easily save the backbuffer as a file.
I guess I'm spoiled by Pygame, which has the utility module pygame.image that translates a memory buffer into a string. But what you can do in Allegro is finish rendering and then call save_bitmap (or however it was renamed in recent Allegro) to write to a single file. Or you can blit the render surface to a 24-bit bitmap and write each scanline.
This sounds like filesystem havoc as too...
If you write all the individual 24-bit frames to a single file one after another, you can then pass the filename of that file, the width, the height, and whether the file is RGB24 or BGR24 to FFmpeg.
User avatar
mikejmoffitt
Posts: 1353
Joined: Sun May 27, 2012 8:43 pm

Re: CRT luminofor fading simulation

Post by mikejmoffitt »

tepples wrote:
mikejmoffitt wrote:
tepples wrote:If you save every frame of raw RGB pixel data to a file as you generate it, you can pipe it through FFmpeg with zero dropped frames.
This sounds tedious, unless scripts are readily available with little to no setup that will run on Windows. I am not booting linux for this.
My own game engine written in Pygame does this saving as easily on Windows as it does on Linux. FFmpeg does not distribute official binaries for Windows because of patent problems, but they are available if you know where to look.
Plus, I am not aware of a function Allegro has that will let me easily save the backbuffer as a file.
I guess I'm spoiled by Pygame, which has the utility module pygame.image that translates a memory buffer into a string. But what you can do in Allegro is finish rendering and then call save_bitmap (or however it was renamed in recent Allegro) to write to a single file. Or you can blit the render surface to a 24-bit bitmap and write each scanline.
This sounds like filesystem havoc as too...
If you write all the individual 24-bit frames to a single file one after another, you can then pass the filename of that file, the width, the height, and whether the file is RGB24 or BGR24 to FFmpeg.
al_save_bitmap looks to be in Allegro 5, so I think I will go ahead and put that in. Good call.

I guess I really should have called it solid-state write cycles hell; I was referring to writing a new file every 1/60th of a second to the drive.

As for PyGame, I used it for a while, but stopped because I could not reliably get it to wait for vertical blank before flipping to the display buffer. As a result I could not time the game to Vblank, which is what I had wanted to do. Do you know of a way to get PyGame to do this?
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: CRT luminofor fading simulation

Post by tokumaru »

mikejmoffitt wrote:I guess I really should have called it solid-state write cycles hell; I was referring to writing a new file every 1/60th of a second to the drive.
You don't have to run the game in real time though, you can slow it down for video recording.
User avatar
Zepper
Formerly Fx3
Posts: 3262
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Re: CRT luminofor fading simulation

Post by Zepper »

Here's my recordings (no audio, crap).
http://www.youtube.com/watch?v=Ve_IoAHocFc (blue-ish effect)

http://www.youtube.com/watch?v=uIWj_RV8NEM (normal decay)
Sik
Posts: 1589
Joined: Thu Aug 12, 2010 3:43 am

Re: CRT luminofor fading simulation

Post by Sik »

tokumaru wrote:You guys keep posting images, but to actually appreciate these effects we need video!
And YouTube won't be enough, because once the effect is done right it's going to take too few frames to be appreciated (we need the full 60FPS, we can't do with 30FPS), and even then, YouTube will most likely completely ruin the quality (since it'd rely on subtle details).

I recall once (long ago) doing a test and the conclusion being that a white dot against a black background will stay at most 1/12th of a second on screen (possibly less), and I don't know how much of that was CRT lag and how much was eye persistence. Moreover, this was a PC monitor, no idea how different are TVs in that sense.

Make what you want out of that, but basically trails shouldn't last longer than a handful of frames at most.
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: CRT luminofor fading simulation

Post by lidnariq »

When I've recorded video of my CRT TV using a medium-high-speed (240fps) camera, I see no significant ghosting.

So I took a CR2 of my screen. 1/2000th exposure, F/2, ISO-equiv 80 (i.e. minimal denoising). I played around with it in cinepaint for a bit. Asked for a linear decode, and pushed the contrast until I could manually calculate the halflife over several periods. By pushing the exposure (which currently shows the active region at about 75%FS), I had to push the exposure up by a factor of about 20 (or 4.5 stops, or 4.5 halflives) to compensate.

With the final version of phosphors used in CRTs in the US before the transition to LCD sets, ghosting simply does not happen. The halflife is FAR too short.

This is not to say that there won't exist CRTs that don't do this! Just that the CRTs that most of us in the USA have seen didn't.
Last edited by lidnariq on Tue Jun 25, 2013 12:39 pm, edited 1 time in total.
User avatar
mikejmoffitt
Posts: 1353
Joined: Sun May 27, 2012 8:43 pm

Re: CRT luminofor fading simulation

Post by mikejmoffitt »

lidnariq wrote:When I've recorded video of my CRT TV using a medium-high-speed (240fps) camera, I see no significant ghosting.

So I took a CR2 of my screen. 1/2000th exposure, F/2, ISO-equiv 80 (i.e. minimal denoising). I played around with it in cinepaint for a bit. Asked for a linear decode, and pushed the contrast until I could manually calculate the halflife over several periods. By pushing the exposure (which currently shows the active region at about 75%FS), I had to push the exposure up by a factor of about 20 (or 4.5 stops, or 4.5 halflives) to compensate.

With the final version of phosphors used in CRTs in the US before the transition to LCD sets, ghosting simply does not happen. The halflife is FAR too short.

This is not to say that there won't exist CRTs that don't do this! Just that the CRTs that most of us in the USA have seen didn't.
Try playing your CRT in pitch dark with a game like Gradius - you will see the trails!
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: CRT luminofor fading simulation

Post by lidnariq »

Fair enough! I tested with Galaxian, and see 3.7 halflives per 1/60th of a second, or a halflife of 4.5ms. This means that the correct constant (with this TV) for the expression I gave above is k=1/13. This is low enough that on the NES, the effect will only ever be visible when transitioning to black pixels. So here's an animated gif, simulating same:
anim.gif
anim.gif (15.52 KiB) Viewed 7287 times
It's really subtle, especially without any of the phosphor size blur. You'll also want to enlarge it; I can't see anything when it's at 100dpi.

And after manually capturing 17 frames from FCEUX, here's how I processed it:

Code: Select all

for i in `seq 0 16`; do 
 pnmarith -maximum $i.ppm previous.ppm > n$i.ppm;
 ppmtogif n$i.ppm > n$i.gif;
 pnmgamma -ungamma 2.2 n$i.ppm | ppmdim .077 | pnmgamma 2.2 > previous.ppm;
done
pnmcat -tb n*.ppm | ppmtogif > all.gif
gifsicle --use-colormap all.gif -O3 -V -o anim.gif -d2 n{0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16}.gif
Note that I'm fixing up the gamma; if I hadn't, it'd be even harder to see.

I suspect that standard 24-bit displays are not actually deep enough to show this in a compelling way; after two refreshes (1/13)² even full scale content is just 1 LSB.
User avatar
Zepper
Formerly Fx3
Posts: 3262
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Re: CRT luminofor fading simulation

Post by Zepper »

See something different this time? ;)
Attachments
demo3b.png
demo3.png
Post Reply