1 Punkte von GN⁺ 2024-04-19 | 1 Kommentare | Auf WhatsApp teilen
  • Der Halo 2 HD-Patch für die originale Xbox ist ein Projekt, das Modifikationen an der ausführbaren Datei, Umbauten an der Konsolenhardware und eigens entwickelte Benchmark-Tools kombiniert, um Rendering über 480p hinaus in 720p und 1080p zu ermöglichen.
  • Das bestehende Halo 2 zeichnete entgegen der 480p-Angabe intern in einen 640×480-Backbuffer und ließ die GPU anschließend auf 720×480 hochskalieren. Für HD-Unterstützung mussten deshalb sowohl die D3D-Buffer als auch die Verarbeitung der Videomodi angepasst werden.
  • Für 720p reichten die standardmäßigen 64 MB RAM nicht aus; nötig waren ein 128-MB-RAM-Upgrade und ein Kernel-Hotpatch, der die Beschränkung umging, damit zusammenhängender physischer Speicher für die GPU auch in den oberen 64 MB zugewiesen werden konnte.
  • Die Leistung wurde durch Triple Buffering, Tiling des texaccum-Render-Targets und ein GPU-Overclocking von 233,33 MHz auf 300 MHz verbessert; die Zanzibar-Benchmarkszene stieg damit von rund 19 FPS auf etwa 27–28 FPS.
  • Zusätzlicher RAM wurde außerdem für größere Textur- und Geometrie-Caches sowie bessere HDD-Übertragungsraten genutzt. Der finale Patch brachte 720p auf ein praktisch nutzbares Niveau, während 1080p eher ein Bonus für Screenshots blieb.

Projektziel und Hardware-Grundlage

  • Ziel war es, der originalen Xbox-Version von Halo 2 HD-Auflösungen hinzuzufügen und zu prüfen, wie weit sich modifizierte Konsolenhardware belasten lässt.
  • Zum Umfang gehörten Spiel-Patches, Änderungen an der Xbox-Hardware und die Entwicklung eigener Tools für Performance-Benchmarks.
  • Die als Grundlage genutzte modifizierte Xbox wurde „god box“ genannt und umfasste folgende Änderungen:
    • Austausch der standardmäßigen 733-MHz-Pentium-3-CPU per Custom-Interposer-Board gegen eine 1,4-GHz-Variante des Pentium 3
    • Overclocking der CPU auf ungefähr 2 GHz möglich
    • zusätzlicher RAM und Einsatz einer SSD
    • Nutzung eines Custom-Kernels oder BIOS-Images zur Unterstützung der Hardware-Mods
  • Die maximal unterstützte Videoauflösung von Halo 2 war 480p; Ziel war, 720p und wenn möglich 1080i hinzuzufügen.
  • Eine höhere Auflösung erhöht die Rechenlast der Pixel-Shader und damit die GPU-Belastung, daher lohnte sich die Arbeit nur, wenn GPU-Overclocking möglich war.
    • Später wurde ein GPU-Overclocking von etwa 15 % möglich, und die Konsole „GENESIS-3“ stand für die Entwicklung bereit.

Halo 2s 480p und interne Rendering-Struktur

  • Halo 2 unterstützt laut Verpackung 480p, aber im D3D-Present-Parameter war D3DPRESENTFLAG_PROGRESSIVE nicht gesetzt, und der Screen-Scale-Wert war stets 1.0f.
  • Die internen screen_bounds wurden unabhängig vom Videomodus auf 640×480 gesetzt.
    • Auf der originalen Xbox wird 480p als 720×480 behandelt.
    • Halo 2 rendert in einen 640×480-Backbuffer, den die GPU anschließend auf 720×480 hochskaliert und an den Video-Encoder weitergibt.
  • Im Widescreen-Modus wird eine anamorphe Kamera mit 1,33:1 verwendet, um auf derselben 640×480-Oberfläche ein breiteres Bild zusammengedrückt zu rendern.
    • Dieses Verfahren könnte dazu gedacht sein, die horizontale Stauchung durch den Stretch-Modus des Fernsehers auszugleichen.
    • Dem Patch wurde auch eine Option hinzugefügt, anamorphes Scaling zu deaktivieren.

