'Fast' at 128 samples - same as before
'Medium' at 1024 samples instead of 512 - almost the same performance as 512, but removes the jumpiness / smoothness issue with 512 and works with more titles which needed the slowest setting before
'Safe' at 3072 samples - new setting, works with almost any title. much better than using (the extremely slow) 'safest'
'Safest' at 0 (unlimited) samples
Do you even know what the samples mean? Or why those settings were used in the first place? Or what happens when using other settings? Have you even tried the settings you are recommending the developers change everything to?
what happened to hashless, abandoned? Was the idea flawed, or just developer didn't have time?
I am a little confused as well. Can you give us more background or information on specifically how you are expecting this to be implemented?
Samples 0 => safe setting => hash everything
Samples 128 => fast setting => hash up to 1 KB
Samples 512 => medium setting => hash up to 4 KB
Since there's at least one game that requires 4096 samples, 4096 samples should be one option.
The idea behind using 2^x values as samples is that a higher samples number results in the same data hashed as with a lower number plus additional data being hashed. So that's a big NO on 2560 samples.
Anyways, i did plan on releasing a test build of Dolphin that tells you which samples number is the lowest you should use. That build will be really slow, and you'll have to play every major situation(main menu, battle, videos etc.) for it to work properly. But when that build tells you to use, let's say 16384 samples, you will want to set the game to use 16384 samples.
But this build will have to wait until it's been decided how to implement this:
https://github.com/dolphin-emu/dolphin/pull/2097
as it affects the setting that works best.
@kirbypuff: We shouldn't change this settings before the next stable release. This would break compatibility with older texture packs. There is a converter in master already which uses the new texcache independet format, but I'd like to have a stable release which can convert *and* read the old format.