Page 4 of 5

Re: CRT luminofor fading simulation

Posted: Sat Jun 22, 2013 9:40 pm
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

Re: CRT luminofor fading simulation

Posted: Sat Jun 22, 2013 9:47 pm
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.

Re: CRT luminofor fading simulation

Posted: Sat Jun 22, 2013 9:56 pm
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.

Re: CRT luminofor fading simulation

Posted: Sat Jun 22, 2013 10:05 pm
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).

Re: CRT luminofor fading simulation

Posted: Sat Jun 22, 2013 10:14 pm
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.

Re: CRT luminofor fading simulation

Posted: Sat Jun 22, 2013 11:11 pm
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

Re: CRT luminofor fading simulation

Posted: Sun Jun 23, 2013 6:28 am
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.

Re: CRT luminofor fading simulation

Posted: Sun Jun 23, 2013 7:53 am
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?

Re: CRT luminofor fading simulation

Posted: Sun Jun 23, 2013 9:45 am
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.

Re: CRT luminofor fading simulation

Posted: Sun Jun 23, 2013 10:45 am
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)

Re: CRT luminofor fading simulation

Posted: Mon Jun 24, 2013 6:24 pm
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.

Re: CRT luminofor fading simulation

Posted: Mon Jun 24, 2013 7:44 pm
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.

Re: CRT luminofor fading simulation

Posted: Tue Jun 25, 2013 7:21 am
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!

Re: CRT luminofor fading simulation

Posted: Tue Jun 25, 2013 12:30 pm
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 7289 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.

Re: CRT luminofor fading simulation

Posted: Tue Jun 25, 2013 5:19 pm
by Zepper
See something different this time? ;)