Würde ich auch sagen. Ich hatte vor langer Zeit eine Matrix G200 in meinem Rechner, zu der Zeit die absolute Bombenkarte, sowohl 2D als auc 3D betreffend, wobei ich bis heute immer noch glaube, dass diese G200 viele der heutigen GraKas im Bereich 2D schlagen könnte.
Mein Vater hat jetzt eine G400 in seinem Home-Office-PC und an der Qualität des Signals ist absolut nichts auszusetzen. Probeweise mal meinen Iiyama VisionMaster 19-Zoll angeschloßen, restlos von 2D überzeugt.
Und Matrox erhebt ja auch den Anspruch die besten 2D-Karten herzustellen und bis jetzt haben sie das auch wohl durch und durch bewiesen. Schließlich WIRD das Hauptaugenmerk auch auf 2D gesetzt und dort mehr Zeit investiert, 3D spielt für die ja keine so große Rolle, da die Hauptabnehmer für Matrox-Karten ja sowieso nicht im Gamer-Segment sitzen, sondern eher SOHO oder halt CAD, wo wirklich ein erstklassiger RAMDAC mit hochwertigen HF bzw. LF Filter gebraucht wird. Und das kostet natürlich einiges, das ist klar, aber meiner Meinung nach bekommt man da auch ordentlich was für sein Geld. Das sieht man zwar nicht in Spielen, aber mit entsprechender visueller Peripherie (goiles Wort ) macht sich das wirklich bezahlt. Da zählt mal nicht RAW-Power, sondern wirklich Ausgabe.
Und Treiber von Matrox laufen größtenteils sehr gut, am Anfang schon ausgereift, wenn man mal von der Parhelia absieht, der ja nach den ersten Release-Test eine bessere Performance durch neuere Treiber nachgesagt wurde. War ja im Endeffekt nicht so, aber wenigstens sprechen die technischen Eckdaten für sich und die neuen Möglichkeiten der GPU sind auch interessant, wenn auch zur Zeit nicht anwendbar. Ich will da mal kurz ATI erwähnen (Sorry MIB, das ist das einzige Mal wo ich ATI hier im Post erwähnen werde, also bitte ruhig auf deinem Stuhl sitzen bleiben). Also ich wollte ATI mit seinem TruForm erwähnen, auch unter der eher technischen Bezeichnung N-Patches bekannt. So kamen von ATI die Aussagen, dass dieses besagte TruForm eine einfache Möglichkeit sei, die Grafik eines Spiels durch geringe Veränderungen am Sourcecode massiv zu steigern. Sprich mehr Qualität bei geringem Arbeitsaufwand, wurde versprochen wie gesagt. Ich will jetzt nichts Negatives sagen, aber dieses "Pushen" von TruForm durch ATI, bei gleichzeitiger Suggerierung, dass die Implementierung des Features recht einfach von der Hand gehen würde, ist blanker Unfug. Ich will jetzt nicht in technische Details verfallen, aber es ist so, dass ohne entsprechnede Geometrieanalyse innerhalb der Engine, TruForm nicht ohne immense Artefakt-Bildung angewendet werden kann. Flächen werden zwar runder, aber wenn der Algo nicht explizit gesteuert wird, brechen Objekte auseinander und es entstehen häßliche Risse, die zwar zu fixen sind, aber dessen Bereinigung in keinem Verhältnis zum Mehrwert an grafischer Qualität der Geometrie stehen. Das kann selbstverständlich alles eingefügt werden, aber es verlangt in vielen Fällen eine gewaltige Änderung am Source und das steht in direktem Gegensatz zu der Aussage ATIs, dass nämlich die Technik seht einfach zu integrieren ist.
Zurück zu Matrox. Hier haben wir das wohl noch etwas unbekanntere Displacement Mapping, was auch eine Art von N-Patches bietet, dazu noch beträchtlich mehr. Geht jetzt auch nicht darum, dass es mehr bietet, sondern mal nur auf die N-Patches bezogen. Da wurde nichts an die große Glocke gehängt, sondern gleich gesagt: Leute, passt mal auf, wir haben uns hier was schönes ausgedacht, das funzt ganz gut, sieht ganz gut aus, ABER es gibt natürlich VIEL zu beachten, damit es auch entsprechend läuft. Knallhart wurde da den Entwicklern klar gemacht, dass sie Opfer zu bringen haben, wenn sie das Feature integrieren wollen, es wurde nicht gepusht unter Vorspiegelung falscher Tatsachen, sondern gleich gesagt was Sache ist. Und sowas finde ich von Matrox gut, das sie ehrlich sind,