D3D-Patch für HD-Rendering

  • Für die Auflösungsunterstützung standen drei Funktionen im Mittelpunkt der Änderungen:
    • _rasterizer_detect_video_mode: so geändert, dass Progressive Scan auch bei 720p aktiviert wird
    • _rasterizer_init_screen_bounds: setzt je nach Videomodus Größen von 640×480, 720×480, 1280×720 und 1920×1080
    • rasterizer_device_initialize: setzt D3D-Backbuffer und Present-Flags
  • Im 1080i-Modus wird nach Prüfung auf 1920 Pixel Breite D3DPRESENTFLAG_PROGRESSIVE entfernt und D3DPRESENTFLAG_INTERLACED gesetzt.
  • Nach den ersten Änderungen verschwand der blaue Filter im Hauptmenü, und es traten sich wiederholende Streifen sowie abgeschnittene Wassergeometrie auf.
    • Ein Teil der Probleme entstand durch hartkodierte 640×480-Views für Back-, Front- und Depth-Buffer.
    • Dabei entstanden Textur- und Surface-Views mit unterschiedlicher Breite auf denselben Speicher, wodurch die Anordnung der Scanlines verrutschte.

D3D-Speicher und Rekonfiguration der Render-Targets

  • Die originale Xbox besitzt eine Unified-Memory-Architektur, bei der CPU und GPU denselben RAM nutzen.
    • Anders als beim PC werden D3D-Allokationen nicht im VRAM angelegt und von der GPU verwaltet.
    • Die CPU kann Speicher für Texturen, Render-Targets und Vertex-Buffer anlegen und der GPU die Adresse direkt übergeben.
  • Halo 2 verwendet etwa 25 Render-Targets, tatsächlich aber nur 4 bis 5 eindeutige Buffer-Allokationen.
    • Mehrere Render-Targets teilen sich denselben Speicher über unterschiedliche Resource-Views, um Speicher zu sparen.
  • rasterizer_primary_targets_initialize erzeugte aus den von D3D angelegten Back-, Front- und Depth-Buffern zusätzliche Render-Targets und Textur-Views und hatte dabei 640×480 hartkodiert.
  • Der Patch kapselt diese Funktion per Hook und korrigiert nach dem ursprünglichen Aufruf die Textur- und Surface-Größen passend zur aktuellen Backbuffer-Auflösung.
    • Der Pitch von Tiled Memory kann sich von einem gewöhnlichen width * bpp unterscheiden und wird daher mit D3D_CalcTilePitch berechnet.
    • Ein falscher Pitch kann besonders bei 1080i den Streifeneffekt verursachen.

Anpassung der texaccum-Render-Target-Größe

  • Die abgeschnittene Wassergeometrie im Hauptmenü entstand, weil das texaccum-Render-Target fest auf 640×480 eingestellt war.
  • Die Xbox-DirectX-Implementierung erlaubt pro Pixel-Shader-Pass nur vier Texture-Samples.
    • Objekte, die mehr als vier Eingabetexturen benötigen, müssen über mehrere Pässe gerendert werden.
    • Die texaccum-Schicht kombiniert zunächst Detailtexturen und dient dann als Eingabe für den Lightmap-Pass.
  • rasterizer_targets_initialize allokierte das texaccum-Render-Target mit 640×480.
  • Durch einen Hook um _rasterizer_alloc_and_create_render_target werden Breite und Höhe des texaccum-Targets bei target_index == 1 auf die aktuelle Backbuffer-Größe geändert.
  • Nach dieser Änderung verschwand das Abschneiden der Wassergeometrie, und auch beim Laden von Maps traten keine auffälligen Rendering-Probleme mehr auf.
  • Das Problem mit dem blauen Filter wurde durch eine einfache Aktualisierung der Größenprüfung gelöst; die Details werden ausgelassen.

Speichergrenzen als Hindernis für 720p

  • Bei 720p stürzte das Spiel beim Start ab; Ursache war Speichermangel durch größere Front-, Back- und Depth-Buffer sowie Rasterizer-Targets.
  • Für die originale Xbox gab es 64-MB-Retail-Modelle und 128-MB-Entwicklergeräte bzw. Debug-Konsolen.
    • Auch auf Retail-Boards sind die Lötplätze für zusätzliche RAM-Chips vorhanden.
    • Mit eingelöteten RAM-Chips und einem modifizierten Kernel lässt sich auf die zusätzlichen 64 MB zugreifen.
  • Für 720p und höher war ein 128-MB-RAM-Upgrade erforderlich.
  • Um selbst normales 480p ohne RAM-Upgrade weiter nutzen zu können, musste Speicher aus dem In-Memory-Textur-Cache entnommen werden, was zu stärkerem Textur-Pop-in führte.

