Die hele discussie over compatible of compliant heeft toch geen zin
Daar ben ik het niet mee eens. Doordat deze twee termen vaak door elkaar gehaald worden (zoals ook in dit stuk), krijg je alleen maar meer verwarring. Vooral als een site als Tweakers.net, dat door veel mensen toch gezien wordt als een 'goede' nieuwsbron, de termen verkeerd gaat gebruiken, zullen veel mensen eerder geneigd zijn om dit te geloven. Dan krijg je van die situaties als "
Maar op Tweakers stond dat het compatible is met DX9.0, dus zal dat wel zo zijn", terwijl ook elke GF3 of Radeon7500, GF2 etc compatible is met DX9.0. Probeer die mensen dan maar eens duidelijk te maken dat ze de verkeerde term gebruiken, maar dat ze eigenlijk "compliant" bedoelen... Ik vind dus dat je dit soort dingen gewoon in de kiem moet smoren, en dat kun je alleen bereiken als je op een juiste manier met de termen "compliant" en "compatible" omgaat.
Dus kort door de bocht:
DX9.0 compliant -> Hardwarematige ondersteuningen voor alle DX9.0 features
DX9.0 compatible -> Geen hardwarematige ondersteuning voor alle DX9.0 features, maar aangezien DX backwards compatible is, zal een "compatible" kaart (bv GF3) wel onder een hogere versie dan zijn eigen "DX-compliancy" (bij GF3 is dat DX8.0) kunnen draaien. Het is dan vanzelfsprekend dat je dan wel enkele effecten mist (zoals het mooie water bij Morrowind).
Dan even ontopic. Het antwoord van nVidia is allerminst duidelijk. Op het eerste gezicht lijkt alleen maar een klein gedeelte van de verklaring over DM te gaan en de verwijzing naar DX9.0 pixel en vertex-shaders lijkt er onsamenhangend achter te zitten. Eigenlijk hadden ze er bij moeten zetten dat er meerdere manieren mogelijk zijn om DM te doen, maar dat ze niet aan 'echte DM' doen zoals Matrox dat doet.
Ik dacht dat alleen Matrox voldoet aan echte hardwarematige displacement mapping. Microsoft zag dat het er mooi uit zag en stopte het in DX9.0, net zoals ze dat deed bij EBM die ook dankzij Matrox in DX is ingevoerd.
Maar aangezien Matrox niet precies wil doorvertellen op welke manieren ze DM uitvoeren, hebben zowel ATi als nVidia hun eigen manieren moeten vinden om toch tot DM te komen.
En beide fabrikanten zijn gekomen tot een vorm van vooraf gesamplede DM en niet een vorm van adaptive/dynamic tesselation in combinatie met DM zoals bij Matrox.
nVidia heeft hier duidelijk gekozen voor een vorm van DM via pixel- en vertexshaders (de DX9 vertex-shaders kunnen namelijk sampled DM doen). Vandaar ook het statement over hun PS en VS in het artikel. En aangezien ATi ook DX9 ondersteunt kan ook de R300 dit via vertexshaders doen, maar deze kaart heeft als extra nog de hardwarematige ondersteuning van n-patches & voorgebakken DM via hun Truform II.
Voor zover ik weet is dus de manier van ATi iets flexibeler dan die van nVidia, maar zeker lang niet zo flexibel als de manier van de Parhelia van Matrox.