Adaptive Tile Refresh von Commander Keen

 (fabiensanglard.net)
2 Punkte von GN⁺ 2023-07-29 | 1 Kommentare | Auf WhatsApp teilen
  • Adaptive Tile Refresh (ATR) ist eine Scrolling-Technik, mit der Commander Keen 1–3 die langsame Vollbild-Aktualisierung von EGA umgeht, indem nicht der ganze Bildschirm, sondern nur geänderte Kacheln neu gezeichnet werden
  • Der EGA-Modus Dh speichert einen Bildschirm mit 320x200 und 16 Farben auf vier Ebenen (C0~C3); wenn pro Frame die gesamten 32 KiB über den ISA-Bus geschrieben werden, sind nur etwa 5 fps möglich, was 60-Hz-Aktualisierung erschwert
  • ATR verarbeitet vertikale und horizontale Bewegung innerhalb eines virtuellen Bildschirms über die Register CRTC_START, OFFSET und PEL; wird der Rand erreicht, setzt ein jolt den Bildschirmbezug zurück und überschreibt nur die nötigen Kacheln im VRAM
  • Die Kosten eines jolt hängen von der Anzahl der neu zu zeichnenden Kacheln ab; im Beispiel von Commander Keen 1 änderten sich von 250 Kacheln nur 40 Kacheln, sodass nur 16 % des gesamten Bildschirms neu gezeichnet wurden, und ein Map-Design mit vielen wiederholten Kacheln bestimmte die Performance
  • Commander Keen 4–6 wechselte von ATR zu einer Methode, die den Wraparound der 64-KiB-VRAM-Apertur nutzt, um kontinuierlich zu pannen und dabei nur die neu sichtbar werdenden Randstreifen zu zeichnen; auf einigen Super-VGA-Karten führte das zu Kompatibilitätsproblemen, weil in nicht initialisierten Speicher geraten werden konnte

Die Bandbreitenbegrenzung auf EGA

  • Commander Keen lief am besten auf PCs mit EGA (Enhanced Graphic Adapter); die Grafikprogrammierung erfolgte über Konfigurationsregister und ein auf VRAM gemapptes 64-KiB-Speicherfenster
  • EGA speichert interne Daten auf vier Ebenen C0, C1, C2, C3
    • C0 speichert das niederwertigste Bit (LSB) jedes 4-Bit-Pixelwerts
    • C3 speichert das höchstwertige Bit (MSB)
    • Jede Ebene besteht aus 200 Zeilen mit jeweils 40 Byte pro Zeile
  • Die Struktur mit vier Bänken war darauf ausgelegt, genügend Bandbreite für die CRT-Ausgabe bereitzustellen, und die CRTC liest 4 Byte parallel
  • Der von Commander Keen verwendete EGA-Modus Dh bietet 320x200 Auflösung und 16 Farben
    • Anders als bei Modus 10h, der Tinten aus 64 Farbwerten rekonfiguriert, wird das hier nicht verwendet
    • Auch in Modus Dh lassen sich Palettenfarben innerhalb der grundlegenden 16 Farben ändern, was in Commander Keen für einfache Fade-in/Fade-out-Effekte genutzt wird

Wie Adaptive Tile Refresh das Redraw des ganzen Bildschirms vermeidet

  • Der zentrale Flaschenhals, den ATR löst, ist die Bandbreite
  • Das Schreiben von 4-Bit-Werten für 320x200 Pixel, also rund 32 KiB, in jedem Frame belastet den ISA-Bus zu stark
  • Eine einfache Schleife, die den ganzen Bildschirm jedes Mal aktualisiert, bleibt bei ungefähr 5 Bildern pro Sekunde
  • EGA bietet auch Möglichkeiten, gleichzeitig in vier Bänke zu schreiben, was beim Löschen des Bildschirms oder bei der Spaltenreplikation in Wolfenstein 3D hilft, aber nicht zum Scrolling-Problem von Commander Keen passt

Weiches Scrollen per Register

  • ATR legt zunächst einen virtuellen Bildschirm an, der größer ist als die Anzeige, und verschiebt den sichtbaren Bereich, indem der CRTC_START-Wert geändert wird, der festlegt, ab wo die CRTC liest
  • Vertikales Scrollen ist relativ einfach
    • Fügt man ober- und unterhalb des sichtbaren Bildschirms jeweils 16 Zeilen hinzu, werden pro Ebene 40 x 232 = 9.280 Byte verwendet
    • Bewegt sich der Bildschirm um eine Zeile nach oben, wird CRTC_START um 40 Byte erhöht
    • Bewegt sich der Bildschirm um eine Zeile nach unten, wird CRTC_START um 40 Byte verringert
  • Horizontales Scrollen verwendet gemeinsam die Register OFFSET und PEL
    • Wird OFFSET auf 2 gesetzt, entsteht zwischen den Zeilen ein Padding von 16 Byte, wodurch links und rechts im virtuellen Bildschirm jeweils 16 Pixel Spielraum entstehen
    • Wird CRTC_START um 1 erhöht, bewegt sich der Bildschirm wegen der Ebenenstruktur nur in 8-Pixel-Schritten, was zu grob ist
    • Horizontal Pel Panning, also das Register PEL, kann nach CRTC_START bis zu 7 Bits überspringen und ermöglicht damit horizontales Scrollen auf Pixelebene
  • Die tatsächliche Bewegung nach links und rechts erfolgt, indem CRTC_START mit dem durch 8 geteilten Koordinatenwert angepasst und PEL mit dem Rest der Koordinate (% 8) gesetzt wird

jolt und partielle Aktualisierung auf Kachelbasis

  • Wenn der Rand des virtuellen Bildschirms erreicht wird, führt ATR einen jolt aus und richtet den virtuellen Bildschirm wieder auf die Mitte aus
  • Ein vollständiges Neuzeichnen des Bildschirms würde rund 200 ms dauern und auf 5 fps absinken, daher überschreibt jolt statt eines vollständigen Redraws nur die geänderten Kacheln
  • Die Levels von Commander Keen bestehen aus 16x16-Kacheln
    • Zeichnet ein Artist eine Kachel, weist das Build-System dieser Kachel eine eindeutige ID zu
    • Der Level-Designer platziert in einem 2D-Editor die Kachel-IDs und baut daraus die Map
    • Die Engine verfolgt, welche Kachel-IDs sich auf dem virtuellen Bildschirm befinden
  • Zum Zeitpunkt eines jolt werden die Kachel-IDs des aktuellen Zustands des virtuellen Bildschirms mit dem Zielzustand nach dem erneuten Zentrieren verglichen
    • Gleiche Kacheln werden übersprungen
    • Nur unterschiedliche Kacheln werden in den VRAM geschrieben
  • Die Effizienz eines jolt ist umgekehrt proportional zur Zahl der neu zu zeichnenden Kacheln, daher mussten die Game-Designer Tilemaps mit vielen wiederholten Kacheln bauen
  • Im Beispiel von Commander Keen 1 änderten sich bei einer weichen Bewegung nach rechts, nach der am Ende des virtuellen Bildschirms ein 16-Pixel-jolt nach links ausgelöst wurde, von 250 Kacheln nur 40 Kacheln
    • Der neu gezeichnete Anteil betrug 16 % des gesamten Bildschirms
  • Über dem Hintergrund wird eine Sprite-Ebene gezeichnet
    • Die Engine verwaltet eine Liste schmutziger Kachelkoordinaten, die von Sprites überschrieben wurden
    • In jedem neuen Frame wird diese Dirty-Liste durchlaufen, um zunächst die Hintergrundkacheln wiederherzustellen und danach die Sprites erneut zu zeichnen

