News for hackers. Stuff that matters.
Re:Color Emulation by simias on Friday September 13, 2019 @04:57AM (#20960369)
Accurate screen emulation is important for many retro games, and not just because of color issues. For instance the GameBoy didn't support transparency so some clever devs would make sprites blink very fast to make them appear transparent. Since the GameBoy screen had a fairly slow response time the ghosting would effectively blend the sprite with the background. If you emulate the game on a modern low-latency monitor you just get a flickering sprite. See for instance the claw's shadow in this gameplay video for Link's Awakening: https://youtu.be/UQlP9sHf5Ho?t=825 (although this video is way worse that what you'd see in an emulator because the framerate of the video doesn't line up with the GB's ~60fps display, so it doesn't even flicker all the time).

An other example is games using the blurriness of analog video signals to blend things together: https://www.retrorgb.com/hd-retrovison-shows-transparency-co...

Basically you interlace two images at a high enough frequency and let the analog artifacts blend them. Once again doing playing that on a modern LCD screen without post-processing ruins the effect.

Re:Color Emulation by tobr on Friday September 13, 2019 @05:36AM (#20960553)
Has anyone tried to simply point a camera at an old screen, say a CRT screen, take a photo of one pixel at a time at a few different levels of brightness, then add all the photos together to render arbitrary images? As far as I can imagine, it should capture the behavior of colors and the fuzzyness between pixels very well. You could even set up a small still life around the monitor, and get accurate reflections and ambient light in the room.

Stuff like the smoothed out flickering that you mention would still need to be emulated, of course.

Re:Color Emulation by leni536 on Friday September 13, 2019 @08:24AM (#20961433)
It's actually a great idea, assuming that background light levels are properly taken care of and the camera is well calibrated to a linear colorspace. Unfortunately "pixels" don't really blend linearly when transferred over a composite cable and there are some games that use NTSC artifacts to achieve certain colors.
Re:Color Emulation by cr0sh on Friday September 13, 2019 @04:15PM (#20966035)
While not really what you're asking about - how about fractals using video feedback (essentially analog fractal computation):

https://www.youtube.com/watch?v=Jj9pbs-jjis

Re:Color Emulation by aidenn0 on Friday September 13, 2019 @03:26PM (#20965483)
Brightness is a non-local effect. i.e. if you change one pixel, the rendering of the adjacent pixels can change.

Also, the rendering is different depending on how the signal made it into the CRT; in particular composite video does not preserve certain things about the image, and in some cases developers took advantage of this/

Most famously the genesis had a poor composite encoder, which was taken advantage of by many games; Sonic 3 in particular looks bad even on a CRT with a real Genesis if you use RGB or component output.

Re:Color Emulation by zellyn on Friday September 13, 2019 @07:14PM (#20967639)
Even color is a non-local effect. Turning two colored pixels on side-by-side on an Apple II makes them white. I can give you an unbounded amount of detail why :-)

https://zellyn.github.io/apple2shader/

Re:Color Emulation by grenoire on Friday September 13, 2019 @05:41AM (#20960572)
There are shaders to render such 'artifacts' programmatically at about a thousandth of the cost of what you describe. It could potentially be more accurate in the way you describe it, but then what kind of blending mode do you use?
Re:Color Emulation by tobr on Friday September 13, 2019 @05:54AM (#20960626)
I think you would first find the two closest brightness levels for each pixels, and blend appropriately between them - then simply use additive blending to composite all the pixels together. A naive approach would require compositing as many images as the number of pixels in the input signal, which seems extremely expensive, but in practice I’m sure you could optimize it quite a bit, as most of the area of each photo would be almost completely black.
Re:Color Emulation by grenoire on Friday September 13, 2019 @06:31AM (#20960783)
If you can arrange lighting perfectly in your CRT studio, you could take only the difference against the all-off state. You could extract the pixel islands' positions and composite only these smaller chunks afterward.

It could work out, but just not sure if it's worth all the hassle. It seems akin to the way you would do a stop-motion video, I suppose.

Re:Color Emulation by tobr on Friday September 13, 2019 @06:38AM (#20960833)
You would need to be in a pitch black room with only one pixel at a time lighting the scene. If you want additional light sources in the room they could be photographed and blended in with the same technique.
Re:Color Emulation by grenoire on Friday September 13, 2019 @08:55AM (#20961626)
"You could even set up a small still life around the monitor, and get accurate reflections and ambient light in the room."

I think this would be a final additive pass after the pixel setup. Would also allow you to turn it off selectively...

The more I think about it the more I want to try it out.

Re:Color Emulation by tobr on Friday September 13, 2019 @09:50AM (#20962114)
I think you would need to get the reflections in the same pass. It’s basically ray tracing in real life: emit light from a bunch of points (screen pixels), “calculate” how they bounce through the room (ie adjust the brightness of the corresponding photo), and combine them all into a single image.
Re:Color Emulation by lostgame on Friday September 13, 2019 @11:48AM (#20963160)
This is brilliant. I’d just love to see what this would look like.
Re:Color Emulation by arayh on Friday September 13, 2019 @12:33PM (#20963614)
ZAS is a good example of blinking backgrounds quickly to introduce more complex backgrounds:

https://cloud.githubusercontent.com/assets/16804570/21383939...