WIP RetroTV Effect Suite

RetroTV Effect Suite is an in-progress set of effects and shaders designed to help you in giving your game a very nostalgic retro flair.
RetroTV effects aren't just made to be "inspired by" older games. I spent the time and effort researching exactly *why* old games looked the way they did. And with this knowledge I set out to recreate the same effects as accurately as I could, for the most authentic retro experience you can get in Unity.

Get it on Github!

Authentic NTSC television emulation
The included CRT Effect script performs accurate emulation of the way RGB colors were turned into a composite signal and then decoded back into RGB on the screen.
It really looks like you're playing the game on a CRT television because it works essentially the same under the hood.

Before and after images of the effects applied to a screenshot from an emulator. Animated GIF version here​

Old-school wobbly meshes
Old 3D games had a lot of wobbly meshes, from the SuperFX chip used in some SNES cartridges all the way to the PlayStation 1. Recreate this effect instantly with the included PS1Object shader. It even includes the same texture mapping artifacts as the PS1 for ultimate authenticity.

The PS1Object effect in action. Notice the popping on the Robot character, and the wobbly texture on the ground.​

Color LUT generator
Want to restrict your game to a limited number of bits per color? Use the included Color LUT generator. You can just enter the number of bits per channel and hit Generate for a ready-made color LUT which can be plugged right into the stock Color Correction effect.
Or, go even farther - the color LUT is generated from a virtual digital-to-analog electronic circuit which can be tweaked. Your color LUT can be the result of an actual theoretical video circuit!

Before and after of a 4-bit per channel color LUT applied.
​

I'd like to make this package as extensive as possible. If there's any features you'd like to see, or if you have some feedback about what I've got here, please don't hesitate to let me know

 

Put together a little demo showing off the CRT effects. A sidescrolling SHMUP style demo

https://dl.dropboxusercontent.com/u/99106620/vid/ShmupDemo.mp4

Background music "Hearts Are The Weakest Shape" used with permission from https://soundcloud.com/thespoonybard

 

I've been working on the UI for the effect script inspector and consolidating multiple features into one effect using multi compiled shaders.
Additionally, I have added two new effects - it's possible to use a multiplied overlay texture now for the screen edges, and additionally a rolling flicker effect has been added to simulate what happens when a camera films a TV and the two have different refresh rates. Also, I have slightly tweaked the TV distortion effect so that it pulls the corners in instead of pushing the edges out, so the CRT distortion is a bit more intuitive now.

 

Today I completely reworked the inspector interface and additionally added a brand-new feature - video modes!
You can now pick one of the following modes to use:

• Composite
• S-Video
• Component
• VGA/SCART

Composite of course has the most blurring and artifacting. S-Video separates out the luma signal which makes the image much cleaner. Component separates out all three Y, I, and Q color components for a completely clean look. Finally, VGA/SCART just uses plain old RGB.

Video of the new video mode support in action (for best results please watch fullscreen 1080p):

 

