Well we have a fix for for the r_clear-triggered bug, but maybe we should still set it to 0 for the non-fastsky ones as a precaution against other bugs?

After some thoughts, this is what I think about:

• set r_clear 1 for usual profiles (medium, high, ultra), on today's hardware player should not see any difference, really, and this would avoids wall of mirrors and other issues from third-party maps we can't fix.
• set r_clear 0 on low and lowest profile, to save a potential extra fps, making use of tr_sky: clear color buffer when fastsky is enabled, do not clear screen by default DaemonEngine/Daemon#473 to clear only when there is sky on the scene and fastky is enabled. I have seen a gain doing that an a PCI (cough, cough) Tesla (cough) card from 2007 on a Vista-era PC (cough, cough)… So it makes sense that if someones needs lowest preset, such trick would be appreciated.

I'm yet to see some hardware supporting medium preset to get a performance difference from r_clear 0, so better fix bugs from legacy third-party assets starting with medium presets.

Daemon#473 seems doubtful to me. Tess_StageIteratorSky is part of the surface drawing pipeline. Clearing of course needs to be done before anything is drawn. So clearing the screen after surfaces are already being drawn risks erasing things.

But isn't sky meant to be drawn before anything else? As far as I know that's part of why we can't draw sky over other things and then, sometime objects from other rooms can be seen through the sky… because sky is meant to be drawn before.

In the normal case I suppose the sky should always have the largest depth and be sorted first. But I'm not sure it couldn't happen in some case like with cameras/portals etc.