Dolphin, the GameCube and Wii emulator - Forums

(02-21-2016, 02:53 PM)shockdude Wrote: [ -> ]Well I attempted to port lanczos4 to Ishiiruka and, uh, got this:

This is at 1x IR. I don't know what I did wrong lol.
I used the libretro implementation and the GeDoSaTo implementation as references. The shader source code is here: http://pastebin.com/eQBLEZ1g

Edit: After poring over the code and doing some experiments, I've come to the conclusion that the shader code is correct, but the coordinate systems that I'm using are wrong.
In fact, if I set stepxy = GetInvTargetResolution()  / 4.0, I get pretty good results out of the shader, but I don't know if it's correct per se.
What exactly do GetInvTargetResolution() and GetInvResolution() return?

I know what's your problem. It's the same problem I'm getting to port my shaders (jinc seems to be so flexible that can overcome it):

Ishiiruka pass some graphics to the shader input framebuffer using Linear Sampling, even when you choose native 1x internal res. For the majority of shaders to work properly, it's mandatory to have access to the RAW native res (that is, all the square pixels at native res).

Your solution using GetInvTargetResolution isn't solving this problem, you are just making your shader pass the linear input directly to the output. What you're getting is indeed a Bilinear output thtough your shader.

(02-21-2016, 08:24 PM)KKLMNNOP Wrote: [ -> ]I don't really know what meaningful detail I can give but basically the custom textures don't load no matter how I configure any Ishiiruka, 520, 554, 560, 565 or the stable version.

With ''Prefetch Custom Textures'' enabled and the texture packs in the right place,
I get ''Custom Textures loaded, 0.0 MB in 0.0 s''.

I also tried deleting every trace of Dolphin and only testing with a single version of Ishiiruka.

All my drivers are definitely up to date and I just did a clean install of Windows 10 a few weeks ago.

Really lost here, the only thing that i can tell you is that you do a doble check on the game itself to be sure thet the id is correct. Apart from that everything else seems to be correct.

(02-21-2016, 06:30 PM)kirbypuff Wrote: [ -> ]@Hyllian:

What we need is these shaders ported to Ishiiruka:

For 2D image enhancement/upscaling
----------------------------------------
* CRT-Caligari
* CRT-Hyllian
* CRT-Lottes

CRT-caligari is soooo old. The best ones in Retroarch are these: crt-geom, crt-hyllian, crt-easemode and crt-lottes. The best one and accurate is crt-royale, but it is so complex it runs slow and is only recommended for 4k displays, so I think it's overkill for Ishiiruka for now.

(02-21-2016, 06:30 PM)kirbypuff Wrote: [ -> ]* 6xBR and 6xBR-v3.7c+CRT (v3.7c looks best when combined with a CRT shader)

- More CRT shaders, because DolphinFX is bulky and *super slow*. DolphinFX Scanlines + Barrel Distortion also doesn't produce a very good CRT effect.
- 6xBR, because 5xBR is not enough for high-res displays.

About your 6xBR request, I need to clarify some things: you're talking about the legacy xbr shaders. They're outdated right now on Retroarch. Some time ago I figured out how to make xBR scale-agnostic, which means it can upscale to any size, no need to NxBR, now it's just xBR. So now I have these kinds of xBR shaders:

xbr-lvl1-noblend.cg (It replace the legacy 3.7 LV1 shaders)
--------------

The most basic xBR shader. Level 1 means it only detects two edge directions (45 and 135 degrees). The interpolation doesn't blend pixel colors. It uses the most similar color from one of its neighbors. So, the final result uses the original color palette. And because of that, it only works properly at odd scale factors (3x, 5x, 7x...).

Recommended sampling: `Point`
Recommended scale factors: `multiple odd scale factors`

xbr-lvl2-noblend.cg (It replace the legacy 3.7 LV2 shaders)
--------------

An evolution from last shader. Level 2 means it can detect four edge directions, which shows as better rounded objects on screen. The interpolation doesn't blend pixel colors. It uses the most similar color from one of its neighbors. So, the final result uses the original color palette. And because of that, it only works properly at odd scale factors (3x, 5x, 7x...).

Recommended sampling: `Point`
Recommended scale factors: `multiple odd scale factors`

xbr-lvl2.cg (It replace the legacy 3.8 LV2 shaders)
--------------

It can detect four edge directions, which shows as better rounded objects on screen. The interpolation blends pixel colors, so that the final image is smoother than the noblend versions. It works well in any integer scale factor.