A little update...
So I've actually fixed a bit of an issue in the CRT Effect. If you notice in the last video, switching from Component to VGA highlighted a bit of a shift towards brown in the whole palette when using everything except for VGA (basically, any of the video modes using the YIQ color space).
Originally, I had chalked this up to color gamut differences between YIQ and RGB, but then when I added support for using matrices to do the conversion instead of lookup textures the color shift vanished. It turns out my color LUTs were slightly wrong. That being said, instead of correcting the LUTs I decided to scrap them entirely. Fixing them is trivial, but after a chat with some helpful people on the Unity IRC, the LUTs weren't nearly as good an idea as I had thought before - best case scenario, you're on a platform where the difference between a LUT and a straight matrix multiply isn't even measurable, worst case scenario you're on a platform where the LUT either isn't even supported or, even if it was, would introduce a very cache-unfriendly dependant texture read (imagine black and white pixels next to each other - they're on opposite ends of the color cube. so that leaves you with both a cache miss AND a texture read).
So now it just uses a matrix multiply. The color differences are much subtler now. In fact, Component and VGA/SCART modes are nearly identical now (in most cases, I can't see any difference).

On another note, I'm thinking of including several guides with this product, the idea being if you want to make a game really look like it's running on an old system it's best to know what limitations you'd have to deal with on those systems. So there'd be guides for many major console systems included, detailing audio and graphical limitations and what to keep in mind when developing with Unity (since it can be so easy to accidentally break those limitations). They should be a good resource in replicating the look and feel of older systems.

 

This is great. I love the accuracy

 

Thanks
I wanted this to look as close to the real thing as possible, especially the TV effect. I figured there was no better way to do that than to replicate how the signals actually work under the hood, rather than just make an effect that's loosely inspired by what I remember them looking like.

 

Ever wanted to know what the Unity Roguelike demo would have been like as a bootleg MegaDrive game? No? Too bad, cause here it is!
Featuring:

• Glorious 9-bit color!
• Lo-fi composite NTSC video!
• A godawful remix of the Unity Roguelike music for the MegaDrive because I suck at music!
• Mac/Windows versions!

Download it here: http://jetfistgames.com/Demos/RetroTVFX/RetroTVRoguelikeDemo.zip

 

Just tested RetroTV FX for WebGL compatibility - it's 100% compatible! Here's that SHMUP demo I made, 100% playable in a browser. Tested in Chrome and FIrefox (use Firefox for improved performance):

http://jetfistgames.com/Demos/RetroTVFX/SHMUPDemo/

 

Wow, that is awesome! Just one thing. Are you planning on doing RF mode? That's what I really want

 

Hm, interesting. I hadn't thought about supporting RF, even though I actually primarily used an RF connector for most of my PS2 gaming

Seems to me RF might be slightly more difficult to accurately emulate than the other standards included, not least of which because RF is also supposed to carry audio signals (which I can't do from a shader, naturally). However, as far as I can tell RF still works somewhat similarly to Composite, with the addition of modulation/demodulation for carrying it over radio frequencies. In the end, it's blurrier than Composite and is also subject to noise. Therefore, I could add an option to increase blurring in Composite mode and add an extra noise pass on top of the generated signal. I'll probably give this some experimentation and see what I can come up with.

 

Replying to 3noneTwo from the other thread...

Yup, I see a lot of those too. And it's always "hey, look, this looks sort of like a CRT!" but, having actually used one extensively, it just doesn't even look remotely close to me.

Actually, the VGA LUT thing is actually not that noticeable. I'm actually thinking of scrapping it - the result is nearly identical to just doing a simple quantize, and also requires the use of a 3D LUT which locks out certain platforms. In the Roguelike demo above, I used a simpler quantize method to produce 9-bit color. With this feature you just specify bits per channel in the inspector and it handles the rest.

As far as customization, some things are limited. Color smearing can be played around with, there's two constants defined in a RetroTV.cginc file which are COMPOSITE_LOWPASS and SVIDEO_LOWPASS. Unfortunately those both are pretty fiddly, it's easy to accidentally render the entire screen grayscale with some values. That said, anywhere between 0.5 and 1.5 seems to work fine, so I could potentially expose that range to the inspector. You can also tweak horizontal blurring with display resolution though (more explained later).

Also, I haven't implemented any form of aspect ratio locking, but you can definitely lock the video resolution! There's an effect in there which lets you specify a game resolution. Right now internally it creates its own camera which renders to that resolution, although I'm thinking of scrapping that and letting you just specify your own camera (or array of cameras, in the case of split screen perhaps?). Also, you can specify the display resolution of the TV. By default it's set to 960x480 (as mentioned above, you can set the horizontal width higher to limit horizontal blurring - so set it to 640x480 for example for a high amount of blurring, or 1280x480 to reduce blurring).
I'll take a look and see if it's possible to lock the aspect ratio and center the TV image on the screen. Right now it just stretches to fill the screen.

 

The game resolution effect sounds very useful, especially for 2D games aiming for that pixel-perfect appearance. As long as it still works alongside other camera assets (eg: Camera Perspective Editor, Pro Camera 2D) and the effect's output remains consistent regardless of users' full-screen/windowed resolutions, it should be enough! (For single player at least)

Display resolution sounds like it's set up to control pixel interpolation? It's interesting, definitely useful for fine-tuning CRT effects, as well as softening up the composite video a little.

Looking over the thread more carefully, there's only a couple extra features I can think of that haven't already been addressed:
1. For 3D games: A camera effect that sets it up with a target display aspect ratio, samples the camera frame at a specific render resolution, and then *stretches the sampled frame back to the target ratio. Think PS1 games with resolutions like 512×240 (non-interlaced) or 256×480 (interlaced) targeting 4:3 on TVs, or N64 games that could switch between 3:2 and 16:9 target ratios while rendering at 320×240.
* It'd probably make more sense for the CRT Effect to do the stretching step. Hell, this step might already be covered by its Display Size options.

2. Pixel Aspect Ratio. A bunch of older consoles (NES, SNES, Game Gear, etc) had a pixel aspect ratio of 8:7, so the output was always slightly wider than native resolution. Many would probably prefer to stick to 1:1 PAR by default, but it's nice to have the option for authenticity's sake.


I was going to suggest a "Pixel Perfect Display" option, for people who'd want the game to be displayed at perfect multiples of the game's internal resolution (on top of being pixel-perfect by design), but I'm not sure if it's suitable for the suite? There's other assets out there that can handle pixel-perfect multiples in the meantime (2D Toolkit offers a fairly comprehensive custom camera), so: eh.

Either way, I'm excited to see how this asset evolves, it's looking awesome.

 

The lo-res effect should work 100% with other assets. All it does is create an internal render texture sized so a specific resolution (by default 320x240), then sets the game camera to render to that texture and then blits it to the screen (so, instead of just scaling down the screen, it actually renders to that resolution). As long as an asset can handle rendering a camera to a texture, it should work with no problems.

1.) Maybe, in line with what was said previously about an option to not fill the entire screen, it could be possible to just specify an aspect ratio to display the final "screen" at? Then you could essentially have your game render at for example 256x240, and then specify that it renders at 4:3 aspect ratio scaled to fit within the screen. Though at the moment it just stretches the internal resolution to fill the entire screen, which can be seen if you fullscreen either of the demos I've uploaded.

2.) Would the above option fulfill the pixel aspect ratio feature?