So, mal kurz auf die Uhr geguckt, ist schon mächtig spät. Bis morgen (ach ne, schon heute) denn und pennt schön lang. Morgen gehts wieder ans C0den und dann wird der Parser auch fertig. Einer Lust ein Stückchen Code in der nächsten Zeit betazustesten??

cya
liquid

also wenn man keinen tft hat ist das eh net soo wichtig..

hatte pixelview gf ti 4200, ne geforce 3 ti 200 von powercolor, testweise ne radeon 7500, ne geforce 1 ddr und ne matrox g400 drinne

und trotz gutem moni sind die unterschiede meiner meinung nach zu vernachlässigen... nur die gf 3 war sichtbar schlechter aber die anderen könnte ich net unterscheiden (trotz gutem moni)

Nochmal ne' kleine Anmerkung zum Statement von MIB, danach ziehe ich mich hier auch zurück, da ich ja meine Meinung zur GraKa-Wahl schon zur Genüge geäußert habe.
Wollte nur sagen, dass der eigentliche Punkt, den ich rüberbringen wollte, bei dir anscheinend nicht abgekommen ist. Ich vergleiche als erstes gar nicht Displacement Mapping und N-Patches, das habe ich in meinem Post nicht gemacht und hatte ich auch nicht vor zu tun. Ich kritisiere auch gar keine der beiden Methoden. Was ich kritisiere ist die Haltung der Hersteller und damit verbunden das Promoting. Das wäre dir auch aufgefallen, falls du den Text genau gelesen hättest. Da habe ich zB gesagt, dass BEIDE Verfahren Probleme aufweisen und beide Verfahren ihre Berechtigung somit auch haben. Worauf ich hingewiesen habe, ist dass die Hersteller unterschiedlich mit den Problemen umgegangen sind. Die einen haben sie gleich zur Diskussion gestellt und explizit auf sie hingeweisen, die anderen haben versucht von den Problemen abzulenken und einen "einfachen Einbau" der Features suggeriert. Das ist mein eigentlich Kritikpunkt, an der Technik allein wage ich gar nicht zu kritisieren, da das Themen sind, die selbst für mich größtenteils böhmische Dörfer sind, wenn ich auch das Grundkonzept begreife, aber ich würde nich anfangen zu sagen, dass eine Methode besser ist als die andere. Wie gesagt, beide haben ihre Berechtigung.

