Then, what you need is a blur shader.
Try those in mudlord folder. Inside them there’s a parameter you can change to control the level of blur.
yeah I actually know how to combine shaders xD but now I’m back to the problem I already had as I tried bicubic as a third step. it seems as if any shader I use afterwards is totally ignoring the image result of xBR and instead uses the original unfiltered one. I don’t know if it is related but I’m also getting this warning in the log if I’m using the shader (with the unmodified cgp):
RetroArch [ERROR] :: [D3D9 Cg]: Fragment error: E:/…/xbr-lv3-multipass/xbr-lv3-pass0.cg(185) : warning C7050: “px0” might be used before being initialized E:/…/xbr-lv3-multipass/xbr-lv3-pass0.cg(185) : warning C7050: “px3” might be used before being initialized E:/…/xbr-lv3-multipass/xbr-lv3-pass0.cg(185) : warning C7050: “px1” might be used before being initialized E:/…/xbr-lv3-multipass/xbr-lv3-pass0.cg(185) : warning C7050: “px2” might be used before being initialized
Those px# are completely ignored in second pass if they aren’t initialised in the first pass.
But, if you want get rid of those warnings, initialise them after this line:
lin0 = lin1 = lin2 = lin3 = bool4(1, 1, 1, 1);
px0 = px1 = px2 = px3 = bool2(0, 0);
I doubt it’ll fix anything.
yeah, third shader is still using the unfiltered image. it’s like xbr-lv3-pass1.cg prevents its image from being send to the next step. maybe it’s a issue with retroarch and maister has to take a look into this.
Post the retroarch log here and maister or squarepusher can see what’s happening.
to get the log:
If you use phoenix, it’s File -> Show Log if not, --verbose on command line.
There’s another test you can do:
put ddt.cg as third shader and change the second scale to 2x.
ok, I feel kinda stupid now. this way it works fine with additional shaders. thanks for the help again.
edit: played a few snes games with it, looks gorgeous. good work hyllian!
yeah i noticed that a while back. If you don’t define the xbr scale to something concrete (anything but “don’t care”) then it gets ignored on subsequent passes. Seems to be the case for all xbr shaders I have tried. Also you might want to try advanced aa as a linear pass after xbr. I really enjoy that look and it solves the issue you were wanting to get rid of. Also 4xsoft linear looks good too with same effect. Just some ideas to try and find your best preference.
Seriously though this looks great. I think it is safe to say that this has become the most advanced project of its kind. Looks even better than the “depixelizing pixel art” algo IMO. Hopefully the gl issues can be worked out soon too so I can use these again (since I ditched windows)!
I’m getting something similar to Awakened’s screenshot with displaced pixels with both DirectX and OpenGL (OpenGL is worse though.)
picture: 
I do, at least, have a theory as to the source of the problem. Some months ago I was trying to understand/improve upon the reverse-AA algorithm (which is a story for another day) and teach myself cg in the process, when I stumbled upon something odd: When I borrowed the standard code many existing shaders (including XBR) use for referencing the surrounding pixels, and tried to make some very, very simple shaders that just shift the picture around (e.g. return the value of the neighboring pixel that’s up one, left one) I sometimes got completely messed up results at 4x. I speculate that either the tex2D function is not always implemented as advertised, or it just doesn’t do what we think it ought to do.
It works exactly as I expect for the system (PS3) I work. And I just use the Cg Specs from nvidia itself.
I just don’t know what other systems are doing in their drivers, because these shaders should work properly.
And yes, most shaders need to look neighbor pixels to the central one. And tex2D only needs two parameters, the first is the texture to look for and the second is the address of the pixel you’re looking for in that texture. As many shaders use nearest neighbor sampling, there are some texture addresses more prone to errors than others. These addresses are generally at the pixel borders, where a miserable small digit bad rounded may induce tex2D to return two different colors, depending on how the drivers implement tex2D.
I think Maister can explain this much better than me.
Well, couldn’t it be the Cg compiler compiling to non conform HLSL or GLSL?
I’m in love with the mdapt + xBR preset combination. It makes Mega Man 2 look so amazing! Great work on xBR, easily my favorite shader. Now mobile GPUs just need to get up to snuff so I can enjoy this on the go.
That’s great. What’s your system (CPU, GPU, SO and DRIVERS)? Retroarch is running in OGL or D3D mode?
Intel i7 3770K nVidia 660GTX TI 16GB RAM
Debian 7.1 stable nVidia 325.15 drivers(latest from nVidia) OpenGL mode
Seems to run everything fullspeed that I threw at it(even bsnes), I’m also running the latest cores and retroarch from git. Do note that the mdapt 5xBR combination in the dithering/mdapt-4p folder crashed RetroArch with a segmentation fault when I tried to load the cg shader, but loading the GLSL converted shaders work just fine. Not sure if it’s RetroArch, the shader, or maybe even the CG compiler I have installed.
Ok, nice machine! I really don’t know what causes nvidia gpus be so picky with these shaders…
BTW, I forgot to mention in this thread: the first comercial game using xBR filters was released a couple of months ago and already has passed 5,000 downloads.
Simon The Sorcerer
Credits
It’s a relaunch (20th anniversary edition) made by MojoTouch for Android devices.
Link: https://play.google.com/store/apps/details?id=com.mojotouch.simon
One of the things I’m working is on the algorithm’s corner detection for small details. The problem is more complex than it seems. Not only it must be good for stills as it must keep HUDs and Fonts stable enough in movement to minimize artifacts where they blend with backgrounds. Another challenge is to prevent important pixels (for example, those that represent character eyes) from blending with neighbor pixels.
Here are some screens from the algorithm corner detection as it is now (In these examples I’m using just LV2). Now you can see the number “1” correctly and not smeared.
Original: … xBR 4x (next corner detection):
Got news!
Repo updated with xBR Multilevel4 multipass shader. This shader is LV1 to 4, because it chooses the level that best fit the pattern according to some new rules.
A major bug was found by another user (aliaspider) which was causing some glitches in nvidia cards with multipass shaders. So I just updated some multipass shaders: mdapt-4p, xbr-lv2-multipass and xbr-lv3-multipass.
your multilvl4 shader doesn’t work for me here. tried it with d3d9:
RetroArch: Environ GET_OVERSCAN: 0
RetroArch: Environ SET_PIXEL_FORMAT: XRGB8888.
RetroArch: Set audio input rate to: 31923.97 Hz.
RetroArch: Adjusting aspect ratio to 1.33
RetroArch: Video @ fullscreen
RetroArch: Setting multimedia scheduling for DWM.
RetroArch: [D3D9]: Monitor size: 1680x1050.
RetroArch: [D3D9 Meta-Cg] Found 4 shaders.
RetroArch: [D3D9 Cg]: Created context.
RetroArch: [D3D9 Cg]: Vertex profile: vs_3_0
RetroArch: [D3D9 Cg]: Fragment profile: ps_3_0
RetroArch: [D3D9 Cg]: Compiling shader: E:/shaders/xbr-mlv4-multipass/xbr-mlv4-pass1.cg.
RetroArch [ERROR] :: [D3D9 Cg]: Vertex error:
E:/shaders/xbr-mlv4-multipass/xbr-mlv4-pass1.cg(110) : error C7004: Too many output registers used. When no output has the PSIZE semantic, only 11 output registers are available.
RetroArch [ERROR] :: [D3D9]: Render chain error: (Failed to compile shaders!).
RetroArch [ERROR] :: [D3D9]: Failed to init D3D9 (Failed to init render chain, code: 0x0).
RetroArch [ERROR] :: Cannot open video driver ... Exiting ...
RetroArch [ERROR] :: Fatal error received in: "init_video_input()"
and with ogl:
RetroArch: Environ GET_OVERSCAN: 0
RetroArch: Environ SET_PIXEL_FORMAT: XRGB8888.
RetroArch: Set audio input rate to: 31923.97 Hz.
RetroArch: Adjusting aspect ratio to 1.33
RetroArch: Video @ fullscreen
RetroArch: Setting multimedia scheduling for DWM.
RetroArch: Found GL context: wgl
RetroArch: Detecting screen resolution 1680x1050.
RetroArch: [WGL]: Setting fullscreen to 1680x1050 on device \\.\DISPLAY1.
RetroArch: [WGL]: wglSwapInterval(1)
RetroArch: [GL]: Vendor: ATI Technologies Inc., Renderer: ATI Radeon HD 4800 Series.
RetroArch: [GL]: Version: 3.3.11672 Compatibility Profile Context.
RetroArch: Querying GL extension: ARB_sync => exists
RetroArch: GL: Using resolution 1680x1050
RetroArch: [GL]: Using Cg shader backend.
RetroArch: [Cg]: Vertex profile: arbvp1
RetroArch: [Cg]: Fragment profile: arbfp1
RetroArch: Loading Cg meta-shader: E:/shaders/xbr-mlv4-multipass/xbr-mlv4.cgp
RetroArch: Loading Cg shader: "E:/shaders/xbr-mlv4-multipass/xbr-mlv4-pass1.cg".
RetroArch [ERROR] :: CG error: The compile returned an error.
RetroArch [ERROR] :: Fragment:
E:/shaders/xbr-mlv4-multipass/xbr-mlv4-pass1.cg(153) : error C5041: cannot locate suitable resource to bind parameter "t8"
E:/shaders/xbr-mlv4-multipass/xbr-mlv4-pass1.cg(153) : error C5041: cannot locate suitable resource to bind parameter "t9"
RetroArch [ERROR] :: Failed to load shaders ...
RetroArch: CG: Destroying programs.
RetroArch: CG: Destroying context.
RetroArch [ERROR] :: [GL]: Failed to init shader, falling back to stock.
used the latest 64bit retroarch version on win8. hmm maybe my gpu is just too old. I guess you tested it on your ps3?
your guess was right, the reason why you can’t run the shader is that it requires a more recent GPU, due to the high register requirement of the shader in its current version, as you can see it in the error message. specifically, there are not enough registers available to store t8 and t9 in the vertex shader so that the fragment shader can use them. you only have 11 registers available per shader but xbr wants to use at least two more.
you could however move all the pre-calculations ( t0 to t9 at least ) from the vertex to the fragment shader, that way the compiler will hopefully be able to optimize register usage and run on your GPU.
EDIT : this is a modified version that should work for you: link