Patch für den Halo-2-Speichermanager

  • Halo 2 reserviert beim Start von den verfügbaren 64 MB etwa 48,9 MB als einen großen Runtime-Datenbereich.
    • Dieser Bereich wird unter anderem für Level-Metadaten, Texturen, Geometrie, Animationen, Sound-Caches, Rasterizer-Targets sowie Netzwerk- und Simulationsressourcen genutzt.
  • Zur Visualisierung der Speichernutzung wurde XboxImageGrabber entwickelt.
    • Es visualisiert den RAM-Nutzungszustand als Bitmap, indem es die Seitentabelleneinträge durchläuft.
  • Der Runtime-Datenbereich wird an der hartkodierten Adresse 0x80061000 angelegt.
    • Die Tag-Daten der Map-Dateien sind relativ zu dieser Basisadresse serialisiert, daher müssen diese Daten immer an derselben Adresse liegen.
    • Andere Runtime-Daten lassen sich verschieben.
  • Als verschiebbare Bereiche wurden Rasterizer-Targets, Texture-Cache und Geometry-Cache gewählt.
    • Bestimmte Allokationsaufrufe werden per Hook in die Debug-Memory-Region umgeleitet.
    • Beim Freigeben, etwa beim Laden eines neuen Levels, wurden passende free-Aufrufe ergänzt.
    • Auch die Größe des Runtime-Datenbereichs wurde reduziert, um Verschwendung zu vermeiden.
  • physical_memory_malloc wurde vom Compiler inline gesetzt, daher musste jeder einzelne Call Site separat gepatcht werden.

Xbox-Kernel-Hotpatch und physischer Speicher in den oberen 64 MB

  • Speicheradressen, die an die GPU übergeben werden, müssen physische Adressen sein, und der entsprechende Speicherbereich muss zusammenhängend sein.
    • Die GPU besitzt weder Seitentabellen noch eine Adressübersetzung für virtuelle Adressen.
  • Selbst bei einem 128-MB-Kernel war zusammenhängende physische Allokation standardmäßig nur in den ersten 64 MB möglich, während virtuelle Allokationen die gesamten 128 MB nutzen konnten.
  • Tests, bei denen Seitentabelleneinträge der oberen 64 MB manuell wie GPU-Speicher verwendet wurden, funktionierten erfolgreich.
    • Die Beschränkung, GPU-tauglichen physischen Speicher nicht in den oberen 64 MB nutzen zu können, war also keine Hardware-, sondern eine Software-Grenze des Kernels.
  • Innerhalb von MmAllocateContiguousMemoryEx gab es eine Prüfung gegen MAX_USABLE_PFN.
    • Der bisherige Wert war 0x83FE0000, entsprechend 64 MB minus 128 KB.
    • Die oberen 128 KB waren als 64 KB GPU-Scratch-Bereich und 64 KB CPU-Page-Table reserviert.
  • Der Patch prüft beim Spielstart, ob die Konsole 128 MB RAM besitzt, sucht dann in MmAllocateContiguousMemoryEx nach mov edx, 0x3FDF und ersetzt den Wert passend für die 128-MB-Konfiguration.
  • Danach werden mit MmAllocateContiguousMemoryEx und MmFreeContiguousMemory zusammenhängende physische Speicherbereiche über die vollen 128 MB hinweg allokiert und freigegeben.
  • Es gab auch Nebenwirkungen:
    • Wenn nach dem Beenden des Spiels ohne Cold Reboot zum Dashboard zurückgekehrt oder das DVD-Laufwerk per Warm Reboot ausgeworfen wurde, konnten in der nächsten App oder im nächsten Spiel schwere Grafikartefakte und Abstürze auftreten.
    • Um das zu kaschieren, wurde ein zusätzlicher Patch eingebaut, der beim Beenden des Spiels einen Cold Reboot erzwingt.

720p/1080p-Rendering und Performance-Flaschenhälse

  • 720p-Rendering sah optisch besser aus, aber in schweren Szenen fiel die Performance teils auf unter 10 FPS.
  • 1080p lässt sich nativ rendern, doch die Konsolenausgabe der Xbox unterstützt nur ein 1080i-Signal.
    • Beim direkten Dump des D3D-Backbuffers konnten 1080p-Screenshots abgegriffen werden, bevor die GPU das Bild für den Video-Encoder in ein Half-Frame umwandelt.
  • Für die Leistungsmessung wurden drei Konfigurationen verglichen: Standard-Xbox, nur CPU-overclockte god box und god box mit CPU- und GPU-Overclocking.
  • Als schwere Testszene diente ein Abschnitt aus Zanzibar, die „zanzibar benchmark scene“.
  • In den ersten Messungen lagen die FPS aller drei Konfigurationen fast gleich; im Performance-Graph zeigte sich swap stall als Ursache.
    • Halo 2 nutzt aktiviertes VSync und Double Buffering.
    • Dabei kann es zu Stalls kommen, wenn die GPU auf VBlank wartet und die Swap Chain nicht rotieren kann.