3.) Not sure if that's even necessary TBH. You could just pick multiples of the internal render resolution yourself, right? Unless I'm missing something. And the main thing it would affect is the pixel mask overlay more than anything else.

 

That'd do the trick! What you said for #1 sounds pretty much like what I was thinking: Give the camera an aspect ratio and a resolution to render into, and then a display aspect ratio to stretch back out to. If it could allow for arbitrary aspect ratios in some way, then yeah, #2 would be fulfilled as well.

 

Alright, well I've now exposed two options. The Lo-Res Effect has an "Override Aspect" function, and an aspect ratio. If Override Aspect is unchecked it just uses the aspect ratio of the resolution you specified (so if you use 320x240 for example it renders at 4:3 aspect ratio), but you can check it and specify a custom aspect ratio instead. It probably shouldn't be used for pixel-perfect games since it will scale the view horizontally and ruin the pixel-perfect alignment, but can be used for 3D games.
Additionally, CRT Effect now has a "Stretch To Screen" option. It's on by default which makes the virtual screen stretch to fill the window or screen, but you can disable it and specify a custom aspect ratio. In that case it sizes the virtual screen to your custom aspect ratio and scales it to fit within the window or screen (sort of like how the Gameboy Advance let you toggle between stretch modes with the bumpers while playing Gameboy or Gameboy Color games)

I'll probably post some screenshots later.

 

I would love to test this out so I can give some proper feedback

 

Some screenshots of the new options I've exposed.

