Reply 1800 of 3949, by Dege
wrote:If you want a baseline testbed, I'm ready to test a 2009 D3D10 system (a good notebook with a Dual Core Proc@2.5 GHz + 4 GB RAM + GeFoce 9600M but with Windows10 😁) for the classic 1280x800 / 1024/768 resolutions.
Ok, thanks, then I'm going to include the 10.0 support in the next WIP.
wrote:What do we lose with that? won't textures actually look better without mipmaps?
Generally speaking, I think not. Some looks better but Moire-like effect is present with large resolution textures.
But, as I said, we would only lose the mipmapping for colorkeyed textures (with colorkeying on) which are, I think, not even multilevel ones
in practice.
wrote:I can understand a depth blt, but how many games you now that actually lock the depth buffer, multisampled or not ?
Not many, actually, I can only instance Druuna Morbus Gravis, which has an Alone In The Dark-like rendering: static 3D background but living characters are rendered in 3D way onto it. In this game the z-buffer is also part of the background, the game uploads background z-data manually to the z-buffer. Or, there is BlairWitch 3 which is very similar, but I can't remember if exactly the same as for the rendering method.
Edit: Back in the ancient times, locking z-buffer was a common method for visibility testing, typically used for lens-flare effects. The game
rendered the scene and then locked the z-buffer to see what depth values are in the buffer at the 'sun position'. If they were the same as the one used for clearing the z-buffer then the sun were treated as visible, otherwise some objects got drawn in front of it. (Later 'occlusion query' was invented to avoid locking the z-buffer.)
It was very typical for Glide games, I don't know how it was true for DX games but I cannot remember if encountered one doing that.
wrote:can SM 4.0 pixelshaders output depth (SM 3.0 can) ? would that not be enough for depth blts ?
Yes, they can emit depth values, but the problem is on the input side, the "z to z" shader has to read the input data from another z-buffer.
And the input one cannot be multisampled for 10.0, what is more, yesterday found that 10.0 doesn't even support raw memory copying (without shaders) from z-buffer to z-buffer. So, for 10.0, it all has to be substituted with shader z-copy that only works for non-AA cases.