4Players.de Forum

Levi  hat geschrieben: ↑05.02.2018 15:07 Ich möchte dir keine Brille runter reißen. Ganz im Gegenteil. Dass du mehr Spaß an Crash als an m64 hattest, kann ich garnicht bezweifeln. (Hallo, ich find wörld auch besser als Galaxy )
... Aber diese faktische Behauptung, dass es technisch besser gewesen sei, halte ich für stumpf falsch.
(Stichwort: z-Fighting, warping etc)

Toll, aber Mario 64 hatte keine Fehler?

Was ist mit den NULL Details in Texturen?
Den stark erkennbaren Schnitten in Gelenken?
Den nahezu nicht vorhandenen Hintergründen?
Den ansonsten fehlenden Details (hat Mario überhaupt nen Mund? O.o)

Ich weiß auch garnicht was deine zwei genannten Fehler sein sollen. Beim z-fighting googlen kommt nur DBZ xD

Ich meine: Es tut mir Leid, aber Mario 64 sieht aus, als wenn alles aus Pappe zusammengefaltet wäre. Als Kind erschien mir es wirklich "schlecht" als ich es zum ersten mal gespielt hab, einfach weil ich besseres gewöhnt war.


Edit:
Hab z-fighting gefunden, wobei mir dieses Problem noch nie bei Crash aufgefallen ist. Ich werd mal drauf achten.

Das N64 war die erste 3D-fähige Konsole (möglicherweise ließe sich das sogar auf Grakas ausweiten), die perspektivisch korrekte Texturen erlaubte und vor dem Zeichnen eines Pixels gecheckt hat, ob das zugehörige Polygon überhaupt sichtbar ist (auch bekannt als z-buffer). Selbst ne Form von Antialiasing war schon drin, wobei das bei den damals üblichen niedrigen Auflösungen auch nicht nur Vorteile hatte. Aber ja, es war auf dem N64 das allermeiste technisch weiter was mit Grafiktechnik zu tun hatte, denn das N64 war in praktisch allen Belangen weiter. Außer beim Speichermedium und in der Folge manchmal beim Sound. Was du meinst mit technisch besser ist eigentlich mehr der Artstyle.

Was Levi als z-Fighting bezeichnet ist wahrscheinlich der Effekt, dass auf der PlayStation teilweise Polygone die eigentlich hinter einem anderen Polygon liegen sollten trotzdem manchmal davor gezeichnet wurden. Das wurde damals in der Fachpresse auch gern als Clipping-Fehler bezeichnet. Der N64 z-Buffer hat das komplett verhindert. Bei Hardware wie der PS1 musste man sich beim Zeichnen der Grafik Gedanken machen, in welcher Reihenfolge Geometrie gezeichnet wird. Beispiel: Ein Auto steht vor einem Haus. Bei der PS1 hätte ich jetzt erstmal dafür gesorgt, dass erst das Haus gezeichnet wird und dann das Auto. In dem Bereich, wo das Auto erscheint, werden dabei im Renderingprozess die zum Haus gehörenden Pixel, die das Auto verdeckt überschrieben. Würde ich andersrum rendern, könnte ich das Auto nicht sehen, denn wenn ich das Haus später rendern würde, würde es das Auto überschreiben, obwohl es dahinter steht. Das war damals tatsächlich Sache der Software, die Reihenfolge zu entscheiden und ein großer Teil der Aufgabe einer Engine bestand damals darin zu entscheiden, was wann gezeichnet wird.

Üblicherweise hat man versucht das per Objekt zu entscheiden, aber es gab natürlich auch Fälle, wo man das auf Polygonbasis machen musste. Da wurde es dann aber teils ziemlich eklig, besonders, wenn sich Objekte durchdrangen. In solchen Situationen konnte es passieren, dass Polygone (oder Teile davon) gezeichnet wurden, die eigentlich hätten verdeckt werden sollen. Wenn das dann auch noch Grenzfälle waren, die vom Programm in jedem Frame anders entschieden wurden kam es zum Flackern der Polygone, was sehr häßlich aussah.

Die Lösung des N64 hieß z-Buffer oder Tiefenpuffer. Zu jedem gezeichneten Pixel wurde nun in einer eigenen Bitmap der Tiefenwert des Pixels festgehalten. War jetzt bei einem neu gezeichneten Pixel der neue Tiefenwert kleiner als der im z-Buffer festgehaltene, wurde der Pixel gezeichnet, denn er lag vor der bereit gezeichneten Geometrie näher an der Kamera. War er größer lag er dahinter und wurde gar nicht erst berechnet. Aus dem Grund konnte das N64 bereits sich durchdringende Polygone korrekt abbilden. Die sichtbare Schnittlinie ergab sich mit dem Algorithmus von selbst. Bei dem Beispiel mit dem Auto hätte ich das Haus jetzt auch später zeichnen können, denn jeder Pixel, der vom Auto verdeckt worden wäre, hätte beim Z-Test gegen den Wert im Puffer verloren und wäre gar nicht erst im Grafik-RAM gelandet.

Der Begriff z-Fighting übrigens ist mir dafür eigentlich nicht bekannt. Den kenn ich aus einem anderen Zusammenhang, und zwar mit z-Buffer. Wenn zwei Polygone nämlich so nah übereinanderliegen, dass die Tiefenbestimmung für den Z-Buffer im Rahmen der Maschinengenauigkeit (gern mal 16Bit bei alten Maschinen) Werte ausrechnet, die nicht eindeutig größer oder kleiner sind als die vorhandenen, dann kommt es zum Durchschimmern eines Polygons, denn welcher Wert gewinnt hängt dann mehr oder weniger vom Zufall ab. Die Pixel „kämpfen“ also um den niedrigeren Z-Wert. Das ist aber selten ein Problem für Spiele, weil da fast nie Geometrie exakt übereinanderliegt, aber ich sehe den Effekt bis heute oft in CAD-Software.