Triple Buffering und Bestätigung des GPU-Bottlenecks

  • Als Lösung wurde der Backbuffer-Count auf 2 erhöht, sodass mit einem Frontbuffer und zwei Backbuffern insgesamt Triple Buffering genutzt wird.
  • In D3DPRESENT_PARAMETERS wurden BackBufferCount = 2, D3DSWAPEFFECT_DISCARD und D3DPRESENT_INTERVAL_ONE gesetzt.
  • Da die Rendering-Engine von Halo 2 für Double Buffering ausgelegt war und pro Frame die Back-/Frontbuffer-Pointer tauschte, mussten auch der Swap-Hook und der Primary-Target-Initialize-Hook angepasst werden.
    • Zwei primäre Render-Surfaces und Textur-Views wurden so geändert, dass sie immer auf den aktuellen Backbuffer zeigen.
    • Selbst wenn das Spiel intern zwei Pointer tauscht, zeigen diese auf denselben Speicher und der Tausch wird faktisch zu einem No-op.
  • In der Zanzibar-Benchmarkszene stieg die FPS mit Standard-GPU damit auf etwa 22 FPS.
    • Das sind ungefähr 3 FPS mehr als zuvor.
    • Bezogen auf das 30-FPS-Cap entspricht das rund 10 % Zuwachs.
    • Der Swap Stall verschwand, die GPU-Auslastung stieg auf ihr Maximum, und damit war bestätigt, dass die GPU der Bottleneck ist.

Overclocking von GPU und RAM

  • Durch die Umstellung des texaccum-Render-Targets auf Tiled Memory kamen zusätzlich 1 bis 2 FPS hinzu.
    • Die Zanzibar-Benchmarkszene verbesserte sich von rund 19 FPS auf 23–24 FPS.
  • Mit GPU-Overclocking der god box erreichte die Zanzibar-Benchmarkszene 27–28 FPS.
    • Beim Herumlaufen auf der Map wurden meist 30 FPS gehalten; nur in einigen schweren Bereichen sank die Rate.
  • Um das erneute Flashen des BIOS zu vermeiden, wurde beim Spielstart direkt das memory-mapped IO-Register des GPU-Clock-Generators angepasst.
  • Die GPU-Taktberechnung basiert auf den M-, N- und P-Werten von NVPLL_COEFF sowie einem Basistakt von 16,6667 MHz.
    • Der Standard-N-Wert 28 ergibt einen GPU-Takt von 233,33 MHz.
    • Durch Anpassung des N-Werts ließ sich der Takt in Schritten von rund 8 MHz konfigurieren; die Einstellung wurde per ini-Datei verfügbar gemacht.
  • Ein GPU-Overclocking auf 300 MHz brachte im Zanzibar-Benchmark gegenüber der Standard-GPU noch einmal etwa 3 FPS mehr.
  • Die Overclocking-Grenzen unterschieden sich je nach GPU.
    • GPUs in Konsolen der Revisionen 1.0 bis 1.4 erreichten oft bereits im unteren 300-MHz-Bereich ihre Grenze.
    • GPUs in Revision-1.6-Konsolen liefen in manchen Fällen stabil mit über 400 MHz.
  • Auch der RAM-Takt wurde getestet.
    • Die theoretische maximale Bandbreite des Xbox-Speicherbusses liegt bei 6,4 GB/s; praktisch nutzbar sind etwa 70 %, also rund 4,5 GB/s.
    • Der RAM läuft standardmäßig nahe 200 MHz, und schon etwa 10 MHz mehr können Instabilität verursachen.
    • In einem Test mit rund 208 MHz wurde ein Zugewinn von 0,7 FPS beobachtet.
    • Zwar wurden RAM-Chips bestellt, die 250 MHz schaffen könnten, zum Zeitpunkt des Artikels waren sie aber noch nicht eingebaut und getestet.