Here's "Stretch To Screen" disabled, with an aspect ratio of 1.33 specified. In this case the screen is pillarboxed (but can also be letterboxed depending on the difference between actual screen aspect ratio and custom-defined aspect ratio).



Additionally, in that screenshot it was set to render at 256x240, which is stretched to fill the 4:3 ratio. However, if I enable Override Aspect on the low-res effect and specify a custom aspect ratio of 1.33:



This way, it can render at other resolutions but still use the target aspect ratio for the projection matrix.

All that being said, I'm thinking of pruning out some of the other effects I've been working on, like the PS1-style shader, and just shipping the CRT effect by itself. If I do it that way, I can get it out sooner and consider the other things as either addons or just plain free releases, as I think the CRT effect is really the main effect in this package and is enough to stand by itself. Any thoughts or feedback on that?

 

Thank you for adding those features! Looks like they do the job perfectly. (gotta love that low-poly racer too, haha)

Yeah, it makes sense to keep the asset focused on CRT/screen effects. And besides, you could always update the RetroTV asset with new effects later on, or even save them for another asset suite if it turns out that way.

 

Hey, I was looking for using something like this, have you released it somewhere? how can I get my hands on it for my game?

 

is it on the unity store i wonder, the shader

 

OK, sorry for lack of updates. Been busy with other stuff.

Today I dug back into the code for the first time in a while and did a bit of simplification. Previously, I had a "lo-res effect" which created an internal render texture and rendered a camera's view to that texture. I just today tossed that code out entirely. Instead, there's two scripts - one is a Blit Render Texture script which just takes a render texture and blits its contents to the screen. The other is an Override Aspect Ratio script which goes onto game cameras, meant to replace the same functionality that the Lo Res Effect script provided.
The idea now is that you just create a render texture in your project which acts as a sort of "canvas" for your game, at the resolution you'd like your game to run at (for example, 320x240). Then, your game cameras are just set to render directly to that texture. Then, a separate camera which is set to render nothing has the Blit Render Texture script on it, blitting the contents of the canvas render texture directly to the screen. And then finally that camera also would have the CRT effect on it, which applies the CRT effects on top.
This simplifies a few things in my code, and also means I'm moving more functionality over to what Unity already provides. For example, now you can have multiple cameras rendering into the same render texture and Unity automatically respects their Depth property as well as clear flags just as it normally would, rather than me having to try and replicate that myself. It also fixes a few edge cases involving moving between the scene and game tabs.

 

Just to fill you guys in... the system as it is right now is functionally complete. I am currently spending my time putting together a few example scenes and working on documentation. The sample scenes are most likely going to take the longest because I'm having to do all of the artwork myself, but I don't really want to skimp on these because I want them to really show off how it would look in a game. That said if there's any sample scenes you guys would specifically like to see (or maybe volunteers for artwork so I can speed up this process? >.>), feel free to let me know

 

The only sample scene I can think of is a standalone interactive demo. A self-playing scene like the robot demo (self-playing version of the low poly racer? 2D Sonic-like "RetroTV" title screen?) would be sufficient, with all of the system's options listed over the top of the effect along the sides of the screen. It'd give people a "try before you buy" thing to play with, and subtly demonstrate that the system is programmable.

Artwork-wise, if you ever need some fancy 2D logo animation, I can volunteer!

 

Well I've got the basis for one sample scene (JRPG-style character running down an infinite hallway), and I might actually leave it at that for now after implementing all of the controls (thinking Cable Type, Horizontal Resolution / Sharpness, Rolling Flicker, Color Depth, and Curvature).

As for the logo... how are you with pixel animation? I might have to take you up on that offer

 

I'm okay at pixel animation! Good enough to get by, and I can always fake fancier details when I need to. (do it in After Effects and clean it up afterwards)

 

Hm, I had sort of storyboarded an intro for Retro TV, which was to have the letters for "Retro" fly in GBA-style, screen flashes white, and as it fades back the "TV" part of the logo is revealed and some sparkles surround the logo. I'll probably work on the static logo image today and see what I can come up with.

 

