Quelle:
http://www.within3d.de/index.php?show=articles&type=showarticle&id=6&page=1
Andere äussere Erscheinungen...
Sofort ins Auge, oder besser: ins Ohr sticht die geringe Lautstärke im Betrieb: Der GameCube kommt mit nur einem einzigen Lüfter aus und das DVD-Laufwerk ist ebenfalls sehr leise (Besitzer einer Dreamcast wissen, wie störend ein lautes Laufwerk sein kann). Auch in Punkto Wärmeentwicklung schlägt sich der Würfel glänzend: Der GameCube besitzt links und rechts je eine Öffnung von etwa 5x5cm, durch die kontinuierlich Luft zirkuliert (für die, die es genau wissen wollen: Rechts kommt frische Luft rein, links wird die warme Luft rausgeblasen). Für die Zirkulation sorgt ganz allein der oben erwähnte Lüfter, welcher hinter der linken Öffnung montiert ist. Und noch etwas für die absoluten Fans: Der Cube wiegt etwas mehr als 1,3Kg.
Crashes, Bluescreens & Co. sind dem Cube unbekannt. Sogar einige fiese Tests unsererseits meisterte er bravourös und konnte sogar positiv überraschen: So löst ein öffnen des Disc-Faches nicht etwa einen automatischen Reset aus. Stattdessen kann man bequem weiterspielen und zwar bis neue Daten von der Disc benötigt werden. Dann wird das Spiel automatisch pausiert und man wird aufgefordert, das Fach wieder zu schliessen. Tut man dieser Aufforderung folge, kann man weiterspielen, als ob nichts gewesen wäre.
Auch eine anspruchsvollere Variante dieses Stresstests konnte den Cube nicht aus der Ruhe bringen: Wechselt man die Disc während des Spiels durch eine andere aus, pausiert das Spiel abermals und man wird freundlichst darum gebeten, wieder die richtige Disc einzulegen. Sobald dies getan ist, kann man weiterspielen.
Kleine, aber nicht selbstverständliche Gimmicks halt, die das Leben mit der Konsole etwas leichter machen. Sollten ausserdem einmal Spiele erscheinen, welche mehrere Discs benötigen, können diese bestimmt davon profitieren. Bisher musste man auf Konsolen vor einem Disc-Wechsel immer zuerst abspeichern, den Resetknopf drücken, die Disc auswechseln und den Spielstand neu laden. Der GameCube könnte diesem Treiben ein Ende setzen.
Apropos Discs: Ladezeiten sind mit dem GameCube auch kein Problem. Trotz den mit optischen Speichermedien verbundenen, längeren Zugriffszeiten (im Vergleich zu Cartridges), ist der Loading-Schriftzug relativ selten und wenn, dann nur für sehr kurze Zeit zu sehen.
Viel interessanter als das Design, über das man sich zweifellos streiten kann, ist aber das Innenleben der Konsole...
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. Folgende Tabelle soll dies veranschaulichen:
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 8) 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.
Last but not Least: Sound!
Man spricht immer davon, dass die Entwicklung von Soundchips mittlerweile an einem Ende angekommen ist, seit diese zu Tonwiedergabe in CD-Qualität in der Lage sind. Wir können da eigentlich nur zustimmen und daher soll der Sound-Teil des Flippers hier nur am Rande erwähnt werden.
Der im Flipper verbaute Macronix-DSP unterstützt bis zu 64 Soundkanäle gleichzeitig - natürlich in 16bit und mit einer Sampling Frequenz von 48KHz und erfüllt damit locker alle Voraussetzungen für ansprechende Musik und Soundeffekte in Spielen.
Doch etwas beherrscht der Chip nicht: Dolby Digital und/oder DTS. Da der Cube keinen optischen Digital-Out besitzt, würde dies sowieso keinen Sinn machen. Als Alternative bietet man Unterstützung für das Dolby Pro Logic II Verfahren an. Hierbei wird mit einem passenden Receiver aus dem Stereosignal ein 5.1-Surround Signal extrahiert. Qualitativ kommt es natürlich nicht an echten, digitalen 5.1 Surround-Sound heran.
Dolby Pro Logic II ist abwärtskompatibel, doch das ganze hat einen kleinen Haken: Ein Pro Logic II-Signal kann zwar problemlos von einem Decoder bearbeitet werden, welcher nur das alte Dolby Pro Logic I unterstützt, doch die Qualität leidet darunter natürlich ein wenig. Receiver, die den neuen Pro Logic II-Standard unterstützen, sind hingegen noch sehr rar gesät und es wird wohl noch ein bis zwei Jahre dauern, bis dies standardmässig von jedem Decoder am Markt unterstützt wird.
Interessant ist zudem der A-DRAM, auf den wir bereits zu sprechen gekommen sind: Auch wenn dieser mit 81MB/sec Bandbreite sehr langsame Speicher auch für andere Daten verwendet werden kann, ist er dennoch hauptsächlich für Sounddaten vorgesehen. Und 16MB sind sehr viel für einen Soundchip. Im akustischen Bereich wird es daher mit Sicherheit einiges zu sehen... pardon: zu hören geben.
Kein Konsolen-Shooutout warum?
Nun kommts: Wir verzichten in diesem Artikel auf den allseits beliebten Konsolen-Shootout. Einige Leser mögen sich nun zu Recht fragen, wieso gerade die angeblich interessanteste Frage bezüglich der neuen Konsolen verzichtet wird: Welche von den drei Systemen hat denn nun am meisten Power?
Die Antwort ist einfach: Wir können das nämlich gar nicht so pauschal sagen. Konsolen sind keine PC-Grafikkarten! Ein Grafikkarten-Shootout ist ein Kinderspiel im Vergleich zu einer fairen Gegenüberstellung dreier Konsolen.
Dies ist so, weil alle Grafikkarten auf den gleichen Software- und Hardwarestandards aufbauen. Die Grundlagen sind auf dem PC absolut identisch und heissen Windows, DirectX, OpenGL & Co. Zwei Grafikkarten können so auch unter fast exakt gleichen Bedingungen diversen Tests unterzogen werden und so kann auch ein fairer Vergleich entstehen.
Doch bei Konsolen sieht die Situation komplett anders aus: Konsolen sind in sich abgeschlossene Systeme, die in ihrer Architektur nicht unterschiedlicher sein können! Der GameCube hat mit Ausnahme der Tatsache, dass er halt auch zum Zocken da ist, nichts und wirklich rein gar nichts mit der XBox und der Playstation2 gemein. Die Unterschiede sind überall: Der GameCube nutzt eine effiziente PowerPC-CPU, die XBox eine weniger effiziente, aber höher getaktete x86-CPU und die Playstation2 eine hochkomplizierte, von Sony und Toshiba entwickelte CPU. Auch die Bus-Interfaces können nicht unterschiedlicher sein: Auf der XBox greifen alle Komponenten auf eine Unified Memory Architecture zu, auf der Playstation2 läuft das Ganze wesentlich komplizierter, ja schon fast konfus ab und die Architektur des GameCubes ist, wie schon gesagt wurde, extrem segmentiert. Oder die Software: Die XBox nutzt ein abgespecktes Windows 2000 mit den aus der PC-Welt vertrauten APIs (u.A. OpenGL und DirectX), auf der Playstation2 und dem GameCube sieht es wieder ganz anders aus. Hier kommt definitiv kein Windows zum Einsatz. Kurz: Bereits die Grundlagen der drei Konsolen sind so unterschiedlich, dass sich ein fairer Vergleich äusserst schwierig gestaltet und ohne Input von Spielentwicklern, die Erfahrung mit allen drei Konsolen haben und sie daher wohl am besten beurteilen können, vermutlich sogar unmöglich ist.
Warum dann wenigstens keine Zahlenvergleiche?
Die allseits beliebten Spezifikationsvergleiche - seien es MIPS, FLOPS, Mpixel/sec oder Dreiecksdurchsätze machen ebenfalls wenig Sinn. Das Hauptproblem wurde ja bereits erwähnt: Man kann sich hierbei nur auf die Herstellerangaben beziehen, denn man kann die Konsolen ja nicht einfach schnell mal selber benchen. Und die Hersteller vertreten in diesem Punkt meistens ganz andere Philosophien: Microsoft gibt z.B. theoretische Maximalwerte an, die in der Praxis niemals erreicht werden können. Nintendos Werte sind dagegen sehr konservativ geschätzt und wirken dadurch auch ziemlich enttäuschend - doch sind sie eben sehr praxisnah.
Das Zweite Problem ist, dass auch solche Zahlen nur wenig über das wirkliche Potential der Hardware aussagen. Was nützt z.B. eine Füllrate von 1,8Gtexel/sec (XBox), wenn die Bandbreite niemals ausreichen wird, um den Chip auch voll auslasten zu können? Die grundverschiedene Architektur macht einen fairen Spezifikationsvergleich also praktisch unmöglich.
Knackpunkt Spielentwickler
Der Hauptgrund für die Sinnlosigkeit eines Spezifikationsvergleiches liegt aber bei der Spielentwicklung auf Konsolen, die sich in einigen technischen Details stark von derjenigen auf PCs unterscheidet.
Bei der Entwicklung eines PC-Spiels hat vom technischen Standpunkt gesehen eine Sache Priorität: Die Software muss auf der grösstmöglichen Anzahl PCs stabil und schnell genug laufen. In anderen Worten: Kompatibilität ist Trumpf. Ein Spiel, das mindestens eine GeForce3 Ti-500 und eine 1,2Ghz CPU voraussetzt, wird nie finanziell erfolgreich sein.
Doch bei der Konsole gibt es keine Hardwarevielfalt und somit auch keinen kleinsten gemeinsamen Nenner, auf dem die Software laufen muss. Hier gibt es genau eine Hardware und Kompatibilität ist somit auch kein Thema. Stattdessen ist es die Hauptaufgabe des Entwicklers, aus der vorhandenen Hardware das Bestmögliche herauszuholen. Und da spielen Faktoren wie Entwicklungstools, Support und insbesondere die Hardwarekonzeption eine viel grössere Rolle, als die theoretisch maximale Leistung einer Konsole. Die schnellste Hardware auf dem Markt nützt überhaupt nichts, wenn die SDKs schlecht sind oder die Hardware so verwirrend aufgebaut ist, dass sie vom Entwickler kaum ausgelastet werden kann.
Beispiel gefällig? Auf Segas theoretisch viel schwächerer Dreamcast sind nach dem Launch von Sonys angeblicher Über-Konsole zahlreiche Titel erschienen, die sich überhaupt nicht hinter den Playstation2-Spielen verstecken mussten. Ultimatives Beispiel ist das Prügelspiel Dead or Alive 2, welches auch auf die Playstation2 geportet wurde und auf der Dreamcast trotz der schwächeren Hardware dennoch besser aussah. Der Grund: Die Dreamcast-Architektur ist übersichtlich und leicht zu verstehen und die SDKs gelten als sehr gut. Die Playstation2 hingegen ist der Alptraum eines jeden Programmierers: Neben Texturing-Schwächen ist hauptsächlich die im Vergleich zur Dreamcast theoretisch um ein Mehrfaches stärkere CPU äusserst kompliziert aufgebaut und erfordert eine sehr, sehr lange Einarbeitungszeit und viel Erfahrung vom Programmierer. Schlechte SDKs erschweren die Arbeit zusätzlich. Das Resultat: Die schwächere Hardware wurde mehr ausgereizt und konnte daher in diesem Beispiel die Stärkere übertrumpfen.
Nur das Resultat zählt
Nun kommt natürlich die berechtigte Frage auf, was denn der entscheidende Faktor beim Konsolenkauf sein soll, wenn gar kein befriedigender Hardwarevergleich gemacht werden kann. Selbst wir Technik-Freaks können da nur sagen: Am Ende zählt nur, was auf dem Bildschirm zu sehen ist: Die Spiele. Man kann noch so lange über die technischen Möglichkeiten einer Konsole jubeln, wenn die dafür erhältliche Software kompletter Schrott ist.
Beim GameCube ist dies im Moment überhaupt nicht der Fall und daran scheint sich auch in Zukunft nichts zu ändern. Die momentan erhältliche Spiele sind mit wenigen Ausnahmen alle sowohl technisch, als auch spielerisch ausgezeichnet:
An technisch vorderster Front kämpft StarWars: Rogue Squadron 2 Rogue Leader. Der Exklusivtitel von Factor5 liefert eine Grafikqualität, die auf dem GameCube, wie auch auf anderen Konsolen und dem PC Seinesgleichen sucht und erweckt das StarWars-Universum so zum Leben, wie in keinem anderen Spiel: Ob man als Luke Skywalker mit einem X-Wing durch den Graben im Todesstern aus Episode IV rast (inkl. Darth Vader im Nacken und Han Solo, der einem im letzten Moment mit dem Millennium Falcon aus der Patsche hilft), während der Schlacht auf dem Eisplanenten Hoth in Episode V die Rebellenbasis vor den riesigen AT-ATs beschützt oder in der legendären, alles entscheidenden Schlacht von Endor gegen eine Übermacht an Tie-Jäger und Sternzerstörer bestehen muss: Genau wie im Film, kommt einem wohl angesichts der Grafikpracht als Erstes in den Sinn:
Factor5 hat das Spiel innerhalb von nur 7 Monaten komplett entwickelt. Einerseits kann man natürlich sagen, dass für ein StarWars-Ballerspiel nicht allzu viel Zeit in der Designabteilung benötigt wird. Betrachtet man aber die technischen Errungenschaften des Titels, spricht diese kurze Entwicklungszeit klar für die vielgerühmte Entwicklerfreundlichkeit von Architektur und SDKs des GameCubes.
Die Lighting-Fähigkeit des GameCubes wird hingegen eindrucksvoll in Nintendos Luigis Mansion gezeigt. Mit Taschenlampe und Staubsauger bewaffnet macht man sich darin als Marios Bruder Luigi in einem unheimlichen Gemäuer auf Geisterjagd. Der originelle, aber leider etwas kurz geratene Ghostbusters-Verschnitt kann technisch mit beeindruckenden Licht- und Transparenzeffekten überzeugen:
Den ultimativen Multiplayer-Spass bietet hingegen Super Smash Brothers Melee: Die gesamte Palette der Nintendo-Charakteren, von Mario über Donkey Kong bis Pikachu, rauft sich in diesem sehr auf Action getrimmten Prügelspiel um die Wette. Bis zu vier Spieler können gleichzeitig an den Prügeleien teilnehmen. Neben Dutzenden von bekannten Charakteren und diversen Spielmodi, bietet Super Smash Brothers Melee eine unzählige Menge von Gags. Fazit: Das ultimative Party-Spiel. Auf der technischen Seite bietet das Spiel zwar keinen Kinnladenherunterklapp-Effekt wie Rogue Squadron 2, läuft aber trotz der Masse an Effekten, die ununterbrochen über den Bildschirm huschen, mit konstant 60 Frames/Sekunde und bietet daneben noch einige der liebevollsten Animationen, die je in einem Spiel zu sehen waren.
Zombies im Würfel
Auch die Zukunft sieht nicht schlecht aus: Nintendo selbst bringt natürlich zu allen bekannten Franchisen neue Spiele heraus. So ist für den GameCube ein neues Mario, ein Zelda, ein Metroid und ein Star Fox angekündigt. Wie man Nintendo kennt, wird man sich dabei mit Sicherheit nicht auf eine Recycling-Mentalität stützen und einfach grafische Updates der Vorgänger herausbringen, sondern im Gegenteil nicht mit neuen Ideen geizen. Dafür wird Miyamoto gleich selber sorgen: Jedes von Nintendo oder einer Second-Party (= Entwicklerstudios, die ihre Titel exklusiv auf einem System in diesem Fall auf dem GameCube herausbringen) verfolgte Projekt muss nämlich zuerst vom Spieldesign-Gott höchstpersönlich abgesegnet werden.
Auch bei den Third-Party Entwicklern sieht es besser als zu N64-Zeiten aus, da ja die ehemals harten Bedingungen gelockert wurden. So hat jeder grosse Entwickler (mit Ausnahme von den Jungs bei SquareSoft, die immer noch mit Nintendo im Clinch liegen) Unterstützung für den GameCube zugesagt. Der berüchtigte Mangel an Software aus N64-Zeiten wird sich also auf dem GameCube höchstwahrscheinlich nicht mehr wiederholen.
Zu guter Letzt soll auch noch auf das beliebte Kiddie-Argument eingegangen werden: Vielerorts wird kritisiert, dass Nintendo sich zu sehr auf die Familientauglichkeit der Spiele konzentriert und kaum erwachsenere Spiele also mit mehr Blut und Gewalt auf den Markt bringt. Dem GameCube kann man dies jedoch kaum vorwerfen, wenn man bedenkt, dass auf dem System exklusiv die Remakes von Capcoms ersten drei Resident Evil Teilen erscheinen. Die äusserst blutrünstigen und insbesondere im indizierungsfreundlichen Deutschland sehr kontrovers diskutierten Zombiemetzel-Spiele sind nun wirklich nichts, was man einem Achtjährigen zu Weihnachten schenkt. Als ob damit nicht genug wäre, portiert Capcom den Dreamcast-Ableger Resident Evil: Code Veronica auf den GameCube und arbeitet angeblich an einem Prequel der Serie Letzteres auch exklusiv für den Cube.
Damit nicht genug: Nintendo selbst bringt gleich Konkurrenz aus dem eigenen Haus auf den Markt: Das von Silicon Knights, ehemals PC-Entwickler und heute Second-Party von Nintendo, entwickelte Eternal Darkness soll ein Resident Evil für den denkenden Spieler werden: Mehr Rätsel und Adventure-Elemente, aber keineswegs weniger Gruselatmosphäre:
Letzte Worte...
Am Ende läuft natürlich auch dieser Artikel auf die alles entscheidende Frage hinaus: Soll man das Produkt nun kaufen, lieber zur Konkurrenz greifen oder sich das Geld besser sparen? Wer nach 32 Seiten immer noch keine Antwort auf diese Frage weiss, dem helfen vielleicht folgende abschliessende Gedanken weiter:
Eines ist klar: Der GameCube liefert bei einem konkurrenzlos günstigen Preis von 199$ eine ausgezeichnete Hardwarebasis für die kommenden Generationen von Videospielen. Gravierende Engpässe in der Architektur konnten wir keine erkennen Nintendo scheint aus den Fehlern beim N64-Design gelernt zu haben. Als einziges Manko ist eigentlich nur die fehlende Unterstützung von DVD-Wiedergabe zu erwähnen. Im Ganzen betrachtet konnte uns das System aber vollumfänglich überzeugen: Vom Preis über Design, Controller und Spiele bis hin zur Hardware gibt es in unseren Augen kaum etwas auszusetzen. Nur die fehlende RGB-Unterstützung stört uns Europäer etwas aber die Konkurrenz ist in dieser Hinsicht leider keinen Deut besser. Die Konsole ist in unseren Augen jedenfalls mehr als genug gut gerüstet, um für eine ganze Konsolengeneration genug Leistung zu erbringen und verdient somit rein technisch gesehen das Prädikat "sehr empfehlenswert".
Bleibt die Software: Hier muss man zuerst mal anmerken, dass die meisten Third Parties mit dem Erscheinen von XBox und GameCube einen klaren Cross-Plattform Kurs eingeschlagen haben: Vieles, was auf der einen Konsole erscheint, wird man etwas später wenn nicht sogar gleichzeitig - auch für die Anderen kaufen können.
Was die Produktionen von Nintendo und den Second Parties und andere mögliche Exklusivtitel von den unabhängigen Third-Parties betrifft: Diesen sollte eigentlich beim Fällen der Kaufentscheidung am meisten Gewicht zugemessen werden. Hier sieht die Situation für den GameCube ausgezeichnet aus: Die angekündigten Exklusivtitel haben praktisch alle Potential zum Klassiker. Ob Star Fox Adventures, Mario Sunshine oder Metroid Prime: Über praktisch allen Produktion wacht im Hintergrund Shigeru Miyamoto persönlich und er hat es in seiner über 20-jährigen Karriere noch nie geschafft, uns zu enttäuschen. Auch spielerisch darf man also vom GameCube viele A-Titel erwarten. Besonders, wenn man bedenkt, dass Nintendo im Geheimen an zusätzlich 25 Spielen arbeitet, die noch nicht offiziell angekündigt wurden.
Am Ende entscheidet aber insbesondere bei Nintendo der Geschmack: Die Spiele mögen alle ausgezeichnet sein, aber wer mit den auf niedlich gehaltenen Charakteren von Nintendo nichts anfangen kann, bedient sich wohl besser bei der Konkurrenz. Denn auch wenn mit StarWars: Rogue Leader, Resident Evil und Eternal Darkness die Anzahl an erwachseneren Spielen bei Nintendo zunimmt, werden viele Toptitel halt dennoch auf ein niedlicheres Design à la Mario setzen. Wer sich nicht daran stört oder dies sogar mag, dem sei an dieser Stelle der GameCube wärmstens empfohlen. Denn wie Nintendo seit über 15 Jahren beweist, verstecken sich hinter dem manchmal etwas gewöhnungsbedürftigen Design wahre Perlen des Spieldesigns. Wer sich jedoch nicht mit dem Design anfreunden kann, der sollte wohl eher zur Konkurrenz greifen, wo tendenziell weniger verniedlicht wird.
Am besten kauft man sich sowieso alle Konsolen und kommt so in den Genuss von allen Toptiteln denn diese gibt es natürlich nicht nur auf dem GameCube. Nur fällt diese Lösung mit nur schon 1600sFr. (2150DM) für die Hardware halt recht kostspielig aus...
Der GameCube ist momentan nur als US- oder Japan-Import erhältlich und setzt daher einen NTSC-fähigen TV voraus. Alternativ kann er auch über eine VGA-Box eines Drittherstellers mit jeden PC-Monitor verbunden werden. In Europa wird die Konsole voraussichtlich im April 2002 veröffentlicht. Ein genaues Datum wurde noch nicht genannt.
Komisch.. 
??:
tra3: