Man kann die Konsolen nur schwer miteinander vergleichen. Hier aber ein kleiner Einblick von ner Hardware Homepage:
Das Board: Kompakt und aufgeräumt
Das Mainboard ist ein schönes Beispiel von durchdachtem Hardwaredesign. Das Ganze System kommt mit nur fünf grösseren Chips aus und ist trotz seiner geringen Grösse nicht mit Kondensatoren und anderen Beilagen überladen. Das Board ist kaum grösser als ein CD-Case.
Nervenzentrum des Systems bildet der Flipper. Das 52Mio.Transistoren-Monster bringt Grafikchip, Soundchip und Northbridge unter einen Hut. Auf dessen Funktionalität wird später genauer eingegangen.
Alle übrigen Komponenten sind direkt mit dem Flipper verbunden: Die Gekko genannte CPU, die 24MB Hauptspeicher und 16MB langsamer A-DRAM für den Soundchip.
Viele Interfaces
Bevor Flipper und Gekko etwas genauer unter die Lupe genommen werden, verdient das Platinenlayout seine Aufmerksamkeit und eine Speichertechnologie, die auf dem GameCube Premiere feiert: 1T-SRAM.
Die Architektur des GameCube ist sehr segmentiert. Im Zentrum steht der Flipper bzw. dessen Northbridge-Teil. Mit 162Mhz gibt er den Systemtakt an. Vom Flipper gehen drei Verbindungen aus:
Der CPU-Bus: Ebenfalls mit 162Mhz getaktet bietet dieser 64bit breite Bus eine Bandbreite von 1,3GB/sec, was genug für die mit 485Mhz getaktete CPU sein sollte.
Der A-DRAM Bus: Dieses 8bit-Interface läuft mit 81Mhz (halber Flipper-Takt) und leistet somit mickrige 81MB/sec. Der A-DRAM ist jedoch nicht für bandbreitenfressende Zwecke vorgesehen. Der Name steht für Audio-DRAM und ist damit selbsterklärend: Alles, was irgendwie mit Sound und Musik zu tun hat, läuft über diesen Bus ab. 81MB/sec reichen dabei problemlos aus: 64 Tonkanäle in CD-Qualität nehmen nämlich nur etwa 6MB/sec in Anspruch.
16MB Speicher allein für Audiodaten sind sehr grosszügig bemessen. Doch laut Nintendo kann der Gekko problemlos direkt auf den A-RAM zugreifen, so dass der Speicher auch für andere Zwecke, welche nicht gerade Bandbreite zum Frühstück verspeisen, verwendet werden kann.
Der Hauptspeicherbus ist aber mit Abstand der Interessanteste von allen, denn dort kommt eine neue, relativ unbekannte Speicherart zum Einsatz
1T-SRAM: SRAM und SDRAM fusioniert
Dieser Bus ist zugleich der schnellste: Ein mit 324Mhz (doppelter Flipper Takt) getaktetes 64bit Interface (2,6GB/sec Bandbreite) verbindet die 24MB Speicher mit dem Flipper. 324Mhz? Kein Schreibfehler. Der Speicher ist wirklich so schnell getaktet, verwendet dabei auch keine DDR-Technologie und ist trotzdem schön billig.
Dahinter steckt der von MoSys Inc. Entwickelte 1T-SRAM. 1T steht für 1 Transistor und auch hier ist der Name bereits wieder selbsterklärend: Der MoSys-Speicher benötigt pro Bitzelle nur einen einzigen Transistor (konventioneller SRAM benötigt dafür 4-6 Transistoren). Die Vorteile: Günstigere Produktion und geringere Wärmeentwicklung. Die Technologie ist dabei eine Mischung aus SRAM und SDRAM, welches die Vorteile von beiden Speichersorten vereint: Vom SDRAM der niedrige Preis und vom SRAM der hohe Takt und die niedrigen Latency-Werte: Dieser beträgt beim Hauptspeicher des GameCubes nämlich nur etwa 10ns (Der Latency-Wert von PC133-SDRAM bewegt sich bei etwa 80ns). Dazu kommt das 64bit-Interface und eine synchrone Taktung des gesamten Systems (alle Komponenten laufen mit einem Mehrfachen bzw. einem Bruchteil des Flipper-Taktes). Somit kann man auch bei nicht linearen Speicherzugriffen eine sehr hohe Effizienz vom 1T-SRAM erwarten.
Aber ist eine gesamte Speicherbandbreite von etwas mehr als 2,6Gbyte/sec nicht etwas wenig für all die aufwendigen Grafikberechnungen? Abwarten der GameCube hat nämlich anderswo noch ein wenig Speicher und viel Bandbreite auf Lager
Zusammenfassend lässt sich sagen, dass man bereits bei Betrachtung des gesamten Systems Nintendos Absicht erkennen kann, auf Effizienz und Kostenreduktion statt auf pure Rechenpower zu setzen. Vergleicht man das Design z.B. mit der XBox, wo dem ganzen System einfach eine grosse Menge schnellerer, aber gleichzeitig auch teurer und ineffizienter DDR-SDRAM spendiert wurde, auf den alle Komponenten mehr oder weniger direkt zugreifen, ging man beim GameCube einen ganz anderen Weg: Zwei langsamere, aber hocheffiziente Speicherinterfaces (und zwei Zusätzliche, auf die wir aber erst später zu sprechen kommen), eine sehr segmentiere Architektur, keinen zusätzlichen Chip für den Sound und die Northbridge: Alles im GameCube schreit förmlich nach Kostenoptimierung. Ein cleverer Programmierer sollte ohne grosse Einarbeitungszeit in der Lage sein, aus dieser überschaubaren Architektur jede Menge Leistung herauszukitzeln.
Falsch oder richtig ist natürlich keine der beiden genannten Methoden es sind nur zwei völlig verschiedene Philosophien.
Gekko: RISC-Technologie von IBM
PowerPC ist zumindest jedem Mac-User ein Begriff: Der von Motorola und IBM gemeinsam entwickelten Architektur liegt jede Macintosh-CPU zu Grunde. Aber auch in IBMs Server und Workstations hat sich diese RISC-Architektur bewährt. Auch im GameCube kommt ein PowerPC zum Einsatz: Der Gekko basiert auf dem 750CXe-Core und ist somit wohl am nächstem mit der auf Macs verwendeten G3-CPU verwandt. Sie ist mit 485Mhz (vierfacher Flipper-Takt) getaktet, reichlich mit Cache bestückt (64KB Level-1 und 256KB Level-2 Cache) und wird in 0.18μ mit Kupfer-Interconnects gefertigt.
Der Gekko wurde ausserdem um einige speziell auf Spiele zugeschnittene Funktionen erweitert: So spendierte IBM dem Core 38 zusätzliche, auf 3D-Berechnungen zugeschnittene Instruktionen. Viel wichtiger ist aber die Modifikation an der in Spielen stark genutzten Floating Point-Einheit: Im Original arbeitet diese mit 64bit Variablen, für Spiele reichen hier aber gewöhnlich 32bit-Werte. Also hat man die FPU so modifiziert, dass sie entweder zwei 32bit Operationen oder eine 64bit Operation pro Taktzyklus durchführen kann. Durch diesen Eingriff kann die CPU wesentlich höhere Leistungswerte erreichen, da die FPU im Optimalfall ja doppelt so viele Operationen durchführt (wenn keine 64bittige genutzt werden).
Damit die externe Bandbreite ausserdem nicht zu knapp wird (1,3Gbyte/sec sollten zwar ausreichen) unterstützt der Gekko zudem eine (nicht verlustfreie) Kompression, mit der 32bit Fliesskommazahlen in 8bit oder 16bit Integerwerte und umgekehrt umgewandelt werden können. Dabei geht natürlich an Genauigkeit verloren, aber wenn diese keine allzu grosse Rolle spielt, kann dadurch einiges an Bandbreite gespart werden.
Die PowerPC Architektur gilt übrigens als sehr effizient und braucht sich trotz des für PC-Verhältnisse niedrigen Taktes nicht zu verstecken. Dank RISC-Architektur liefert der Gekko nämlich mehr Leistung pro Megahertz, als z.B. die auf Windows-PCs gebräuchlichen x86-CPUs. Es wird gesagt, dass ein cleverer Programmierer aus dem Gekko gut und gerne Leistungswerte eines 900Mhz PentiumIII oder mehr herauskitzeln kann. Aber mit solchen Aussagen sollte man auch vorsichtig umgehen, denn die beiden Architekturen sind nun wirklich grundverschieden.
Flipper: Alleskönner von ATI/ArtX
Im Mittelpunkt des Cubes steht aber nicht der Gekko, sondern dessen grösserer Bruder, genannt Flipper. Dieser relativ komplexe Chip (51 Mio. Transistoren) vereint Grafik-, Sound- und Northbridge-Funktionalität auf einem Die. Er wurde ursprünglich von ArtX, einem aus ehemaligen Silicon Graphics-Ingenieuren gegründeten Start-Up, entwickelt. Letztes Jahr wurde ArtX von ATI geschluckt, auf die damals fast abgeschlossene Entwicklung des Flippers hatte dies jedoch kaum einen Einfluss.
Bevor der Chip nun aber im Detail betrachtet wird, soll erwähnt werden, dass ATI und Nintendo nur wenige Informationen zur Flipper-Architektur preisgegeben haben. Die gröbsten Spezifikationen sind zwar erhältlich, aber sobald es ins Detail geht (z.B. die verwendete FSAA-Art), sind handfeste Informationen nur schwer zu finden. Einige Angaben zur Hardware stammen also nicht direkt vom Hersteller, sondern wurden entweder von uns mit Hilfe von anderen, öffentlich zugänglichen Spezifikationen hergeleitet, stammen von diversen Spielentwicklern oder gehören ins Reich der Vermutungen. Ist dies der Fall, wird natürlich an der betreffenden Stelle im Artikel auch darauf hingewiesen.
Mehr als ein DirectX7-Chip
Der Chip ist mit 162Mhz getaktet und liefert eine Pixelfüllrate von 648 Mpixel/sec, was auf 4 Rendering-Pipelines hinweist. Mit 648 Mpixel sind ausserdem nicht bilinear, sondern bereits trilinear gefilterte Pixel gemeint. Eine Texelrate gibt Nintendo nicht an, was eigentlich nur bedeuten kann, dass der Flipper mit einer Textureinheit pro Pipeline auskommen muss.
Erwähnt werden sollte zudem, dass der Flipper nur in 24bit Farbtiefe rendert. Doch gleichzeitig besitzt der Chip einen Postfilter, welcher ohne zusätzliche Rechenpower eine dem 32bit-Rendering in fast nichts nachstehende Bildqualität liefert. Genaues über diesen Filter ist nicht bekannt, wir vermuten aber, dass hier ein ähnliches Verfahren zum Einsatz kommt, wie auf den Voodoo3/4/5-Karten von 3dfx, auf denen ein sog. 22bit Postfilter die Bildqualität ohne Performanceverlust etwas verbesserte.
In der von Nintendo veröffentlichten Spezifikationsliste finden sich ausserdem diverse 3D-Features. Neben seit Jahren zum Standard gehörenden Funktionen wie bilineares und trilineares Filtering, MIP-Mapping oder Fog, unterstützt der Flipper auch alle Bump Mapping-Verfahren (Dot3 Product, Enviromental), Enviroment Mapping (Sphere, Cube), anisotropes Filtern, S3TC und Geometrie-Kompression.
Irrtümlicherweise wird mancherorts vermutet, der Flipper sei wie der Kyro ein Tile Based defered Renderer. Dies ist nicht der Fall, der Chip ist ein gewöhnlicher immediate Renderer. Als Hidden Surface Removal-Methode werden lediglich frühe Z-Checks unterstützt. Dabei werden die Z-Werte bestimmter Pixel vor dem Rendern mit denen von bereits gerenderten Pixeln verglichen. Dadurch kann bestimmt werden, ob ein Pixel sichtbar ist oder nicht. Ist letzteres eindeutig der Fall, wird es gar nicht gerendert, wodurch wertvolle Füllrate und Bandbreite gespart wird. Das Verfahren ist jedoch niemals so effizient wie echtes defered Rendering und läuft zudem nicht automatisch ab: Die Spielengine muss speziell auf frühe Z-Checks ausgelegt werden.
Geometrisches...
Vertex- und Pixelshader sucht man auf dem Chip hingegen vergeblich und dies hat schnell auch mal Aussagen im Stil von der Flipper ist nichts als ein Chip nach DirectX7-Standard mit unbrauchbarem T&L provoziert. Doch damit wird der GameCube bereits zu stark mit einem PC gleichgesetzt. Auf dem Cube gibt es kein DirectX. Und keine Vertex Shader bedeutet daher auch noch lange nicht, dass der Flipper eine T&L-Unit im Stil der berüchtigten Implementierungen der ersten Generation (GeForce256, GeForce2, Radeon) mit langsamer Transformation-Engine und unbrauchbarer Lighting-Unit aufweist. Im Gegenteil: Die T&L-Unit des Flippers ist sogar in der Praxis relativ schnell. Die offizielle Zahl von Nintendo fällt zwar mit 12 Millionen Dreiecke pro Sekunde verhältnismässig niedrig aus, doch von Spielentwicklern war zu hören, dass diese Zahl sehr, sehr konservativ geschätzt ist und erst auf eine aufwendige Szenerie mit Multitexturing und mehreren Lichtquellen zutrifft. So soll der Flipper in einer untexturierten, gouraud-schattierten Umgebung ca. 40 Millionen Dreiecke in der Sekunde berechnen. Mit einer Textur fällt der Dreiecksdurchsatz auf 33 Millionen Polygone pro Sekunde, mit Shading, einer Textur und einer Lichtquelle auf 25 Millionen. Was für eine Art Lichtquelle (Directional Light, Spot Light usw.) in diesem Beispiel verwendet wird, ist uns jedoch nicht bekannt. Genaue Angaben zum Einfluss von Texturing und Lighting auf den Dreiecksdurchsatz sind jedoch nicht öffentlich zugänglich. Es ist lediglich bekannt, dass der Flipper bis zu 8 Lichtquellen gleichzeitig berechnen kann. Wie stark die Polgyonenrate darunter leidet, hängt von der Art der verwendeten Lichtquellen ab.
Übrigens: Auch wenn alle diese Zahlen im Vergleich mit den 115 Millionen des NV2A (XBox) erbärmlich erscheinen, muss man bedenken, dass die Werte von Microsoft sich nicht auf Dreiecke, sondern nur auf deren Eckpunkte beziehen und zwar auf unbeleuchtete und nicht geshadete (von der T&L-Unit des Flippers kann man auch problemlos behaupten, sie leiste maximal 120 Mio. Vertices in der Sekunde - 40Mio. Dreiecke x 3). Um so einen hohen Dreieckswert zu erreichen, müsste die gesamte Szenerie zudem in Strips unterteilt werden, was sich aber in der Praxis als völlig unpraktikabel erweisen würde. Und damit werden diese Werte in Spielen wohl auch niemals erreicht werden.
TEV: Multitexturing auf hohem Niveau
Neben dem Vertex Shader fehlt dem Flipper auch ein Pixel Shader, doch stattdessen hat man dem Chip eine mächtige Multitexturing-Engine spendiert, die auf den Namen Texture Enviroment (TEV) hört. Doch auch hier sind Details leider nur Entwicklern zugänglich. Laut Julian Eggebrecht vom Entwicklerteam Factor5 (Star Wars: Rogue Squadron 2) kann das TEV jedenfalls in einem Renderingpass bis zu 8 Texturen auf ein Polygon auftragen. Dies beherrscht momentan sonst nur der Kyro von PowerVR. Ausserdem werden bis zu 16 Texture Stages pro Pass unterstützt. Texture Stages sind Operationen, mit denen die Texture Blending-Vorgänge vom Entwickler gesteuert werden können. Abhängig davon, wie diese (und wie viele davon) kombiniert werden, kommen völlig verschiedene Resultate heraus. Damit erreicht das TEV zwar noch lange nicht die Flexibilität eines echten Pixel Shaders, wo der Entwickler solche Operationen selber programmieren kann, doch bietet er den Entwicklern im Vergleich zu den vom PC bekannten Multitexturing-Engines (DirectX7 und tiefer) eine verhältnismässig hohe Flexibiltät. Bestes Beispiel dafür ist das Action-Adventure StarFox Adventures von Rare, dessen Engine auch ohne Pixel Shader einen Effekt darstellen kann, welcher von diversen Hersteller eben gerade im Hinblick auf die Pixel Shader gehypt wurde: Überzeugend wirkendes Fell. Ein solches Beispiel kann eigentlich nur bedeuten, dass das TEV tatsächlich um einiges flexibler ist, als die vom PC bekannten Multitexturing-Engines.
RAM an Bord!
Kommen wir aber endlich auf den interessantesten Teil des Flippers zu sprechen. Der Chip besitzt neben einem Grafik-, Sound- und I/O-Teil nämlich auch noch eine ansehnliche Menge direkt auf dem Chip verbauter Speicher: Ganze 3MB wurden darauf untergebracht ebenfalls hocheffizienter und platzsparender 1T-SRAM. 2MB davon sind für den Frame- und Z-Buffer reserviert, welche ziemlich genau darin Platz haben (vom Framebuffer ist nur der Backbuffer auf dem On-Chip Speicher untergebracht. Der Frontbuffer wird regelmässig in den Hauptspeicher geschrieben). Das übrige eine MB dient als Texturencache. Die Architektur ist auch hier wieder segmentiert: Sowohl der Texturencache, als auch der Frame/Z-Buffer besitzen ihr eigenes Speicherinterface.
Dieser Speicher ist logischerweise sehr schnell: Die Verbindung zum Frame/Z-Buffer besteht aus vier 96bit breiten Interfaces. Bei einem Chiptakt von 162Mhz resultiert dies in einer Bandbreite von 7,8GB/sec fast so viel, wie die gesamte Bandbreite einer GeForce3 Ti-500. Doch sind diese 7,8GB/sec alleine für Frame- und Z-Buffer Zugriffe da. Für aufwendige Multipass-Effekte ist also mehr als genug Bandbreite da und die bereits erwähnten frühen Z-Checks können dank der im Überfluss vorhandenen Bandbreite auch problemlos durchgeführt werden.
Der Texturencache ist sogar noch schneller: Dieser ist in 32 je 32Kbyte grosse Stücke aufgeteilt, von denen jedes ein eigenes 16bit-Interface besitzt. Resultat: 10,4GB/sec Bandbreite allein für Texturenzugriffe. Im Texturencache können zudem S3TC-komprimierte Texturen abgelegt werden, wodurch effektiv 6 MB an Texturdaten abgelegt werden können (dies sind z.B. 12 Stück 512x512x16bit Texturen).
Dank diesen beiden grossen, schnellen und dank der tiefen Latency von 1T-SRAM auch sehr effizienten Caches ist der Flipper perfekt für die aufwendigen Texturing-Effekte des TEV ausgelegt: Ohne den externen Speicher zu belasten, können auf dem Chip problemlos Pixel und Texturen herumgeschoben werden Bandbreite ist ja genug vorhanden. Auch der externe Hauptspeicher wird durch den Cache stark entlastet, so dass die mickrig erscheinenden 2,6Gbyte/sec problemlos neben Programmcode und Geometriedaten auch für eine grosse Menge zusätzlicher Texturen ausreichen.
Der einzige limitierende Faktor ist wohl die Füllrate: 648Mpixel/sec gelten nur für eine Textur pro Polygon. Bei zwei Texturen reduziert sich die Füllrate auf 324Mpixel, bei vier 162Mpixel und bei acht auf 81Mpixel. Hier müssen wohl die frühen Z-Checks dafür sorgen, dass nicht zuviel Füllrate an unsichtbaren Pixeln vergeudet wird.
Effizientes Texturenmanagement aus der Profiecke
Der Texturencache des Flippers ist zwar mit 1MB (bzw. 6MB mit S3TC) relativ gross bemessen, doch unbegrenzt Ressourcen stehen dann doch nicht zur Verfügung. Es muss irgendwie sichergestellt werden, dass im Cache nur die Daten gelagert werden, die auch wirklich gebraucht werden. Um die Effizienz dieses grossen Texturencaches zu maximieren, hat man dem Flipper daher ein interessantes, aber wenig beachtetes Feature spendiert: Virtual Texturing. Dieses Feature ist im Enduser-Markt relativ unbekannt, da es von keinem Grafikchip genutzt wird, in der Profibranche findet es aber schon seit längerer Zeit Anklang. So propagiert z.B. 3Dlabs, ein alteingesessener Entwickler von Profikarten, seit längerem deren Virtual Texturing Fähigkeit.
Möglichkeiten für Cache-Ineffizienz gibt es zuhauf: So muss man sich z.B. eine beliebige Textur vorstellen. Nehmen wir eine 512x512x24bit Textur, mit S3TC 6-fach komprimiert, also 128KB gross. Diese Textur ist nun aber nur zur Hälfte im Bild. Die andere Hälfte befindet sich in unserem Beispiel ausserhalb des Sichtfeldes und wird daher vom Rasterizer ignoriert. Doch um die sichtbare Hälfte rendern zu können, muss trotzdem die ganze Textur in den Speicher geladen werden. 64KB des Caches werden also von nutzlosen Daten belegt.
Vorhang auf für Virtual Texturing: Jede einzelne Textur wird dabei in kleine Kacheln zerlegt (die Kachelgrösse beim Flipper ist unbekannt) und es werden nur die Kacheln in den Cache abgelegt, die auch wirklich in der Szenerie benötigt werden. In unserem Beispiel wird also nur die halbe Textur (genau gesagt: alle Kacheln des sichtbaren Teils der Textur) in den Cache geladen und somit stehen die vorher nutzlos belegte 64KB für andere Daten zur Verfügung.
Virtual Texturing ist zudem bandbreitenschonend. Die benötigte Bandbreite wird dabei jedoch nicht reduziert, sondern regelmässiger verteilt. Um dies zu verstehen stelle man sich folgendes Beispiel vor: In einer relativ grossen Entfernung zum Betrachter befindet sich eine Bodentextur. Um Rechenpower und Texturencache zu sparen, wird natürlich eine tiefe Detailstufe verwendet. Nun nähert man sich der Textur bis man an die Stelle kommt, wo die tiefe Detailstufe nicht mehr ausreicht und man eine detailliertere Version benötigt. Für gewöhnlich würde der Chip nun diese grössere Textur sogleich komplett in den Speicher laden, was die Bandbreitenanforderungen für kurze Zeit in die Höhe schnellen lässt. Doch Sinn macht dies nicht, da im Bild ja nur ein kleiner Teil dieser grossen Textur auch verwendet wird (im hinteren Teil wird immer noch die kleinere Textur verwendet). Mit Virtual Texturing wird wiederum nur der Teil der Textur in den Speicher geladen, der auch wirklich benötigt wird. Nähert man sich in unserem Beispiel nun weiter der Textur, wird Kachel für Kachel der grösseren Version in den Cache nachgeladen, statt dass die ganze Textur auf einmal geholt werden muss. Dadurch wird die benötigte Bandbreite für das Laden der Textur auf einen grösseren Zeitraum verteilt. Kurze Einbrüche der Framerate durch plötzliches Ansteigen der benötigten Bandbreite tritt dadurch viel weniger oft auf.
Fiese TV-Normen und passende Gegenmassnahmen
Der Fernsehschirm ist nicht gerade ein Garant für ein scharfes, flimmerfreies Bild. Dies hat zwei Gründe: Zum einen hat der Fernseher eine für PC-Verhältnisse fast schon skandalös tiefe Auflösung: Das in Europa gebräuchliche PAL-Format ist 720x576 Pixel gross, das in Amerika etablierte NTSC-System verwendet sogar noch kleinere Bilder: Mit 720x480 Pixel muss man da auskommen (die vertikale Auflösung ist in Wirklichkeit etwas höher, aber sichtbar sind nur die 576 bzw. 480 Zeilen. Die anderen, unsichtbaren Zeilen enthalten u.A. Steuerinformationen). Dafür hat NTSC einen anderen Vorteil: Die Vertikale Frequenz beträgt 60Hz, während die PAL-Norm mit nur 50Hz auskommt.
Damit aber nicht genug: Der Fernseher geht nämlich gelinde gesagt ziemlich sparsam vor und bringt noch das sog. Interlacing ins Spiel. Interlacing ist ein Verfahren, bei dem während des Bildaufbaus nur die Hälfte der horizontalen Bildzeilen angezeigt werden (z.B. alle geraden Zeilen). Beim folgenden Bild wird dann die andere Hälfte (also die ungeraden Zeilen) berücksichtigt, beim Nachfolgenden wieder die geraden Zeilen usw. Dadurch halbiert sich die effektive Vertikalfrequenz auf jämmerliche 25Hz (PAL) bzw. 30Hz (NTSC). Als Vergleich: Selbst der billigste PC-Monitor schafft heute in 640x480 locker 100Hz.
Auf das Problem der niedrigen Auflösung kommen wir später zu sprechen. Momentan interessiert nur, was man gegen diese niedrigen Bildwiederholraten und das damit verbundene Flimmern unternehmen kann.
Nintendo hat hierfür einen sog. 3-line Deflickering Filter in den Flipper eingebaut. Der Name ist auch hier Programm: Um dem störenden Geflacker entgegenzuwirken, fliessen neben der eigentlichen Bildzeile auch die Informationen von den zwei Benachbarten (oberhalb und unterhalb) in die Berechnung ein, bevor die endgültige Zeile an den Fernseher geschickt wird. Da durch das Interlacing die benachbarten Zeilen sowieso nicht angezeigt werden würden, macht dies durchaus Sinn. So fliessen trotz Interlacing in jedes Frame die Informationen aller berechneten Pixel ein. Effekt: Das Flimmern lässt stark nach. Da der Flipper kein interlaced, sondern immer ein ganzes Bild rendert, verbrät der Deflickering Filter auch keine zusätzliche Rechenpower.
Ganz ohne Nebenwirkungen ist dieser Filter dann aber doch nicht: Das Ganze ist im Grunde genommen nämlich nichts anderes als ein Blur-Filter und damit müssen leichte Abstriche in der Bildschärfe gemacht werden. Dies ist aber auf einem normalen Fernsehschirm kaum erkennbar (es sei denn, man setzt sich 30cm vor diesen hin). Die leicht verbesserte Bildschärfe bei deaktiviertem Deflickering Filter (gewisse Spiele bieten diese Option) steht in keinem Verhältnis zum Geflimmer, das dadurch auftritt.
FSAA: Smoothvision-mässig?
Das Flimmerproblem wäre mit dem Deflickerer mehr oder weniger gelöst, doch da wäre immer noch die sehr tiefe Auflösung und die damit verbundenen Aliasing-Artefakte. Der Deflickering Filter beseitigt als positiven Nebeneffekt zwar auch etwas Aliasing, aber genug ist das noch nicht. Jeder aufmerksame Leser kennt hierfür natürlich sogleich die Lösung: Full Scene AntiAliasing.
Und hier haben sich die Jungs bei ATI/ArtX etwas Besonderes einfallen lassen: Der Entwickler kann hier selber bestimmen, wie viele Subpixel pro Pixel genommen werden (zwischen 2 und :cool: und hat so eine einfache Methode zur Hand, den bestmöglichen Kompromiss zwischen Bildqualität und Performance zu finden. Wir vermuten, dass das FSAA im Flipper mit dem Smoothvision des Radeon 8500 verwandt ist, da dies ja nach einem ähnlichen Prinzip funktioniert. Dies lässt natürlich auch Raum für die Spekulation offen, dass der Entwickler auch beim Flipper nicht nur die Anzahl Subpixel, sondern auch das verwendete Subpixelmuster bestimmen kann. Während dieses Feature auf einem PC nämlich relativ sinnlos ist, würde es dank der einheitlichen Hardware auf einer Konsole sicher auf mehr Interesse der Spielentwickler stossen.
Mehr Informationen zum Smootvision-AntiAliasing gibt es in unserem Radeon 8500-Preview.
Um nun nicht noch mehr in Spekulationen abzudriften, sei an dieser Stelle einfach gesagt, dass das Full Scene AntiAliasing des Flippers wenig zu wünschen übrig lässt: Von den 4 Spielen, die wir getestet hatten, nutzte jedes FSAA und den Deflickering Filter. Störende Artefakte waren in allen Titeln überraschend rar gesät. Natürlich ist es nichts im Vergleich zu einem 1024x768-Bild mit 4xFSAA auf dem PC, aber man muss bedenken, dass man es hier mit einer Auflösung von nur 525x480 Pixel (NTSC) zu tun hat. Unter diesen Voraussetzungen leistet der GameCube in Punkto Bildqualität ausgezeichnete Arbeit.
Nun zu meiner Meinung:
In meinen Augen ist es was die Grafik angeht noch schwer zu sagen wer im Enddefekt die Nase vorn haben wird, doch zum Launch ist es der Gamecube. Ihr könnt sagen was ihr wollt aber wer einmal auf der GamesPro-DVD DOA3 und Halo mit Rouge Leader verglichen hat, weiß was ich meine.
Und schließlich sind das PC-Spieler von der Gamestar. Deren Grafik Wertungen:
DOA3: 90%
Halo: 90%
Rouge Leader: 95%