So here's what I've got for the demo scene that will ship with RetroTV.

http://jetfistgames.com/Demos/RetroTVFX/JRPGDemo/

It will serve as an example scene which lets you easily play around with various parameters, see how they might look in action, and also an example of structuring and setting up rendering (how to set up a render texture as a virtual canvas of sorts, how to set up a UI so that it's rendered with the same effects, and also an example of adding image effects to the game camera as the demo uses a color correction effect on the game view).

 

Nice little demo. :> That's a good collection of common scenarios to show off.

Quick suggestion: Maybe fill the black void with something (underground dirt tiles? or even just a dark grey), so that the corners of the screen can be seen while curve is enabled.

 

Hm, I'll think about that. Maybe something like how Link To The Past handles it.

 

Awesome! can't wait to try this out. When do you think it'll be ready for the asset store?

 

Is this dead? Please tell me it's not! It hasn't been too long, so I'm optimistic, but I want it ASAP so I'm a bit impatient!

 

I've actually not had a whole lot of time to work on it on account of recent work and a bit of a hiatus I took for some medical stuff that happened in my life. That said, here's the thing - I've actually got another asset store thing I'm working on, a full blown game kit for making multiplayer-ready RTS games, which I think would be a lot more popular than this. Thing of the CRT stuff is that it's super niche, and I don't know if the money I get from it would be enough to offset the support burden.

That in mind, I'm honestly thinking about just putting in on Github in its current state. That would leave me free to deal with the other work I've got, and the game kit, and means you guys can just have at it. Sound fair?

 

Yes, please! Thanks for considering it

 

Fair enough, it is super niche stuff. Good to know what happened to this. Hope you're doing better medically, too!

 

Other than the odd hypoglycemic episode, I'm doing significantly better.
One of the things about having constantly high blood sugar (which is what I went in for): among other things, it really leaves you completely drained, physically and mentally. So having that energy back was/is an indescribable relief

Anyway, I'll probably try and package this stuff up for Github later tonight. I'll keep you posted.

EDIT: Aaaaand it's up!
https://github.com/KillaMaaki/RetroTVFX

 

I've just had a quick peek around, but I just want to say: I love that you added a hum/noise audio generator to this package, it's such a small but awesome detail. And that RF noise looks really legit.

I'm gonna dig into this later on, there's a couple things in here that I'm really interested in checking out. But thank you so much for sharing this!

 

This is actually one cool looking CRT shader I made a similar thing, but with a bit more tweaks and settings, and uploaded it to the Asset Store: https://www.assetstore.unity3d.com/en/#!/content/80048

Here's a WebGL demo of what it can do: https://b005t3r.github.io/UltimateCRT/

And a forum thread if somebody has any questions about it: https://forum.unity3d.com/threads/released-ultimate-crt-cathode-ray-tube-display-simulation.454666/

 

Odd choice to advertise in my thread...

Looks neat. Seems like we've got a bit of a different approach and goal - yours appears to be centered more around providing a high degree of artistic control, whereas mine is more designed for a high degree of authenticity but with a fair bit less artistic control.

 

Hah, sorry about the "advert", there are just not that many CRT effects out there, so I simply wanted to share mine

Yes, I was going for providing as many settings as possible, so nearly anything can be set up. The idea behind it was, if you're making a game, you probably want to adjust all of the small things to achieve that unique look. And if you're going for a high level of authenticity, this can be achieved as well (I'm pretty sure that with the right internal resolution, blur and shadow mask settings something like the image from the first post can be achieved).

 

Hm, not sure about that. One of the things I'm doing is converting RGB into YIQ color space and then interleaving Y, I, and Q values into a single greyscale "signal". On the receiving end I then perform a lowpass on that and then extract interleaved Y, I, and Q, then convert that YIQ back into RGB. An offset is added per scanline and then incremented each frame to help mask the resulting color artifacting, which results in that scanline crawl effect.

You can see the chroma artifacting that results from this if you take a look at my screenshots in this post: https://forum.unity3d.com/threads/wip-retrotv-effect-suite.419581/#post-2753152 The artifacts alternate on each line, and then that itself is animated so that in motion it's less detectable but there's still a subtle motion present that I feel does a lot to make it feel like a real TV (having studied one such TV that I used for over a decade of my childhood).

S-Video is implemented in a similar way, except I split the Y value into its own color component and interleave I and Q (simulating separate luma and chroma signals, like S-Video does). Which means luminance information isn't blurred, but the color hue information still bleeds, much like real S-Video connections.

I mean, I really did go for as much authenticity as possible, because I figured modeling it similar to how the actual video signals on those TVs worked internally would result in the most authentic retro look possible. But there's also something to be said for less authentic, but significantly more artistic control. Depends on the end goal I think.

 

Ah, I see what you mean. I definitely is noticeable on such 8-bitish images. I implemented color bleeding as well, I called it luminosity bleeding, because it's based on pixels' luminosity, it's nowhere as advanced as yours but it gets the job done where a dithered pattern needs to be smoothen out. I think it's best visible on "Cannon Fodder" jungle and winter levels, which are unwatchable on a modern LCD (they look like a pixely mess), but with my effect they look as I remembered them from back when I played it on my Amiga

I tried getting as close with my effect to what your does with the screenshot from Sonic, I guess it's pretty close, but, as you said, you can definitely see the small differences



BTW, with all that complex YIQ transform, how's the performance? I tried to make mine run on decent mobile devices and it does (not all devices are capable of rendering 60 FPS with it, but 30 FPS is easily achievable on a decent one).

 

Haven't checked mine on mobile. The RGB -> YIQ -> RGB isn't much at all, just a matrix multiply which should be lightning fast, the harder part is probably in the interleaving (which involves a sine and a cosine), the low pass (which has to sample multiple pixels, though you get that basically for free if running in GLES3 and above), and the fact that it takes several passes which have to read back the screen texture which can be a problem for the limited VRAM speed in phones.
I'd bet money my Nextbit could run it at 60 FPS (at least for five minutes, until this thing's extremely overzealous thermal throttling kicks in >.>), although as powerful as that phone is maybe not the greatest for perf comparisons. I never really worried about phone perf since on a screen that small most of the effect is lost/hard-to-see anyway.

 

As someone who had been looking around for an accurate shader emulation of NTSC/CRT imagery for a long time (to the point that I eventually commissioned a developer to port some NTSC shaders to Unity), I strongly feel that the "chroma aberration" approach misses the point. There were drawing techniques employed in older games that relied on the chroma/luma crosstalk that was so inherent to composite video. Dithered pixels would result in a "transparent" appearance, and new colors could be forged out of a more limited color palette.



Take note of the lap numbers, the dithered shadow under the speedometer, and the dithered mini-map.
Uncropped screenshots: [Daytona1] [Daytona2] [Daytona3]

Most players won't notice/care about the difference, and truthfully many developers would be better off suggesting the style anyway, rather than emulating it 1:1. But for any developer or artist who does want to emulate the look accurately, getting this effect to work correctly would be important, if not crucial.


That said, I'm running into trouble with RetroTVFX. I use an animated test image designed to check whether an NTSC shader does chroma/luma crosstalk correctly. A drag-and-drop Unity prefab of the test image is available [right here], and a video of the test itself is below.

Below is a comparison of expected and current results from RetroTVFX. I've done everything I can to ensure that everything is set up correctly. Render textures are set to 256x240, camera sizes are set to 120.



I'm not 100% sure where RetroTVFX is going wrong, but it's definitely close to being correct. I found I could force it to produce a false-positive result by setting the CRT Effect's Display to 853x120, but obviously this isn't ideal. It's a shame because it otherwise feels very legitimate, and I wouldn't have even questioned it if not for this test.

 

I think the main question is: Why would anybody need it? Modern retro games won't be using this trick, because they don't have to (you can have real transparency these days! ) and it's really tiring for the eyes - for how long can you watch this flickering image? So unless somebody's working on an emulator, it makes very little sense to actually use this effect.

 

Alright, I'll take a look.

Why you gotta be like that though T - T
But seriously, different strokes for different folks. I felt like it was probably too niche to sell, but I figure I can't be the only person who enjoys a high degree of authenticity in retro gaming, which was why I released it for free on Github.

 

Question: Is "correct" supposed to look like a seizure? Because I've got it doing that now XD I think I'm a lot closer.

EDIT
So here's what I've got now. If I disable scanline animation, it gradually cycles through colors. If I enable scanline animation, it cycles through colors while flashing like a strobe and generally looking like it should be capable of causing the worst seizure of all time, or at the very least a migraine.



The colors don't seem to match that video super well. I wonder if that's important, or just the fact that it cycles through colors and that "Pass!" is quite clearly visible now.

A few issues:
- Turns out, for best results, your vertical display resolution should match your render texture's height, but your horizontal display resolution should be exactly four times your render texture's width.
- My chroma mod frequency was slightly wrong. It should be (and now is) 1/3 * PI (approximately 0.33334 * PI ), whereas I had it set to 0.4 * PI
- My scanline phase offset was going in the wrong direction.

I might just commit this change as it is now, since it's at least more correct than it was before, and take another look on the weekend at seeing if I can match the colors better in that test.

 

Hah, I'm not like that, people who make games are like that Once I finished my effect, which uses a much simpler trick when blending adjacent pixels (brighter ones grow bigger, darker - smaller) I showed it to fellow game devs and some where impressed, but others were like "this is not how modern retro games are supposed to look like" and "I'd probably have to create graphics in a specific way to make this work (which is true, it does look better with old Amiga games than with the modern ones IMO), which is just not worth it" etc.

Don't get me wrong, I really appreciate the sheer amount of effort it took to make your effect and I would really love to see a game tailored just for it, but I'm not that sure I'd risk putting years of work into making a flickering game, you know what I mean? It's just a different thing wanting to see it in action, a different thing actually wanting to play it and buy it, and a different one investing your time into working on it.

 

Maybe worth noting, the flicker is rather subtle when used in-game. It happens so fast that it's barely noticeable. Nintendo even implemented their own version of it as a video effect for their NES Classic, it's rather tasteful.


(That's a GIF, I promise. Look closely at the vertical lines.)

The test is definitely meant to be seizure-inducing for composite video (it's much kinder for S-Video, no flashing every two/three frames). I can see the effect working in Unity now, but wow, that is a whole different breed of seizure. @@; You're right though, it's way closer now!

I've noticed that if you set up the display resolution for best results, and then halve both dimensions (eg: 1024x240 = 512x120), it actually produces colored results. Below is three consecutive frames.



While the colors don't match up to the video (NTSC: "Never The Same Color"), I believe all that's actually important is that there is chroma/luma crosstalk present. If this worked without having to halve the vertical resolution, it'd be a perfectly valid result!

 

Not sure if those colors are strictly correct, though. It's probably different because, by the bottom row of pixels, the phase has been offset by half the amount it normally would have (at 120 pixels high the difference in chroma mod phase between the top and bottom of the screen is 120*120=14400 degrees, whereas at 240 pixels high the difference in chroma mod phase between the top and bottom of the screen is 240*120 = 28800 degrees). This phase difference, coupled with the pattern used, could definitely produce different colors. I'm currently using a phase offset of 120 degrees per line since this is also what the NES and SNES used IIRC

Anyway, I'm actually starting to wonder whether the different colors I'm encountering are due to the way my decoding filter is designed. It's an 8-tap filter, whereas one version I found of themaister's NTSC shader, which I think is the one used in that video, is a 24-tap filter. I wonder if similar differences could be found displaying that same image on multiple different real NTSC televisions.

On a side note I did find a way to get rid of an extra pass in my shader, which is nice so I'll be pushing that change pretty soon.