Actually what do you count as forced filters. I just turned off Aniso and it's definitely still there. The foreground pixelation on land is there and also the offset pipe remains @ 4K.
Okay config: D3D11 4K. Vsync and fullscreen. 4xAnti-aliasing. What do I set for Aniso? Is MSAA okay or not?
I have per-pixel lighting on.
Ignore format changes. Store EFB to Tex. only.
Texture cache in middle safe zone. Async. Fast Depth.
Is the same in all the backends?
(06-29-2015, 08:05 PM)Tino Wrote: [ -> ]Is the same in all the backends?
I could not play in openGL. Massive glitches could not locate shader path or something. Let me try again. With 1x Aniso I still get these problems. Is aniso even needed for this anymore?
Let me try dx9.
I'm still amazed at these coins lol.
Okay with all enhancements off DX9 has no gitches. Offset pipe is fine. The land is also not pixelated slightly. Obviously game is not playable in DX9 without major hitches.
I turn off all enhancements with DX11 and both glitches remain. Thanks for reply.
Ok will take a look and try to reproduce it.
(06-29-2015, 08:16 PM)Tino Wrote: [ -> ]Ok will take a look and try to reproduce it.
Scaled EFB copy OFF, making coins awful, produces no pipe offset in DX9. When on the pipe is back to being offset. The pixelation of land is not in DX9 only DX11.
Somewhere in those enhancements is producing the offset and problem.
In DX11 when I keep all my enhancements on but EFB scale copy off, making coins awful again, the pixelation problem is actually fixed but the tile problem remains.
Sorry I am noob when it comes to this so I hope I am being clear and this is okay info.
I cannot thank you enough for fixing the coins man. They make the game unplayable before. Dear lord.
As an added bonus, Safe Texture Cache (samples = 512) is not needed anymore.
You can use the "fastest" setting (samples = 128) to improve performance and the texture effects still work.
@ Khronikos: Why are you always talking about anisotropic filtering? Do you even know what it does? As far as I can tell it shouldn't make a perceivable difference in this game, because there's no 3D looked at at sharp angles...
@Tino: The scaling works greatly, I don't even remember the coins looking that nicely on the console... well, I guess they didn't because of the low resolution ^_^
However, custom texture loading seems to be broken recently. With it enabled, Mario levels crash every time they open... also happens with SMG, so it's not only that pack having issues. (and it has nothing to do with the scaling - also happens with it disabled)
@StripTheSoul Thanks for the report will take a look, if you can see the last version that worked it will really help me.
(06-29-2015, 09:24 PM)kirbypuff Wrote: [ -> ]As an added bonus, Safe Texture Cache (samples = 512) is not needed anymore.
You can use the "fastest" setting (samples = 128) to improve performance and the texture effects still work.
Actually, it's more the other way around. It's important for Dolphin to detect if a texture was changed or not. The lower the sample number is(except 0...), the more likely it is that the texture seems to be unchanged although it was changed. When using efb2ram though, which was required for the spinning coins, textures are removed from the cache, if they overlap efb copies(makerangedynamic). Since the spinning coins and co are efb copies that are inside the memory area of the big texture, on efb2ram, the big texture was removed from the cache every frame. And so, at least for the big texture, even a sample number of 1 would have worked.
Now with efb2tex, there are no textures removed if they overlap efb copies. So Dolphin needs to track changes of the big texture. Well except the spinning coins, because those are copied over the matching part of the big texture, and we can ignore how the texture looks in these places. Enable texture dumping and look at the 1024x1024 texture the game dumps, and then go to another world, dump the texture, and look at it again. Now you have to consider what 128 samples means. The texture consists of 32x32 tiles each with a size of 32x32 pixels. So you have 1024 tiles, and with 128 texture cache samples, the hash is calculated with 8 bytes of data from every 8th tile. So if the wrong tiles change, Dolphin can't detect the change. From a theoretical point of view, you'd want at least 1024 samples for this texture.
You could ask: "Why doesn't Dolphin always assume the texture was changed on efb2tex + overlapping efb copies?" - Well, that's because it's a major performance issue to even have one texture upload/creation per frame. In my testing the game only went from 300 fps down to 250 fps when recreating this one texture. Other games have 50% drops, if there's one texture creation per frame.
So with just 128 samples, i expect there to be issues in the levels when you change from one level to another. Stuff like instead of a block, there's a part of a pipe in the level.