Recommended sampling: `Point`
Recommended scale factors: `Integer multiples` <-- See! It's scale agnostic!

xbr-lvl2-fast.cg (A fast alternative to xbr-lv2, though a bit less accurate)
--------------

This is a simplified lvl2 implementation. Much faster than the standard version, though it sacrifices some quality.

Recommended sampling: `Point`
Recommended scale factors: `Integer multiples`

xbr-lvl3-noblend.cg
--------------

Level 3 means it can detect six edge directions, which shows as better rounded objects on screen. The interpolation doesn't blend pixel colors. It uses the most similar color from one of its neighbors. So, the final result uses the original color palette. And because of that, it only works properly at odd scale factors (3x, 5x, 7x...).

Recommended sampling: `Point`
Recommended scale factors: `multiple odd scale factors`


Other than those, there are the multipass versions of them, up to lv4.

So, a simple xBR-LV2 would fullfill your need for a 6xBR. That's the shader I'm trying to port to Ishiiruka, but I'm having problems yet.

(02-21-2016, 06:30 PM)kirbypuff Wrote: [ -> ]For downsampling (from GeDoSaTo/madVR/MPC-HC)
--------------------------------------------------------
* Lanczos3 & Lanczos4 (with adjustable deringing fllter)
* Bicubic (with adjustable sharpness from 0 to 100)
* Catmull-Rom AR

Actually, though those lanczos are called 3 and 4, they're indeed 2-taps only.

Catmull-Rom is just a special configuration of a more general Bicubic implementation. I have one bicubic shader in Retroarch with some internal params that can be adjusted to work like catmul-rom and other known cubic spline configs.

Tino,

When you set Dolphin to native 1x res of 640x528, what's the resolution of the framebuffer it uses to put 'in' the dolphin screen?

Normally on other emulators it is a PoT framebuffer. So, for 640x528, other emulators would create a framebuffer of 1024x1024. What happen in Ishiiruka?

@Hyllian: in dophin the framebufferr size is a multiple of the real efb size so you start with 640x528 at 1x, 1280x1056 at 2x, 1920x1584 at 3x ....

If the native res is 640x528, is there any reason why when I use the Screenshot feature, to take a native shot of the game, it takes screenshots at odd sizes like 584x480, or 584x448 in gamecube games (Luigi's Mansion and RER, respectively) and 640x360 in wii games?

because the games do not uses the entire efb to render, every game chooses the resolution at what they whant to render, some games even render half of the screen copy that to one xfb the the other half copy that toa diferent xfb and then the final output to the screen is renderen combining the 2 xfb. sorry if is not clear but wii/gc rendering is a little complex but powerfull.

So, the hypothesis of Dolphin doing Linear sampling at some sprites/textures before feeding shaders is the most probable. If yes, this is breaking the efficiency of most common shaders.

(02-21-2016, 10:06 PM)Hyllian Wrote: [ -> ]I know what's your problem. It's the same problem I'm getting to port my shaders (jinc seems to be so flexible that can overcome it):

Ishiiruka pass some graphics to the shader input framebuffer using Linear Sampling, even when you choose native 1x internal res. For the majority of shaders to work properly, it's mandatory to have access to the RAW native res (that is, all the square pixels at native res).

Your solution using GetInvTargetResolution isn't solving this problem, you are just making your shader pass the linear input directly to the output. What you're getting is indeed a Bilinear output thtough your shader.

And you're saying Dolphin/Ishiiruka currently can't pass the native internal res to a shader?

(02-22-2016, 01:54 AM)shockdude Wrote: [ -> ]And you're saying Dolphin/Ishiiruka currently can't pass the native internal res to a shader?

I don't know about the inner workings of Dolphin/Ishiiruka, so take that with a grain of salt. What I'm saying is just based on the behavior of these shaders. They behave as if the input texture isn't native. It seems like Ishiiruka is prefiltering the input before passing to the shaders. It's that or we are getting some wrong param. Your lanczos port is correct, I compared with the version in GedoSato and Retroarch, the sources are the same. Why only Ishiiruka doesn't output correct filtering, then?

Look at these two screenshots I got using Ishiiruka. I configured it to native 1x internal res and checked the option 'Auto adjust Window size', so that it runs in a Window and its size will always adjust to the internal res (even if it changes in real time). It's using the shader nearest-neighbor.glsl.

[attachment=14414]

[attachment=14415]

Can you see distortions there??

Now this from Luigi's Mansion:

[attachment=14416]

Zoomed 2x for you to see the distortions:

[attachment=14417]