Broken shadows on Silent Hill 3 & 4 on latest dev.builds

[FlatOut]

Broken in native? Or broken in upscaling/CR ?

It's broken in CR. In 640 it still worked with CR resolutions. Native scaling was never broken.

[gregory]

Oh. Ok.It wasn't clear for me.

So yes depth behavior is slightly different. It works better but unfortunately doesn't support CR. I don't plan to "fix" it. I prefer spending time fixing "real" issues.

[Psycho-A]

Works in native scaling, yes, thanks.
So as I understood, you've plan totally kill CR in emulator as it doesn't care you? That's bad - custom resolutions were always faster than multipliers... Even in 4xNative I'm now getting my videocard's pain because it needed to process a twice larger number of overall image's pixels, because my monitor has 2m pixels while 4xNative gives 4m ones. But 3xNative is not enough to get normal sharpness on 1080p, either it's larger than custom too (totally 2.3 mpx) and slower now too.

[jesalvein]

Works in native scaling, yes, thanks.
So as I understood, you've plan totally kill CR in emulator as it doesn't care you? That's bad - custom resolutions were always faster than multipliers... Even in 4xNative I'm now getting my videocard's pain because it needed to process a twice larger number of pixels, because my monitor has 2m pixels while 4xNative gives 4m ones. But 3xNative is not enough to get normal sharpness, but it's larger than custom too (totally 2.3 mpx) and slower now too.

Let's say it isn't top priority because of what kind of glitch it can make.
Maybe one day...

[lightningterror]

Works in native scaling, yes, thanks.
So as I understood, you've plan totally kill CR in emulator as it doesn't care you? That's bad - custom resolutions were always faster than multipliers... Even in 4xNative I'm now getting my videocard's pain because it needed to process a twice larger number of pixels, because my monitor has 2m pixels while 4xNative gives 4m ones. But 3xNative is not enough to get normal sharpness, but it's larger than custom too (totally 2.3 mpx) and slower now too.

Imo custom resolutions are never a good thing. Unless you're  trying to setup a custom upscale resolution ( example x2.5 or x2.6 like I do). You can try something between x3 and x4 like x3.5 or something.

This can come in handy http://andrew.hedges.name/experiments/aspect_ratio/

[Psycho-A]

>> Imo custom resolutions are never a good thing. Unless you're trying to setup a custom upscale resolution ( example x2.5 or x2.6 like I do). You can try something between x3 and x4 like x3.5 or something.

The problem is that Custom resolution now seems to have other behaviors than Native multipliers, and even if I set in CR the same sizes as obtained via native multiplier (f.e. 1536x1536 that's complies 3x of native 512x512 for SH3 and some other PAL games), it doesn't get rid of CR-introduced glitches.

[gregory]

CR set framebuffer size. During the framebuffer lookup, a scaling factor will be computed as framebuffer size/PS2 screen size.

Scaling factor can be dynamic (it is allowed to change the screen size parameter). The game framebuffer can be bigger than screen size. In order to reduce code complexity, I need to sample depth buffer directly so I need to apply a scaling factor on coordinates. It is free with xN factor but just annoying with CR. So everything is broken.

Current goal is to separate the framebuffer size / scaling factor / PS2 screen size / rendering size. The framebuffer size ought to be big enough to hold data (it's just a container). However lots of GSdx operations are based on the size of framebuffer instead of the size of the image in it. Lots of extra pixels are computed for nothing, it explains why xN is slower now.

So yes I want to remove CR because it isn't a good solution. It is broken by design. And I'm nearly sure we can obtain a similar behavior with a basic factor (float instead of integer). If it doesn't work, I will likely fix CR but currently it is the lowest priority.

[Psycho-A]

However lots of GSdx operations are based on the size of framebuffer instead of the size of the image in it. Lots of extra pixels are computed for nothing, it explains why xN is slower now.

I didn't learned well about what you talking, but is this issue just planned to fix in the future? Since people have bigger and bigger resolutions on monitors, it's going to be very actual now, especially if CR planned to be stripped. "Current goal is to separate the framebuffer size / scaling factor / PS2 screen size / rendering size."  sounds to be good, so I hope the solution for it will be found soon...