Hybrid Scanlines
NewHome › Forums › OSSC, OSSC Pro and DExx-vd isl › OSSC – Feature Requests › Hybrid Scanlines
- This topic has 97 replies, 18 voices, and was last updated May 10, 2018 at 2:32 AM by
PRC.
-
AuthorPosts
-
March 1, 2018 at 10:34 AM #19719
The automatic bl off/on won’t be part of the official fw. It’s on my test branch because I personally don’t want to switch bl everytime off and on every time. Implementation is 100% HDL to not use software code space for that.
March 1, 2018 at 1:37 PM #19726In this perspective one could call this option hybrid strength and make this a variable number from e.g. 0 to 15, where 0 is off and 8 is 100%.
Ok with the overdrive it looks good. The hybrid setting definitely needs to be a variable number so it can be tweaked. Hybrid high on my PAL 3-chip SNES already clipped the top bars of the grayramp so max 125% is good.
Reverse LPF works now but in Optimized mode the first column of pixels skips the reverse LPF every other line so it results in a checkerboard effect.
also want to mention that the discoloring observation by @retrorunner with subtraction method for scanlines does not come from his TV. I build a firmware where you can see, what the scanline really looks like.
Yes I know the scanlines lose color but his pictures showed extreme results with the car picture almost black & white. Even with 100% black scanlines there is still color in the picture so it should not be black & white.
March 1, 2018 at 9:27 PM #19739OK; I updated the GitHub branch once again:
-> hybrid strength can now be adjusted from 0% (off) over 100% (SL-str is 0 exactly at I_max, i.e. 255) up to 200% (SL-str becomes 0 at 0.5 x I_max, i.e. 127) in steps of 12.5%. (yes, 17 steps (5bits needed). I had 16 steps before (4bits) but stopping at 188% looked a bit strange)Reverse LPF works now but in Optimized mode the first column of pixels skips the reverse LPF every other line so it results in a checkerboard effect.
Have checked that and I was able to reproduce that. But it was the same on the fw-build 0.79, which I downloaded from official hosting page. Could that be a trigger issue (I haven’t change anything at the trigger)
Yes I know the scanlines lose color but his pictures showed extreme results with the car picture almost black & white. Even with 100% black scanlines there is still color in the picture so it should not be black & white.
You are absolutely right! My comment was regarding the off-colours (not the b/w)…
Anyway – back to topic; the hybrid scanlines:
I guess we found a very good common approach. Hope you are fine with itMarch 1, 2018 at 11:38 PM #19746This is great Borti! Nicely done. Though for the casual user it probably makes more sense to just display Sl.hybrid str. as 0-15 (save 1 bit 🙂 ) or display 0-100% for 0-15.
Have checked that and I was able to reproduce that. But it was the same on the fw-build 0.79, which I downloaded from official hosting page. Could that be a trigger issue (I haven’t change anything at the trigger)
Indeed its not caused by your firmware. I had tried it on previous firmware before I reported it and it worked properly then but it was just a coincidence. It works randomly. I’ll have to check it out why this happens.
March 2, 2018 at 7:16 AM #19751This is great Borti! Nicely done. Though for the casual user it probably makes more sense to just display Sl.hybrid str. as 0-15 (save 1 bit ? ) or display 0-100% for 0-15.
Great that you like that, too 🙂
Indeed, I was thinking about exactly the same display solution, too. This are the reasons why I decided against that:
– displaying 0-15 are some kind of ‘magic numbers’ for the user
– displaying 0-15 as 0-100% is not what exactly calculated
– 1 bit extra has no cost in sw (it’s a 8bit variable anyway)
– 1 bit extra in hardware is neglectableThe only odd feeling was to stop setting at exactly 10000; but hey, if it is so, it is so 😉
Another soultion I had in mind was stopping at 150% or 175% but I wanted to have it sharp.What about other opinions?
While we are beta testing, maybe make all parameters variable (0-100%) so we can find a few sweet spots?
That would be: Contrast str, Scanline str, Gamma fix str.One side note: setting 100% sl.str., 100% hybr.str. and mult. method gives you an x^2-function* at the output. A special case of gamma adjustment in the scanline.
(* not 100% as I used Y (YCoCg appr.) for multiplicationand not RGB individually; so it is R*(R/4+G/2+B/4), G*(R/4+G/2+B/4) and B*(R/4+G/2+B/4))Indeed its not caused by your firmware. I had tried it on previous firmware before I reported it and it worked properly then but it was just a coincidence. It works randomly. I’ll have to check it out why this happens.
It strange is that it works / works not by random.
Edit: I’ve an idea where this problem comes from. But I just can test it this evening. @paulb_nl
March 2, 2018 at 9:24 AM #19754It works great.
I like how hybrid str 100% with scanline str 100% exactly produce scanlines on peak white (240), very well balanced.March 2, 2018 at 11:23 PM #19779I delayed the start of the reverse lpf by one tap now (https://github.com/borti4938/ossc/commit/145e3a5). This reduces the logic after the large multiplexer (R_act,G_act,B_act were written into two following registers and used in an adder/sub). I hope this helps a bit.
I also merged latest official fw into the branch. Here is the new build: https://github.com/borti4938/ossc/tree/dev_lcdbl/fw_build
To the main topic:
If there is nothing to add / no bugs found in the scanline generation, I will update the upstream branch for the pull-request 🙂March 3, 2018 at 4:46 PM #19797It still does the same thing with your firmware with the reverse LPF delayed. I found that if I change H.backporch so the screen moves to the right and has a black bar to the left then it works fine. Its very strange because changing backporch does not affect R/G/B_act I think.
Your firmwares 0.80 reverse lpf delayed and 0.81 have glitches on screen on lineX5 mode. The previous firmware of 1 march works fine on lineX5. Is FMax on pclk_5x still around 160Mhz?
Everything else seems to work fine on 0.81
March 3, 2018 at 11:56 PM #19816Ok, the linex5 does not work on my setup; so I didn’t know.
Could you download the source and remove the latest code change commit where I add an additional output register on the top level entity?
https://github.com/borti4938/ossc/commit/3714ad4f734d9cf8107d52c6b41ba1d8e039ac5e
Maybe it’s related to that test!?
March 4, 2018 at 4:48 AM #19821These changes are fantastic. I’m a big fan of scanlines and have always used them on the OSSC. Up until now, I’ve limited the strength of the scanlines simply because the image would otherwise be too dark. The idea of hybrid scanlines has appealed to me, but I didn’t have an UltraHDMI N64, so my first chance to test them was with the Super Nt. I was pretty underwhelmed – in bright sections of the screen, you can barely notice them, which is definitely not how I’ve perceived them on my CRTs.
In my limited testing of the beta firmware, I really like hybrid strength 87% and scanline strength 87% with multiplication. The experience is much improved. In the few games I tested, I really enjoyed the look.
Is there any reason to keep the subtraction method around?
March 4, 2018 at 1:34 PM #19829@borti4938 Reverting both ‘delay RLPF by one PP stage’ and ‘registered outputs to HDMI-TX after final mux’ brings back pclk_5x Fmax of Slow model 85C and Slow model 0C to 158Mhz, 161Mhz respectively and fixes the glitching.
Is there any reason to keep the subtraction method around?
Yes some people prefer the subtraction method. I am one of them 🙂 IMO subtraction has better colors with Hybrid but I believe it depends on your console + display. My 3-CHIP SNES looks quite different compared to my 1-CHIP. Probably mostly because at default gain setting the 1-CHIP is much brighter.
March 4, 2018 at 3:24 PM #19834FYI the 1Chip has boosted RGB values and is usually modded with resistors to bring its brightness down when adding RGB amp.
March 4, 2018 at 4:43 PM #19835I have a capture card so I know exactly what my SNES consoles are outputting. Most 1-CHIPs are too bright but my US 1-CHIP-01 outputs very close to 255. Only green and blue are a bit too bright and is easily fixed by slightly lowering the gain on the OSSC. Its barely noticable on the display.
My PAL 1-CHIP-02 was way too bright, crushing the brightest 3-4 bars on the grayramp so I needed to mod that one with resistors. My PAL 3-CHIP outputs 235 at default gain so is much too dark.
March 4, 2018 at 7:17 PM #19840Such big tolerance between units, according to shows like “My Life in Gaming” I thought all 1Chip units clip the whites.
I too vote for keeping the subtraction option since it may create better results with Monitor/TV gamma fix.March 5, 2018 at 3:25 AM #19851Downloaded the 0.81 beta version, definitely loving the multiplication method. The color output does seem different (less saturated for sure), but it doesn’t seem like it’s at risk of being black and white at full scanline strength and hybrid strength at all.
Using 25% scanline strength, 100% hybrid.
As mentioned before, 5x resolution isn’t working with this. There’s a persistent noise glitch that can’t be remedied with anything I can find. Is there any way you can get access to a monitor that displays 5x? My display rounds the pixels on 4x a little too much for my liking, but 5x is nice and sharp.
Hopefully this makes it into the official firmware. Great work!
-
AuthorPosts
- You must be logged in to reply to this topic.