Weniger Pop-in und größere Caches

  • Halo 2 hatte schon ursprünglich Probleme mit Textur- und Geometrie-Pop-in, was auf Konsolen mit mechanischen HDDs aus den frühen 2000ern noch deutlicher auffiel.
  • Mithilfe des zusätzlichen RAM wurden Texture-Cache und Geometry-Cache vergrößert.
    • Der standardmäßige Geometry-Cache beträgt bei Singleplayer-Maps 6,5 MB und bei Multiplayer-Maps 7 MB.
    • Der Texture-Cache variiert je nach Größe der Map und nutzt den freien Bereich hinter den Tag-Daten und vor dem Low-Detail-Texture-Cache.
  • Die Caches arbeiten nach dem LRU-Prinzip.
    • Alle 30 Frames werden Daten entfernt, die in den letzten 30 Frames nicht verwendet wurden.
    • Wenn der Cache voll ist, muss der Aufrufer entweder eine erzwungene Eviction anfordern, oder der Ladevorgang schlägt fehl und wird im nächsten Frame erneut versucht.
  • Texturen können Low-, Medium- und High-LOD-Buffer besitzen.
    • Wenn das Laden von High LOD fehlschlägt, wird Medium oder Low LOD versucht.
    • Dadurch kann zunächst ein niedrigeres LOD sichtbar sein und später durch ein höheres ersetzt werden, was Pop-in verursacht.
  • Maps enthalten außerdem einen Emergency-Low-Detail-Texture-Cache mit Größen von 2×2 bis maximal 8×8.
    • Er dient dazu, Modelle vorübergehend trotzdem zu rendern, wenn reguläres Texturladen fehlschlägt.
    • Das Phänomen, dass nach dem Öffnen und Schließen des Xbox-Live-Freundemenüs Gelände mit extrem niedrig aufgelösten Texturen erschien, hängt mit der Nutzung dieses Caches zusammen.
  • Durch Rekonstruktion der Graph-Visualisierung aus dem Bungie-Debug-Build konnten die Cache-Auslastung direkt beobachtet und die Größen entsprechend abgestimmt werden.
  • Die finale Konfiguration erhöhte den Geometry-Cache auf 20 MB und setzte den Texture-Cache fest auf 30 MB.
    • Beide Caches sind damit nahezu doppelt so groß wie in der Standardkonfiguration.
    • In der Eröffnungs-Cutscene von Outskirts erscheint Master Chief sofort mit hochauflösenden Texturen, und es bleibt noch Cache-Spielraum übrig.
  • Um verbleibendes Pop-in weiter zu reduzieren, wurde auch die HDD-Übertragungsrate erhöht.
    • Standard-UDMA 2 entspricht etwa 33,3 MB/s.
    • UDMA 3 entspricht etwa 44,4 MB/s.
    • Mit einem 80-poligen IDE-Kabel ist sogar UDMA 5 mit etwa 100 MB/s möglich.
    • Mit dem Standard-IDE-Kabel ergibt sich etwa 10 % mehr Durchsatz, mit einem aufgerüsteten IDE-Kabel theoretisch bis zu 300 %.
  • Das finale 720p-Speicherprofil nutzt mehr als 75 % der 128 MB RAM.
    • Im 1080p-Modus belegen Swap Chain und Rasterizer-Targets so viel Speicher, dass die Cache-Größen reduziert werden mussten; praktisch wird dabei fast der gesamte 128-MB-Speicher genutzt.

Ergebnis

  • Insgesamt wurde der 720p-Patch auf ein spielbares Niveau gebracht; 1080p-Unterstützung ist vor allem ein Bonus für Screenshots.
  • Bei Performance und Speicherverwaltung gibt es zwar noch Verbesserungspotenzial, doch das Projekt hat die Grenzen von Halo 2 und der Xbox-Konsole deutlich verschoben.
  • Der Download des Halo 2 HD-Patches und der Source Code sind auf GitHub verfügbar.

