Mdapt & gdapt - dithering treatment [Updated 06/06/14]

RetroArch Additions Shaders
#101

Faster.

#102

hmm saw some activity here. just wanna mention that I didn’t abandoned mdapt. on the other hand I’m currently at an dead end. the approach of converting mdapt to a shader which doesn’t make binary decisions is way to complex and doesn’t get such amazing results as the easy case. I’m still thinking about it though from time to time.

you could have mentioned the author of the shader :wink: btw didn’t even know that my algorithm is based on hyllians DDT. I guess I should’ve studied other shaders beforehand to save me many hours of coding.

#103

@Sp00kyFox Oh man, I definitely should have mentioned you. I’ll do that right now.

As for the DDT thing, that wasn’t you? I must have been thinking of someone else. Christ, I really got my facts wrong with that one. I’ll set the record straight on it, as well.

EDIT: corrected.

#104

now I feel like being picky, lol.

thanks though for correcting it, your blog is really informative and good advertising for retroarch…

@Hyllian thanks for helping out in the meantime and code optimization, I appreciate it. I installed a new OS on my system and was also busy with a few new games ^^

#105

@Sp00kyFox Hyllian just converted a shader from Ver Greeneyes that might be helpful for mdapt, based on Ver’s description:

Here’s a link to Hyllian’s port (also posted in that thread): https://anonfiles.com/file/6a59cd1642b731d037111008c8b26910 Hyllian noted that it doesn’t appear to be a fully lossless process (at least in its current state), but whatever.

#106

Hi Sp00kyfox,

I’d like to understand this piece of code in mdapt-pass2.cg:



    if(C.w > 0)
    {
        for(int x=-rad; x<=rad; x++)
        {
            for(int y=-rad; y<=rad; y++)
            {
                hits += (tex2D(decal, VAR.texCoord + (x*g1) + (y*g2)).w > 0) ? 1 : 0;
            }    
        }
    }
    else
    {
        for(int x=-rad; x<=rad; x++)
        {
            for(int y=-rad; y<=rad; y++)
            {
                hits += (tex2D(decal, VAR.texCoord + (x*g1) + (y*g2)).w == C.w) ? 1 : 0;
            }    
        }
        return C;
    }

Why this “else” if you return at the end?

#107

well the idea was to differentiate between checkerboard pattern (positive) and one line dithering (negative) in pass1 by using different signs. so the “else” is for the second case. but I must admit I don’t really have a clue why there is a return statement. yeah, it doesn’t make much sense. I guess since the one line dithering detection isn’t working too well I temporarily disabled it by adding a return here and forgot to remove it again. good find hyllian :wink:

btw can it be that these loops in pass2 are very ineffecient? I guess one could unroll them. edit: never mind. just saw that you already did that in the optimized version.

1 Like
#108

No matter how much effort is put into a shader that detects dithering patterns and blurs them, it can never be free of false positives and false negatives. There’s just so many countless combinations of patterns, and even with a team of people working I can’t see how you could ever make one that’s perfect in all situations at all times. Perfect for some games, sure, but not everything.

Could a dithering shader be made going the other way? Right now, Blargg NTSC only works for a select few systems. Could a shader be made that focuses just on reproducing the effects needed for dithering to be blurred and work regardless of system? Or is how NTSC operates too different per system? Also, standard NTSC shaders reproduce a lot of other effects that have nothing to do with blending dithering.

A kind of NTSC-Composite-lite shader, with the focus on dithering blurring.

1 Like
#109

If I’m not mistaken, GTU can do this.

There are many filters that blur dithering, even in ancient emulators like kega or gens. Some of those TV Mode, Soft Blur, GS2x, etc can do this. The problem with all of them is that the whole screen becomes blurred. And that’s what we’re trying to avoid here in this thread.

1 Like
#110

I tried Soft Blur and the dithering became… blurry dithering. It didn’t blend it at all. So which ones can do it and at what settings? The only thing that’s worked for me is NTSC Composite filters, and Snes-hires blend (for certain kinds of dithering).

1 Like
#111

GTU can definitely do it. It does an absolutely beautiful job on SNES pseudo-hires transparency, and (if you tweak some settings) it can smooth out Genesis dithering nicely, as well. It does blur the whole image noticeably, though. (I have some shots in this blog post: http://filthypants.blogspot.com/2013/06/dedithering-pixel-shaders.html)

1 Like
#112

@Hillian one question to your optimization. ist there a little error with the dtt-vector? I mean it’s nothing that would break the shader. but shouldn’t be (65536,256,1) used instead of dtt=(65536,255,1). 24bit color gives you 16,777,216 different possible values. but the mapping process with this results in only 16,776,961 possible values. any reason for that or just a coding mistake?

#113

code mistake I think.

#114

ok here is a little update to mdapt. I corrected a few little things and optimized it further.

changelog:

  • fixed: in some obscure cases the dtt vector would have led to wrong decisions.
  • fixed: sometimes patterns were overlooked due to bad if-else-structure in pass1 (health bar in turtles in time is now blended correctly)
  • optimized: removed hyllians mapping process between tags, specific values are now being used. (still doesn’t need framebuffer)
  • changed: color transitions at the edges of blended areas should be smoother (check out the title screen in ecco)
  • removed: one-line-dithering detection. meh, the pattern is too simple. there are just too many false detections if it’s activated. I think about an additional shader specific for this “genesis dithering”.

download: http://forum.themaister.net/viewtopic.php?pid=7973#p7973

comparison between v1.5 und v1.6:

[Album] mdapt-v1.6

1 Like
#115

looks great, man :smiley:

#116

Great Spookyf0x!

I’ll see how it compares to 1.5 in performance.

#117

Spookyf0x, I just tested here on PS3 and found some problems:

  • Some ditherings treatments are broken. For example: that match screen in SFA3 isn’t as smooth as in the 1.5. Many glitches appear now.

  • The X hud in Super Mario World used for the number of lives is now treated as dithering.

  • the fighter screen in Marvel Super Heroes (arcade) isn’t so smooth as in 1.5.

#118

I can’t see the problem with marvel super heroes (maybe a marked screenshot plz?) and the X counter in smw was already blended in 1.5, it’s a shitty pattern. let me see what I can do about it. regarding SFA3, yeah I see it, not so noticable in motion though. thx for the information. I’ll work on it.

ps: meanwhile one could use this version here. I removed the questionable (?) smoothing of color transitions which led to the issues in SFA3. so it’s basically v1.5 but without the bugs (see the changelog above).

edit: problem solved, look here: http://forum.themaister.net/viewtopic.php?pid=7973#p7973

#119

Enter this screen in MSH and look at the dithering problems:

#120

I already did that but except for the better color transitions at the building I don’t see the difference to v1.5.