Eliminating NTSC "temporal interference"

Topics related to the API, programming discussions & questions, coding tips, bugs, etc. should go here.
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Eliminating NTSC "temporal interference"

Post by Jubatian »

Here are some shots with my display:
Bugz avatar: Normal compile; With a 228 clocks long line; HighRes; HighRes and a 228 clocks long line.
Bugz avatar: Normal compile; With a 228 clocks long line; HighRes; HighRes and a 228 clocks long line.
shots_normal_228_hr_hr228.jpg (107.93 KiB) Viewed 6304 times
It isn't very apparent, but I think it is red enough, at least visually it comes through. You also see a striking example on how my display can destroy graphics: the first and third shots are like how the original kernel does it (first the normal Mode 3, then the extended resolution Mode 3). The second and fourth shots show what happens when I add a 228 clocks long line, it looks a lot better.
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Eliminating NTSC "temporal interference"

Post by Artcfox »

I just compiled it and tried it myself, and the results on my big LCD look similar to your results with Bugz. Without the 228, I have two whitish vertical bars underneath the face. (I tried to snap some pics, but they didn't turn out as well as I had hoped, but it looks very close to the ones you posted.)

I am very satisfied with the results of the 228, since it either improves things or keeps them looking the same, depending on your display. It would be interesting to see what the difference looks like on an actual CRT, but I don't have one of those to test with.

I tried it on my small LCD, and again the results look identical between 227.5 and 228, but this is apparently a really high quality small LCD that was gifted to me. Just for the sake of completeness, here is what Bugz looks like with the HR-228 mode enabled—pretty much just like it does in the emulator!

Nice work Jubatian!
BUGZ-HR-228.JPG
BUGZ-HR-228.JPG (92.12 KiB) Viewed 6299 times
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Eliminating NTSC "temporal interference"

Post by Jubatian »

OK, then I will introduce it in the kernel after the kernel boost and the mode 3 modding is merged in! (Maybe I really shouldn't wait with them like anyone would test further... Not you as we just had Bugz compiled in every imaginable way with them, although you might test the Laser Puzzle).

The display of that LCD is really nice for sure! It is hard to believe that it is indeed NTSC!
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Eliminating NTSC "temporal interference"

Post by Artcfox »

I've got some bad news. I just tested the 228 versions out on a different LCD, and it makes the entire picture shake back and forth in all of the games that I've tried it with.

Edit: By "shake" I mean the picture itself is not offset horizontally, but the details within the image flicker as if they are moving back and forth by a pixel.

Watch these fullscreen for the full effect, the effect of the one with 228 is very jarring.

227.5 scanlines:


228 scanlines:


(In the second video, it doesn't look like it's flickering until I filmed it in high speed mode, but to the naked eye you can very much see it all over the screen in realtime.)
Last edited by Artcfox on Tue Sep 05, 2017 7:35 pm, edited 2 times in total.
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Eliminating NTSC "temporal interference"

Post by Jubatian »

What I see there is expectable to some degree since the 228 version does exactly that: It rapidly alters between opposite polarities (30Hz) to even it out. Truly that's what a normal TV broadcast over NTSC is supposed to be doing, too! (So I really don't understand how that TV gets it so poorly)

It should be a 30Hz flicker which a normal LCD panel should smooth out. I guess it is something with enhanced response time. It is crap either way (you have a choice between distorted graphics and flicker, great). I am actually thinking about coming up with a kernel which could take this as a setting from EEPROM (there is a block reserved for various kernel & bootloader stuff), so you could adjust it to your television (with a new bootloader, or until then, a programmer).

Maybe later I will also look into how I can generate true interlaced 525 line signal, which might fix such issues on televisions with craptastic filters (it shouldn't affect games a lot as you get just a half line extra in VBlanks, it would introduce a very slight 60Hz distortion in audio, though, due to extending a sample by a half-scanline every frame).
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Eliminating NTSC "temporal interference"

Post by Artcfox »

I'm not sure if you saw my second edit or not, so I'll make a new reply here:

Interesting enough, if I shrink the Uzebox image down using the "Picture-In-Picture" feature of this other display, everything looks pretty good with the 228 scanline mode, my eyes can only detect the flickering for a brief period right when I look at the display. I'm not sure if this would cause eye-fatigue if I spent an hour playing a game though. Maybe in the new bootloader, you can have an option to enable 228 scanlines for mode 3, and dynamically rewrite the 101 to a 97 in those two spots in the machine code?
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Eliminating NTSC "temporal interference"

Post by Jubatian »

Artcfox wrote: Tue Sep 05, 2017 7:34 pm I'm not sure if you saw my second edit or not, so I'll make a new reply here:

Interesting enough, if I shrink the Uzebox image down using the "Picture-In-Picture" feature of this other display, everything looks pretty good with the 228 scanline mode, my eyes can only detect the flickering for a brief period right when I look at the display. I'm not sure if this would cause eye-fatigue if I spent an hour playing a game though. Maybe in the new bootloader, you can have an option to enable 228 scanlines for mode 3, and dynamically rewrite the 101 to a 97 in those two spots in the machine code?
No, I don't mean using this mod. on Mode 3, I just used it for the experiment (as it was very simple to do). I intend to craft it in the kernel's VSync generation, thus affecting every game regardless of the video mode compiled with it (same for the true 525 line interlaced display if I eventually make it). The kernel itself would fetch the EEPROM config bits and generate the VSync accordingly, completely transparent to the game, without needing reprogramming (you set it by the bootloader or a display test program, then every game using such a new kernel would display accordingly).

The two images shouldn't differ a lot normally, so it shouldn't strain the eyes too much (of course it would be better if the LCD didn't have such a fast response time since then you just wouldn't have anything to notice), but probably that's why these are better off as user configurable options.
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Eliminating NTSC "temporal interference"

Post by Artcfox »

Gotcha, that sounds perfect.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Eliminating NTSC "temporal interference"

Post by uze6666 »

I recall having played a lot with this approach a long time ago. Giving quite varying results on different devices. CRT was the worst for me with more
"shaking" artifacts. In the end I resorted to my scope to inspect closely NES, SNES and Genesys signals and used precisely the same (the 1820 cycles). I figured if it was good for Nintendo it was good enough for me. ;) That said, for backward compatibility sake (never heard anybody complaining about shaking pictures so far on any type of TV), I'd keep the current 1820 as default in all video modes. An eeprom feature bit is quite appropriate for those who would like to experiment.
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Eliminating NTSC "temporal interference"

Post by Jubatian »

uze6666 wrote: Wed Nov 01, 2017 1:20 am(...) An eeprom feature bit is quite appropriate for those who would like to experiment.
I already have this concept in my mind for a further kernel upgrade. I would like to utilize GPIOR0 for it (which I already did in Flight of a Dragon and the new bootloader), as it is generally very useful to hold important kernel flags (such as it also saves a register in the inline mixer).

So the general approach would be that you could save the graphics configuration you prefer in EEPROM (I already reserved the byte for it in the new bootloader), temporal interference elimination and full interlaced 525 line mode, then if the kernel of the game supports it, it would silently use it (both are doable with any video mode as they only need code in the VSync generation which is common for every video mode).

Otherwise yes, the current approach if the game generates a clean sync seems to work very well. I also found that with temporal interference elimination my TV can't sync to the EUzebox's signal (the 4 cycles longer line apparently keeps throwing it out of sync).
Post Reply