1 Kommentare

 
GN⁺ 2024-04-19
Meinungen auf Hacker News
  • Videolink am Ende des Artikels: https://www.youtube.com/watch?v=O_nk21389u8
    Das Video enthält einen direkten Vergleich zwischen dem hochskalierten Original in 480p und 720p; ab etwa Minute 7 wird erklärt, was nötig ist, um 720p zu erreichen und dabei Gameplay mit rund 30 fps beizubehalten.
    Der Artikel ist ebenfalls hervorragend, aber auch das Video ist gut, weil es zusammenfasst, welche Änderungen für die höhere Auflösung nötig sind.

  • Dass 720×480 keine 16:9-Auflösung sei oder kein „echtes 480p“, muss man eigentlich der ITU-Standardisierung der 1970er-Jahre anlasten: https://tech.ebu.ch/docs/techreview/trev_304-rec601_wood.pdf
    In einem Memo vom Februar 1980 hieß es, dass die Zahl der Samples pro aktiver Zeile größer als 715,5 sein müsse, um die aktiven Zeilendauern aller europäischen Standards abzudecken; später etablierten sich die 720 Samples, die in Rec. 601 und SMPTE 125 verwendet wurden, als erster Wert, der „funktionierte“.
    Rec. 601 lieferte 720 Samples pro aktiver Zeile für den Luminanzkanal und jeweils 360 Samples für die Farbdifferenzsignale; als HDTV definiert wurde, verdoppelte man die horizontale Auflösung dieses bestehenden TV-Systems und wandte ein Seitenverhältnis von 16:9 an, was zu 1920 Samples pro Zeile und 1080 Zeilen führte.
    Auch das Progressive-Scan-System 1280×720 gehört zu derselben 720-Pixel-Familie, und die meisten auf digitalem TV, DVD und MPEG basierenden Systeme leiten sich von diesem 4:2:2-Grundstandardformat ab.

    • Soweit ich weiß, unterstützt DVD nur anamorphes 4:3-Video mit nicht quadratischen Pixeln, damit beim Abspielen das richtige Seitenverhältnis entsteht.
  • Der „Hackergeist“ an sich ist völlig legitim, aber ich frage mich, ob es außer der PC-Version noch einen besonderen Grund gibt, sich die Mühe zu machen, einer Konsole zusätzlichen Speicher zu verpassen und die GPU zu übertakten, nur um Halo 2 so zu spielen.

    • Die PC-Portierung von Halo 2 war früher wie heute berüchtigt schlecht, sogar schlimmer als das, was Gearbox mit Halo 1 gemacht hat.
      Es gibt viele Videos, die die Mängel auf mehreren Ebenen ausführlich behandeln.
      https://youtu.be/03K2Uz3s1hg?si=zaFO1XdzMcFvI1F6
    • Wenn ein altes Gerät als ungeeignet für eine bestimmte Aufgabe gilt, fühlt es sich meist gut an, es genau diese Aufgabe doch erledigen zu lassen.
      Es fühlt sich an, als würde man beweisen, dass es durchaus möglich ist oder sogar besser geht.
      Vielleicht ist das fast schon eine psychologische Macke, aber meistens eine harmlose und spaßige; es wirkt wie die Kehrseite der Besessenheit, als Erster das neueste Modell eines beliebten Geräts kaufen zu wollen.
      Beides vermittelt eine Art Überlegenheitsgefühl.
    • Das ist einfach Hackergeist.
      Halo 2 lässt sich auch heute noch über Online-Lobbys oder in der Kampagne spielen, und man kann zwischen der Originalgrafik von 343 und der remasterten HD-Grafik wählen.
    • Es sind immer noch 30 fps, daher fällt es für mich persönlich automatisch raus.
  • Im Text hieß es: „Das Tag-Datensystem wurde so flexibel und schnell wie möglich entworfen, und seine interne Funktionsweise ist ingenieurtechnisch beeindruckend. Allein darüber, warum ich glaube, dass es die Blam Engine zu einer der flexibelsten Engines macht, könnte ich einen eigenen Artikel schreiben, aber das gehört nicht hierher.“ Wenn dieser Artikel tatsächlich geschrieben wird, würde ich ihn unbedingt lesen wollen.

    • Falls jemand so etwas selbst geschrieben hat oder jemanden kennt, der es getan hat, wäre es schön, wenn er es teilt.
    • Als Kind habe ich Halo-2-Modding gemacht, kannte mich aber kaum mit Programmierung aus, und die Konzepte, die ich dort gesehen habe, haben mich wirklich umgehauen.
      Ich war so sehr Anfänger, dass ich kaum nachvollziehen konnte, wie das funktionierte, und es war so dynamisch, dass ich grundsätzlich nicht verstand, wie eine solche Struktur überhaupt möglich sein konnte.
      Ich verstand nicht, wie eine Spielerposition im selben Kontext stehen konnte wie eine Waffe mit Einstellungen, und wie sogar Effekte in derselben Liste auftauchen konnten.
      Viele Dinge, die mich heute interessieren, kreisen letztlich immer noch um genau solche Konzepte.
  • Ich wünschte, die Ära des Xbox- und Halo-2-Moddings würde heute wieder zurückkommen.
    Diese Zeit hatte großen Einfluss auf meine Berufswahl, und ich glaube immer noch, dass Halo 2 das innovativste Online-Spiel aller Zeiten ist.
    Damals konnte man mit einem einfachen Tool zum Laden von Spielständen, das man nur kaufen musste, innerhalb weniger Minuten eine softgemoddete Xbox bauen; heutige Konsolen dagegen brennen e-fuses durch, verhindern Downgrades und haben deutlich mehr Sicherheitsmaßnahmen.
    Zusammen mit Insignias Projekt, Halo-2-Support zu starten, ist das wirklich eine gute Zeit für das klassische Halo 2.

    • Ob gut oder schlecht: Die Entwickler der letzten zehn Jahre scheinen in vielerlei Hinsicht die Leiter weggetreten zu haben, über die sie selbst nach oben gekommen sind.
      Einer der Gründe, warum ich heute Software Engineer bin, ist, dass man leicht nachsehen konnte, wie Webseiten funktionieren, im Speicher von Programmen herumstochern und Hardware öffnen konnte, um hineinzuschauen.
      Als ich zu Halo-PC-Zeiten Levels gemoddet habe, habe ich viel darüber gelernt, was in einem Spiel steckt; zu wissen, was „BSP“ ist, mag nutzloses Trivia sein, gab mir aber das Vertrauen, noch mehr verstehen zu können.
      Auch heute kann man noch in Technik einsteigen und lernen, aber der Weg über echtes Herumbasteln ist schwer zu erkennen.
      Software ist deutlich schwerer zu cracken oder zu debuggen geworden; unmöglich ist es nicht, aber die Einstiegshürde ist viel höher.
      Webseiten kann man sich zwar weiterhin ansehen, doch viele heutige Sites sind zu Haufen von divs geworden, die ein minimiertes und obfuskiertes JavaScript-Monster tragen; bei Spielen ist es oft gleich ganz schwierig, weil sie zunehmend darauf angewiesen sind, Inhalte vom Server zu streamen.
      Auch bei Hardware muss man Sicherheitsprozeduren, die Geräte bricken können, Heißluftpistolen zum Öffnen verklebter Bezels und das Risiko dauerhafter Schäden in Kauf nehmen.
      Für jede dieser Veränderungen gab es wohl Gründe, aber dabei ist auch der meiste Spaß verschwunden, und selbst wenn die heutigen Werkzeuge technisch besser sind, fühlt sich Game-Modding nicht mehr an wie früher.
    • Die Xbox von damals war weniger Custom-Hardware als vielmehr ein PC aus Standardkomponenten, deshalb war ein Softmod nur mit einem Spielstand-Tool so einfach.
      Auch heute kann man mit PCs oder PC-basierten Konsolen wie dem Steam Deck noch reichlich herumbasteln; ich weiß nicht, warum man unbedingt gegen proprietäre Konsolen kämpfen sollte, die darauf ausgelegt sind, verschlossen zu sein.
      Unklar ist auch, was man außer dem Zugang zu billig am Markt erhältlicher Custom-x86-Hardware gewinnt.
    • Die Aussage „Halo 2 ist das innovativste Online-Spiel aller Zeiten“ wirkt im Kontext von Online-Spielen fast wie eine der wenigen nahezu einhelligen und wenig umstrittenen absoluten Thesen.
    • Ich frage mich, in welcher Hinsicht Halo 2 genau das innovativste Online-Spiel aller Zeiten gewesen sein soll.
      Kompetitive Online-FPS mit starken Modding-Communities waren auf dem PC bereits seit über zehn Jahren sehr aktiv.
    • Ich spiele Halo 2 auch auf dem PC noch häufig, inklusive Multiplayer.
      Dank Project Cartographer gibt es eine aktive Community: https://halo2.online/home/
    1. den RAM neu verlötet und den VRAM von 64 MB auf 128 MB aufgerüstet, 2) eine neue CPU in die Konsole gelötet und dann einen GPU-Flaschenhals entdeckt, 3) auf der originalen Xbox GPU-Overclocking aktiviert, aber an Grenzen der Speicherbandbreite gestoßen, 4) den Halo-2-Quellcode reverse-engineert und die Skalierung auf 720p oder 1080p gesetzt (Ausgabe ist interlaced 1080i), 5) sogar die Festplatte beschleunigt, damit Texturen schneller laden.
      Diese Person scheint Halo 2 heute mehr Hingabe entgegenzubringen, als Bungie in seine eigene IP steckt.
    • Bungie hat nichts mehr mit Halo zu tun.
      Die IP gehört Microsoft, und die Entwicklung liegt bei 343 Industries.
      Bungie hat jetzt Destiny/Destiny 2 und den kommenden Extraction-Shooter Marathon.
    • Nostalgie hat enorme Kraft.
      Ich habe wirklich sehr viel Zeit in dieses Spiel gesteckt, und es ist schön, dass es noch jemanden gibt, der wie ich seinem Zauber verfallen ist.
    • Das ist zwar eine enorme Engineering-Leistung, aber wenn man weiß, dass man für 500 Dollar eine Xbox Series X kaufen und die Remaster-Version in 4K mit 120 fps spielen kann, wäre es wohl schwer, das selbst zu machen.
      Trotzdem ist diese Hingabe bewundernswert.
  • Das mag übermäßig zynisch klingen, aber das Projekt selbst ist wirklich großartig.
    Ich frage mich nur, ob man wirklich sagen kann, man treibe die Grenzen der originalen Xbox aus, wenn CPU getauscht und übertaktet, RAM erweitert, Solid-State-Speicher hinzugefügt und sogar die GPU übertaktet wurde.
    An diesem Punkt wirkt es im Grunde nicht mehr wie eine Xbox.

    • Ob das noch eine Xbox ist, lässt sich diskutieren, aber im Kontext dieses Themas und des Artikels ist das größtenteils eher ein Streit um Semantik.
      Wenn man bei einem Honda Civic Motor und Fahrwerk stark modifiziert und sagt, man treibe ihn an seine Grenzen, kann die Frage „Ist das dann wirklich noch ein Civic?“ technisch berechtigt sein, klingt aber leicht nach Haarspalterei.
      Der Autor hat das Recht, den gewünschten Titel zu wählen; man kann ihn im Kopf einfach als „die OG Xbox bis kurz vor den Tod modden“ lesen.
    • Im Xbox-Modding-Kontext ist „original Xbox“ hier als nicht die Xbox 360 zu verstehen.
      Halo 2 kann auf der 360 mit höherer Auflösung laufen, daher ist es nützlich klarzustellen, dass es ein Modding-Projekt für die ursprüngliche Xbox ist.
      Es geht nicht wörtlich um eine unmodifizierte Xbox, sondern darum, dass das Modding-Ziel die ursprüngliche Xbox war.
    • Dass dasselbe Mainboard verwendet wird, halte ich trotzdem für bedeutsam.
    • Wenn man sich das GitHub-Repository ansieht, steht dort, dass man diesen Patch auch ohne Konsole mit CPU-Upgrade nutzen kann und dass in Tests kein zusätzlicher Performance-Gewinn gemessen wurde.
      Bei einer Konsole mit dem Standard-IDE-Kabel steigt die Übertragungsrate um 10 %, mit einem aufgerüsteten IDE-Kabel theoretisch um bis zu 300 %.
      Mit 128 MB RAM kann der zusätzliche RAM genutzt werden, um 720p- und 1080i-Videomodi zu aktivieren und den Speicher-Cache für Texturen und Geometrie zu vergrößern, wodurch Pop-in fast verschwindet.
      Wenn man nur 480p möchte, reichen bei einer Serienkonsole GPU-Overclocking und ein anderes IDE-Kabel.
      Die Formulierung zu SSDs hat offenbar unbeabsichtigt für Missverständnisse gesorgt; gemeint war vielleicht die Kombination aus 80-adrigem Kabel und SSD.
      Eine übertaktete CPU ist nicht nötig, die CPU ist auch kein Flaschenhals, und der zusätzliche RAM wird nur gebraucht, wenn man mehr als 720p will.
      Dieses Feedback wurde weitergegeben, daher könnte der Blogbeitrag diesen Punkt noch klarer aktualisieren.
    • Aus bestehender Hardware das Maximum herauszuholen, ist an sich schon ein eigenes Ziel.
      So ist es in der Retro-Computer-Szene, und beim Autotuning ist es ähnlich.
      Manche wollen eine perfekte Corvette im Werkszustand, andere ein Model A mit einem 50 Jahre neueren Motor.
      Etwas Vertrautes und Bekanntes nach dem eigenen Willen zu verbiegen, ist einfach cool.
  • Der Arbeitsaufwand ist enorm
    Interessant ist auch, dass der Freund „doom“ seine Identität nicht preisgeben wollte

    • Wir sollten Spekulationen zwar nicht ernst nehmen oder überhaupt spekulieren, aber wenn man in einer Branche arbeitet, in der man lieber zweimal nachdenkt, bevor man seine reale Identität mit Xbox-Reverse-Engineering in Verbindung bringt, ist das durchaus nachvollziehbar
    • Musste an Doom9 denken
    • Ist fast sicher grimdoomer