Was refering to the lies about 3d technology and products that NV and ATI spout.Reverend said:This is not the GD forum, guys. Thanks.
Sure, but I'm curious how potent the basic requirements are for real-world situations. If the basic implementation is cool and efficient, I don't really care whether it's not very programmable at all.Ailuros said:The GS in D3D10 is what's left of what could have been a highly potential PPP; I doubt IHVs will waste HW to go beyond the according basic requirements.
Yup, being able to select how much of the MSAA should become SSAA on a per-pixel basis would be cool, so as not to limit that feature only to alpha-testing-related-shaders. Of course, that would only be useful if the problem didn't come from textures, in which case a standard HLSL function to do that without having to rewrite the code a zillion times could be nifty.Adaptive shader antialiasing. Now that we've finally got adaptive AA for transparencies, the 4-5 years D3D10 is aimed to last is enough to get a bit more greedy.
Uttar said:Sure, but I'm curious how potent the basic requirements are for real-world situations. If the basic implementation is cool and efficient, I don't really care whether it's not very programmable at all.
Personally, I'd already be very happy with a system that would let me automatically put select a LOD that was created on the CPU (that is, with a fixed number of LODs being present on the installation disk, artist-approved) and lerp between the different possibilities properly.
Yes, this can be done on the VS, but there are multiple problems with it imo. Of course, such a special-purpose implementation won't happen I'm sure, bleh. Oh well.
Yup, being able to select how much of the MSAA should become SSAA on a per-pixel basis would be cool, so as not to limit that feature only to alpha-testing-related-shaders. Of course, that would only be useful if the problem didn't come from textures, in which case a standard HLSL function to do that without having to rewrite the code a zillion times could be nifty.
*cough* NAO32 *cough* - I know I'm insisting on that one, but it feels so humiliating for FP16 blending in the SM3.0. generation (read: would have been it totally useless had it been figured out earlier) that it completely disproves your claim: talented programmers can and will find astonishing solutions to key problems.Ailuros said:Past history tells me rather that I shouldn't expect too much from developers in finding sollutions for any sort of problems.