Double Buffer und das Drifting der zweiten Trilogie

  • Um visuelle Artefakte zu vermeiden, wird das gesamte System mit zwei Framebuffern dupliziert
    • Während die CRTC aus dem einen liest, kann in den anderen an einer anderen Position im VRAM geschrieben werden
    • Jeder Buffer belegt (320 + 32) * (200 + 32) * 4 / 8 = 40.832 Byte
    • Der vollständige Double Buffer belegt 40.832 * 2 = 81.664 Byte und überschreitet damit die 64 KiB der ursprünglichen IBM-EGA-Karte
  • Laut VileR war nur das ursprüngliche IBM-EGA-Board mit 64 KiB ausgestattet; die meisten EGA-Klone, die etwa 1986–1987 erschienen, hatten 256K, und zum Release von Commander Keen waren EGA-Karten mit weniger als 256K fast nicht mehr vorhanden
  • In Commander Keen 1–3 fallen die von ATR benötigten Wiederholungsmuster auf dem Bildschirm deutlich auf, während dieses Merkmal in Commander Keen 4–6 weit weniger sichtbar ist
  • Die zweite Keen-Trilogie nutzt das Wraparound-Verhalten, bei dem CRTC_START nach Erreichen des Endes eines 64-KiB-Blocks wieder zum Anfang des Blocks springt
    • Der Bildschirm wird kontinuierlich weiter gepannt und nur die neu sichtbar werdenden Randkachelstreifen werden gezeichnet
    • Da jolt entfällt, musste man deutlich weniger ähnliche Wiederholungsflächen erzeugen
  • Diese Methode ist weniger ein neues Feature als vielmehr eine Verbesserung, die jolt beseitigt
    • Die zwei Elemente des Double Buffer driften mit derselben Geschwindigkeit durch den VRAM-Bereich und überlappen sich daher nicht
    • In den meisten Fällen funktioniert das gut
  • Auf einigen Super-VGA-Karten traten jedoch Probleme auf
    • Bei Karten mit nicht standardkonformer Implementierung und größerem Speicher sprang der Zugriff am Ende nicht per Wraparound zum Anfang zurück, sondern konnte in real existierenden, nicht initialisierten Speicher laufen
    • Statt für viele verschiedene Nicht-Standard-Karten jeweils eigene Workarounds zu bauen, wählte Carmack die einfache Lösung, am Bildschirmende einen hitch in Kauf zu nehmen und den ganzen Bildschirm nach oben zu kopieren
  • Diese Drifting-Technik könnte verhindert haben, dass Kacheln und Sprites im VRAM gespeichert und schnelle VRAM-zu-VRAM-Kopien genutzt werden, aber da pro Frame ohnehin nur sehr wenig gezeichnet werden musste, war das vermutlich kein großes Problem

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-07-29
Meinungen auf Hacker News

  • Die Scroll-Geschmeidigkeit von Commander Keen 4–6 blieb auf dem PC über viele Jahre von keinem Spiel erreicht, selbst nachdem Spiele auf 256-Farben-Grafik umgestiegen waren.
    Dank John Carmacks erstaunlicher technischer Arbeit und Adrian Carmacks 16-Farben-Palette-Art hatte id in den 1990er-Jahren eine Zeit lang wohl die am besten aussehenden Plattformspiele auf dem PC.
    Adrian Carmack ist nicht mit dem bekannteren Carmack verwandt, aber ich sehe ihn als einen verborgenen Meister der 16-Farben-Palette.

    • Es fühlt sich ziemlich seltsam an, dass alle klassischen Commander-Keen-Spiele zwischen Dezember 1990 und Dezember 1991 entwickelt und veröffentlicht wurden.
      Das Tempo der Fortschritte bei Grafik und Gameplay war wirklich enorm.
      Die Veränderung seit dem ersten Spiel: https://en.wikipedia.org/wiki/Commander_Keen_in_Invasion_of_...
      Die Veränderung bis zum letzten Spiel: https://en.wikipedia.org/wiki/Commander_Keen_in_Goodbye,_Gal...
      Ich habe sie damals als Kind selbst gespielt und hatte vergessen, dass das alles so schnell passiert ist.
    • Wenn es um das am besten aussehende PC-Plattformspiel für eine Zeit in den 1990ern geht, würde ich Prince Of Persia wählen.
      Ich will Commander Keen damit nicht schlechtreden, aber die Optik und die Spielmechanik von PoP wirkten für die damalige Zeit einzigartig.
      Als ich es mit etwa sieben zum ersten Mal spielte, wirkte es magisch auf mich, und es ist bis heute mein Lieblings-Plattformspiel, also bin ich da wohl voreingenommen.
      Natürlich hat PoP überhaupt kein Scrolling, und genau dieser Teil ist bei Commander Keen schwarze Magie.
    • Vielleicht ist das die rückblickende Perspektive, aber viel von dieser innovativen Entwicklung wirkt im Vergleich zu heutiger Entwicklung ziemlich einfach.
      „Der Speicher ist langsam, also zeichnen wir nur neu, was sich geändert hat“ ist heute eine fast selbstverständliche Idee.
      Trotzdem sind die Optimierungen in Teil 4–6 interessant. Spannend ist auch, dass man in Teil 1–3 die ganze Arbeit gemacht hat, weil man davon ausging, dass der Buffer nicht wrappt, obwohl er in Wirklichkeit wrappte und diese Arbeit damit nutzlos wurde.
    • Was ist mit Jazz Jackrabbit? Auch dieses Spiel hatte wirklich butterweiches VGA-Scrolling.

  • Ich habe einmal unter Windows 98 mit DirectX 5 ein tilebasiertes Spiel gebaut und anfangs einen Ansatz implementiert, der dem in diesem Artikel beschriebenen ähnelte.
    Da der Bildschirm nicht scrollte, war die Lage etwas einfacher, auch wenn potenziell viele Tiles neu gezeichnet werden mussten.
    Am Ende habe ich den ganzen Code wieder herausgerissen, weil ich auf einer RIVA-TnT-Karte die Kosten für das Zeichnen des gesamten Bildschirms profiliert habe und die benötigte Zeit so gering war, dass sie nicht einmal messbar war.
    Ich bin froh, dass ich in der PC-Entwicklung die EGA-Ära verpasst habe. In dieser Zeit hätte ich vermutlich nichts fertiggestellt.

    • Bei mir war es umgekehrt: Ich mochte diese Low-Level-Programmierung.
      Optimierung mit Bit-Shifts statt Multiplikation, Kerncode in Assembler schreiben und mit fortschreitender Prozessorentwicklung jeweils 16 oder 32 Bit auf einmal schreiben.
      Weil ich nur wenig Material hatte, lernte ich ständig aus Büchern der örtlichen Bibliothek und von Floppy-Disks mit txt-Dateien.
      Ich war zu jung und zu unerfahren, um etwas fertigzustellen, aber ich bekam weiches vertikales Scrolling hin, hatte horizontales Scrolling fast am Laufen und implementierte Double Buffering für einen rotierenden 3D-Würfel. Das umfasste sogar Depth Buffering, Mathematik und zeilenweises Zeichnen von Polygonen.
      Dann kam DirectX, der Kontakt zur Maschine verschwand, und ein rotierender 3D-Würfel wurde so einfach, dass es keinen Spaß mehr machte.
    • Schon damals wurde die Kluft zwischen den langsamsten und den schnellsten Grafikkarten sehr groß.
      Der Bus wurde von 8 Bit auf 16/32 Bit breiter, Grafikkarten unterstützten Posted Writes, sodass die CPU weniger warten musste, und auch die CPUs wurden schneller, sodass schnelle Systeme einen 640x480x256-Bildschirm mit über 300 Frames pro Sekunde schreiben konnten.
      In diesem Fall war es wohl ein gecachter System-Memory-Buffer plus DMA-Kopie, oder der Blitter hat das Zeichnen übernommen. Aber selbst zu Windows-98-Zeiten gab es unter den günstigen 3D-Karten welche, bei denen der CPU-Zugriff extrem langsam war und die kaum besser waren als alte ISA-Bus-Karten.
      Weil die Bildschirmauflösungen inzwischen so hoch geworden sind, hat sich das heute ein Stück weit wieder umgekehrt. Selbst wenn man einen 4K-Vollbildschirm mit 60 Frames pro Sekunde neu zeichnen kann, ist das schwerlich effizient.
      Spiele zeichnen normalerweise immer noch alles neu, aber Desktop-Compositoren optimieren ziemlich viel, etwa indem sie Layer dynamisch Hardware-Planes zuweisen, um die neu zu zeichnenden Bereiche zu reduzieren.

  • Ich arbeitete zur selben Zeit bei einer anderen Spielefirma und habe mir eine Scrolling-Technik wie den zweiten Ansatz selbst ausgedacht.
    Ich halte das nicht für besonders erstaunlich. Wenn man damals dasselbe Problem gelöst hat, wäre man vermutlich zu ähnlichen Schlüssen gekommen.
    Wir haben auch einen eigenen PWM-Audiotreiber gebaut, um Sample-Sounds über den PC-Speaker abzuspielen, aber das haben anscheinend alle anderen auch gemacht.
    Bevor wir alle zu Konsolen wechselten, bekam der PC nicht genug Liebe. Demos wie Hornets 8088 MPH begeistern mich noch heute.

    • Falls es ein veröffentlichtes Spiel war: Könntest du den Titel nennen, damit man vergleichen kann? Ich stimme zu, dass die meisten wohl auf ähnliche Lösungen gekommen wären, aber mich interessiert, ob sich das Spielergebnis gleich anfühlt.
    • Wenn das nicht so beeindruckend war, warum ruckelten dann selbst viele der damaligen Top-Scrolling-Plattformspiele so stark?
      Es ist keine Voraussetzung für ein unterhaltsames Spiel, aber die Geschmeidigkeit, die Keen besonders auf schwacher Hardware wie unter 10 MHz zeigte, war damals ein echter Augenöffner.
    • Ruhm entsteht oft nicht durch die Erfindung selbst, sondern durch die Fähigkeit zur Kommerzialisierung und zum Marketing.
      Es muss über Jahrtausende hinweg unzählige großartige Erfindungen gegeben haben, von denen niemand je erfahren hat.
      Auch ich habe zehn Jahre vor LinkedIn etwas Ähnliches „erfunden“, konnte es aber nicht erfolgreich kommerzialisieren. Die meisten Erfindungen werden wohl nie weithin bekannt.
      Deshalb starten viele Startups mit zwei Personen: einem Experten und einem Geschäftsmenschen.
      Insofern ist die Aussage nicht falsch. Diese Erfindung war vielleicht an sich nichts Besonderes, aber durch die Kombination aus Neuheit, Nützlichkeit und erfolgreicher Kommerzialisierung wurde sie besonders.

  • Im hervorragenden Buch Masters of Doom wird beschrieben, dass Keen ein Mario-artiges Spiel war, also ein Side-Scroller.
    id bot Nintendo diese Technik als Möglichkeit an, Mario auf den PC zu portieren, aber Nintendo lehnte ab, und so entstand Keen.
    Für PC-Spiele war das ein gewaltiger Sprung und läutete eine neue Ära von PC-Spielen ein.
    Was ich allerdings immer noch nicht ganz verstehe: Was war an NES- und PC-Technik so unterschiedlich, dass Nintendo horizontales Scrolling mehrere Jahre vor dem PC umsetzen konnte?

    • EGA stellt im Grunde einen großen Framebuffer bereit.
      In EGA-Grafikmodi kann man beliebige Dinge zeichnen, etwa Linien, Kreise oder einzelne Pixel; dafür war es gedacht.
      Scrolling gibt es aber nicht umsonst. Man muss Speicher direkt kopieren, und wie der verlinkte Artikel zeigt, kommt man mit brachialem Vorgehen wegen der Bandbreitenbegrenzung des ISA-Busses nur auf etwa 5 Frames pro Sekunde.
      Das NES und andere 8-/16-Bit-Konsolen waren nicht dafür gebaut, beliebige Dinge zu zeichnen. Sie waren dafür gebaut, Tiles zu rendern.
      Man definiert ein Raster aus Hintergrund-Tiles und gibt einen Scroll-Offset an. Sprites funktionieren ähnlich, können sich aber unabhängig bewegen. All das bekommt man kostenlos mit 60 Frames pro Sekunde.
      Der Nachteil ist, dass man beliebige Dinge nicht einfach rendern kann. Wenn man zum Beispiel irgendwo ein einzelnes Pixel setzen möchte, braucht man ziemlich heftige Umwege.
      Es war also nicht so sehr ein Problem, das Nintendo früher „gelöst“ hätte als IBM; vielmehr baute IBM ein allgemeines Grafiksystem für Universalcomputer und statische Grafik, das feingranulare Kontrolle über jedes Pixel bot. Wenn man sich eine EGA-Karte ansieht, ist das ein ziemlich großes Gerät mit viel Silizium.
      Nintendo dagegen baute ein deutlich einfacheres spezialisiertes Grafiksystem, das darauf ausgelegt war, Tiles zu verschieben.
    • Tatsächlich erstellten sie einen SMB3-Port und zeigten ihn Nintendo.
      Als Nintendo nicht darauf einging, erstellten sie neue Assets, aus denen später Keen wurde.
      Ein Video des Ports gibt es hier: https://youtu.be/1YWD6Y9FUuw
    • Ich bin mir nicht ganz sicher, aber soweit ich weiß, hatte das NES einen dedizierten Grafikchip zur Sprite-Manipulation, während man all das auf dem PC in Software erledigen musste.
    • Die Methode im Artikel imitiert mit einem unabhängigen Pixel-Framebuffer hardwareverwaltete Tiles in Software.
      Für die NES-Seite scheint https://www.nesdev.org/wiki/PPU ein guter Einstieg zu sein.
      Die zentrale Herausforderung besteht nicht darin, „herauszufinden, wie horizontales Scrolling funktioniert“, sondern eine Side-Scrolling-Game-Engine innerhalb der Speicher- und Bandbreitenbeschränkungen eines völlig anderen Systems so anzupassen, dass sie gut aussieht.
    • NES und GB waren, glaube ich, tilebasiert.
      Da Spiele spritebasiert mit Layern erstellt wurden, ergab diese Art, 2D zu „beschleunigen“, durchaus Sinn.

  • Im John-Carmack-Interview von Lex Fridman geht er sämtliche wichtigen Innovationen der einzelnen Spiele durch.
    Eine wirklich spannende Folge; wenn man Zeit hat, kann ich sie sehr empfehlen. Sie dauert ungefähr 5 Stunden.

  • Ich erinnere mich noch an die Zeit, als ich glaubte, fast alle Geheimnisse von Commander Keen Goodbye Galaxy zu kennen.
    Schulfreunde fragten mich nach der Schule oft, ob ich ihnen die Geheimnisse der Level verraten könne, die sie auf den Schulcomputern spielten.

    • Neidisch. An meiner Schule war ich, soweit ich mit Leuten darüber gesprochen habe, der einzige Nerd, der je von Commander Keen gehört hatte.

  • Wenn ich fabiensanglard.net sehe, empfehle ich es sofort.

    • Er ist wirklich ein Schatz. Auch das CPS1-Buch ist hervorragend.
      Falls jemand andere technisch tiefgehende Blogs über klassische Spiele kennt, würde ich mich freuen, wenn er sie teilt.
      https://nicole.express/ und https://sudden-desu.net/ gehören ebenfalls zu meinen Favoriten.

  • Ich habe verstanden, wie vertikales Scrolling funktioniert, wenn man den Startpunkt des Framebuffers scanlineweise anpasst, aber anfangs war mir nicht klar, wie horizontales Scrolling möglich ist, ohne den Framebuffer stark zu verbiegen.
    Nachdem ich etwas länger darüber nachgedacht hatte, wurde mir klar, dass es dem Bemalen der Seitenfläche eines Zylinders ähnelt. Egal, wo man den linken Bildrand zeichnet: Wenn man den Zylinder dreht und CRTC_START sowie das PEL-Register setzt, gibt es immer eine Möglichkeit, das ganze Bild sauber zu sehen.
    Interessant ist auch die Stelle, dass man „beim Erreichen des Bildschirmrands als einfache Lösung Ruckeln in Kauf nahm und den gesamten Bildschirm nach oben kopierte“.
    Ich erinnere mich, dass beim Start von Keen normalerweise eine Meldung wie „VGA compatibility mode enabled“ erschien, und ich habe mich immer gefragt, was das bedeutete.

  • Commander Keen war wirklich ein liebenswertes kleines Spiel.
    Ich sollte mal nachsehen, wie ich es wieder zum Laufen bekomme.
    Aber wie führt man das am besten aus? Seit ich „erwachsen“ bin, habe ich seit etwa 20 Jahren kein Windows mehr benutzt – wie kann ich es unter Debian spielen?

    • Direkt spielbar: https://archive.org/details/msdos_Commander_Keen_1_-_Maroone...
    • Da stimme ich nicht zu. Das war ein Spiel für Kinder, die aus irgendeinem Grund Zugang zu einem Computer hatten, aber keinen Nintendo.
      Damals waren Computer ungefähr zehnmal so teuer wie Konsolen, also lag es meist daran, dass Erwachsene starke Vorstellungen davon hatten, was ein Kind tun sollte.
      Im Vergleich zu NES- und Genesis-Spielen fehlt ihm die Seele. Damals mochte ich es, aber als ich es neulich in DosBox wieder ausprobiert habe, merkte ich deutlich, dass es nicht mithalten kann.
    • DosBox führt alte VGA-Spiele sehr gut aus und läuft auf fast jeder Plattform, auch im Browser: https://archive.org/details/msdos_Commander_Keen_1_-_Maroone...
    • Vermutlich DosBox.
    • Commander Keen und Jill of the Jungle waren damals die Spiele, durch die ich zum ersten Mal mit PCs in Berührung kam. Wirklich schöne Erinnerungen.

  • Vor ein paar Jahren habe ich die zweite Methode implementiert, aber selbst wenn nur die vordere Kante gezeichnet wurde, war es sehr langsam.
    Allerdings war es in C geschrieben, und ich habe Assembler-Programmierung nie richtig gelernt.
    https://github.com/geon/kate/blob/master/src/platform/dos/eg...