Desweiteren spricht du, MIB, an, dass ATI Matrox geholfen haben soll, Displacement Mapping zu entwicklen. Ich würde an dieser Stelle große Zweifel äußern, da sich Normal-Maps (deine Erklärung hätte nicht sein müssen, ich weiß was N-Maps sind und wofür sie benutzt werden, sogar wie man welche von gerenderter Geometrie anfertigt ) entscheidend von N-Patches unterscheiden. Das N im Namen zeugt auch von keiner Verwandschaft. Wie gesagt, keine großen techn. Details, MassiveBlue will ja nicht seinen Thread komplett ins Off-Topic abgleiten sehen (Thx hier nochmal an Massive, der bis jetzt ja recht ruhig geblieben ist). N-Patches sind eine Abwandlung von sogenannten Bezier-Patches, also Patches, die aus B-Splines hergestellt wurden. B steht für Biquadratisch, Formel lässt sich sehr leicht entwickeln, ist also keine Neuentwicklung seitens ATI, NV oder Matrox, sondern diese Methode der Flächenbeschreibung gibt es schon ein paar Jahrzehnte.
Komme wir noch kurz zu den Normal-Maps, die wie der Name schon ausdrückt, eine Menge von Normalen aufnehmen. Normale, für die die es nicht wissen, sind Vektoren die senkrecht zu einer Ebene stehen (sie gucken gewissermaßen aus der Ebene raus, werden unter anderem für Lichtberechnung benötigt). Dieses "Vektor-Raster" wird als herkömmliche RGB-Textur gespeichert, die einzelnen Grundfarben nehmen die Vektorkomponenten (X, Y, Z) auf und werden von der GPU zur erweiterten Lichtberechnung umgesetzt.
Soviel dazu, man sieht, dass es dort große Unterschiede in der Methode gibt, allerdings sind N-Maps immer noch nicht mit Displacement Mapping zu vergleichen, da anders als bei den N-Maps beim D-Mapping die Geometrie tatsächlich verändert wird. N-Maps verändern diese nicht, sondern nur ihre "Wechselwirkung" mit einer Lichtquelle. So sollte man eher ATIs TruForm mit dem Displacement Mapping vergleichen, da dies beides Verfahren sind, welche eine veränderte Geometrie als Ergebnis haben, was ja bei den Normal-Maps nicht so ist.

(Part 2 folgt)

Vorletzeter Punkt ist der zeitliche Abstand der Entwicklungen. Meine Meinung dazu ist, dass dieser nicht relevant bei meiner Argumentation ist, da ich nicht beurteile welches Verfahren besser ist, sondern wie oben schon detailliert aufgeführt, sich die Hersteller zum Verfahren geäußert haben. Hätte ich jetzt argumentiert, welches Verfahren besser gewesen wäre, dann hätte ich natürlich dem zeitlichen Abstand einen entsprechenden Wert zugewiesen, da ja klar ist, dass neuere Entwicklung eigentlich besser sein sollten, als ältere. Aber da dem nicht so ist, habe ich den zeitlichen Faktor nicht berücksichtigt, da er schlicht nicht relevant ist.

Mein letzter Punkt soll sich auf die Spiele beziehen, die TruForm tatsächlich eingebaut haben. Serious Sam ist zwar ein gutes Beispiel für umgesetztes TruForm, allerdings muß hier auch beachtet werden, wie diese Engine rendert und wie die "interne Pipeline" aufgebaut ist. So lässt sich bei SS sehr einfach neue Effekte einbauen, wie zB die Gras-Effekte in Teil 2, diese waren sehr einfach einzubauen, da die Engine recht modular geschrieben wurde und so leicht Veränderungen an einer Stelle möglich waren, die keine weiteren Veränderungen an weiteren Sourcecodestellen nach sich gezogen haben. Fakt bleibt allerdings, dass TruForm nicht ohne weiteres in ein bestehendes Spiel eingebaut werden kann, ohne dass entsprechend große Änderungen zwangsweise durchgeführt werden müssen. Du hast ja selber geschrieben, dass es zu Artefaktbildung kommt, wenn TruForm auf alle Objekte angewandt wird, und gerade hier geht es ja los. Die entsprechenden Funktionen anzuändern, die die Geometrie für TruForm auswählen, verlangen erstens massive Änderung, zweitens verbrauchen sie auch entsprechend CPU-Leistung. Das alles kann minimiert werden, wenn entsprechenden Geo-Infos vorberechnet werden, aber wie gesagt, das verlangt alles nach nicht unbenklichen Änderungen am Source, Änderung die bei einem fertigen Spiel oder einem Spiel in der Entwicklung, wo die Engine schon steht, nicht so ohne weiteres möglich sind.

Genug von mir. Matrox rulez und das ist gut so, hiermit verabschiede ich mich von diesem Thread. Noch viel Spaß bei der weiteren Diskussion, wünscht euch euer

liquid