Ich habe gearde eine video über den Acorn 3020 gesehen und da wurde dieses Spiel gezeigt.
Da dachte ich mir nur: Hey, das ist ja mal Geil! 
Das hätte ich gerne auf dem C64. Mir ist klar, das da ALLES vom C64 abverlangt wird. Abstriche werden sicher unvermeinlich sein, wie z.B. der Schatten auf der Oberfläche. Der frisst sicher auch viel Rechenzeit. Den könnte man schon mal weglassen. Wie sieht ihr das ganze?
So schaut Zarch auf dem ZX Spectrum (48K) aus:
wurde dieses Spiel gezeigt.
welche der vielen gezeigten Spiele meinst Du denn ?
So schaut Zarch auf dem ZX Spectrum (48K) aus:
Steckt ja auch ein Z80 drin. 
Wie sieht ihr das ganze?
Neben dem Riesenaufwand, den die ganzen Berechnungen benötigen, gibt es hier ein typisches C64-Problem: Aufgrund des Kachelsystems der Bitmapgrafik kann man nicht frei auf dem Bildschirm Farben malen. Um "schnelle" 3d-Grafik zu erhalten, muß man darauf verzichten, mühselig zu bestimmen, welche Farbe in welcher 8x8 (bzw. 4x8)-Kachel gesetzt werden soll. Notgedrungen wird also die Farbanzahl beschränkt auf 2 Farben (HiRes) oder 4 Farben (Multicolour). Das macht es schwierig, Elemente voneinander zu unterscheiden. Das Original "Zarch" (bzw. "Virus") lebt auch davon, daß die einzelnen Landschaftsflächen jeweils verschieden eingefärbt sind. Das wäre so also nicht möglich. (Selbst mit SCPU würde man hier an die Grenze von max. 4 Farben pro Kachel kommen.)
Bei Virus gibt es zwei Arten von Objekten: 1.) rotierbare (Spieler und Gegner) 2.) Landschaftsobjekte (Bäume, Häuser etc). Außerdem verfügt das Spiel über eine ausgefeilte Partikelengine zur Darstellung des Schubfeuers, der Viren, Explosionspartikel etc.
Um die Objekte so zu malen, daß sie sich je nach Z-Tiefe übermalen, wird das Spielfeld in verschiedene Tiefenzonen eingeteilt, die gleichzeitig den Landschaftsflächen entsprechen. Vor dem Malen werden alle Objekte bewegt und mittels Array den Tiefenzonen anhand ihrer Z-Koordinate zugeordnet. Beim Malen selbst werden zunächst die Landschaftsflächen gezeichnet von links nach rechts und anschließend alle Objekte der Tiefenzone einschießlich der Partikel.
Der Malaufwand an sich ist auch ohne Schatten daher schon ziemlich hoch. Für die Vektorberechnung der rotierenden Objekte kann man zwar auf Sinus- und Cosinuswerte zurückgreifen (die Rotationsmatrix läßt sich relativ leicht berechnen), aber das Schwierigste dürften nicht die Multiplikationen, sondern die Divisionen sein, die bei allen Objekten heftig zu Buche schlagen. Leider gibt es gerade für die Division keine wirklich schnelle Alternative zum langsamen Bitshiften und Vergleichen. Man könnte Logarithmentabellen bemühen, doch ist deren Genauigkeit sehr eingeschränkt, so daß das Ergebnis ziemlich ungenau, sprich: wabbelig aussehen dürfte. So gesehen hat oobdoo durchaus recht, wenn er auf den Z80 verweist, da dieser den Divisionsalgorithmus schneller durchführen kann als der 6502. Und selbst mit Z80 ruckelt die Grafik auf dem Spectrum immer noch ziemlich.
Eine weitere Frage, die man klären müßte, wäre, wie die Karte intern repräsentiert werden soll. Im Originalcode verbrauchen allein die Karteninformationen 64 kb. Man müßte also zunächst einen Kartengenerator entwickeln, der on-the-fly für eine bestimmte Koordinate den Höhenwert ausspuckt.
Kurz gesagt: Ich glaube nicht, daß sich solch ein Spiel auf den C64 umsetzen läßt, jedenfalls nicht in einer spielbaren Form, eher sowas wie "Hard Driving".
Danke für das umfangreiche posting.
Originalgetreu umsetzbar bestimmt, aber mit extrem niedriger Framerate 
Was ich mir vorstellen kann, wäre eine abgespeckte Version:
Die Objekte als Sprites und die Landschaft nur mit Punkten umgesetzt. Das dürfte dann schnell genug sein. Die Sprites müssten vorberechnet sein, d.h. die möglichen Winkel wären sehr starr etc. ...
((( Eine andere (rein optisch, erträumte) Vorstellung, wäre eine Umsetzung im Multicolor-Bitmap-Mode mit einer Rasterung für die Flächen der Landschaft, d.h. bei 4 Farben hätte man da noch die Zwischenfarben, wenn man pixelweise oder zeilenweise die Farben wechselt. Vielleicht könnte man alle darstellbaren Variationen der einzelnen Flächen vorberechnen, indem man bspw. nur eine Steigung von max. einer Höhe zu einem benachbartem Feld o.ä. zulässt. )))
Zu der Umsetzung der Landschaft mit Pixeln habe ich mir einwenig mehr Gedanken gemacht:
In dem Video besteht der sichtbare Ausschnitt aus 12x10 Flächen, d.h. es müssten 13x11 Pixel ermittelt werden. Diese 13x11=143 Bildpunkte müssten also für unterschiedliche Höhen vorliegen.
Wenn man die möglichen Höhen begrenzen und vorberechnen würde, könnte man einfach die x und die y Position für den jeweiligen Punkt aus einer Tabelle auslesen.
Da 143 Punkte eine für 8-Bitter ungerade Zahl ist, könnte man max. 128 Punkte anstreben, so dass x und y Position in eine Page passen, d.h. für eine Fläche (oder Tiefe, je nachdem von welcher Richtung man das Spielfeld aufbauen möchte oder betrachtet) mit bspw. 16 Höhen, bräuchte man nur 4 kb, was sich sicherlich verschmerzen ließe.
((( Die Wurzel aus 128 ist ca. 11, d.h. 11x11x16x2 wäre eine solche Beispielrechnung. )))
Ein Bildpunkt im Level könnte als Byte gespeichert werden (evtl. sogar über ein Tileset), wobei dann 4-Bit für die Höhe und 4-Bit für die Farbe (oder evtl. ein Landschaftsmerkmal (bspw. Baum)) verwendet werden könnten.
(...)
Im Anhang ist ein kleines Experiment zu der Landschaftdarstellung über Pixel.
Der dargestellte Ausschnitt ist 16x8x16 Punkte groß. Die Ausgabe erfolgt im MC-Bitmap-Modus.
Die Map ist 256x64 Punkte groß.
Natürlich ist alles nicht optimiert und sieht schrecklich aus.
Der Bildaufbau ist momentan etwas langsamer als ein Frame, weshalb man das Löschen sieht.
Die Map selbst ist max. 11 Stufen hoch, d.h. hier könnte man etwas Dynamik reinbringen, vor allem weil die Map auch außerhalb des sichtbaren Bereichs, wie im Spiel, angezeigt werden könnte.
((( Ein einfacher nächster Schritt, wäre wenn man den Pixeln einfach unterschiedliche Farben, entpsrechend der Höhe gibt (bspw. Blau, grün und weiß oder grau) oder evtl. die Dichte vergrößern würde. Doublebuffering wäre dazu sicherlich notwendig. )))
testzarch.prg
Das hätte ich gerne auf dem C64. Mir ist klar, das da ALLES vom C64 abverlangt wird. Abstriche werden sicher unvermeinlich sein, wie z.B. der Schatten auf der Oberfläche. Der frisst sicher auch viel Rechenzeit. Den könnte man schon mal weglassen. Wie sieht ihr das ganze?
Es stellt sich immer die Frage, was man als Quintessenz eines Spiels ansieht, die man zwingend erhalten möchte. Ist es z.B. der 3D-Porn oder irgendwas am Spielprinzip? Ich kenne Zarch nur aus Videos und habe es nie gespielt. Ist der 3D-Effekt notwendig für das Spiel? Macht es einen Unterschied, ob die Spielfläche Höhenunterschiede aufweist? Ist die Framerate wichtig?
Ohne jetzt allzu viel über das Spiel zu wissen, außer dass man über eine gekachelte Fläche fliegt und irgendwas "abwirft" und ab und zu auf Gegner schießt – warum soll man das nicht auch auf einer schnell scrollenden 2D-Fläche (von oben gesehen) tun können? Ich würde bei Überlegungen so verfahren, wie ich das bei einer Atari 2600 Portierung tun würde – was ist das minimalste, was man braucht?
Ich würde mich also von so Games, wie Z oder Parallax inspirieren lassen (sofern die 3D-Darstellung nicht doch funktional wichtig ist):
Und dann gucken, wie man mit so einer Engine die Zarch-Optik mit farbigen Flächen (evtl. gerastert) und schattierten Objekten irgendwie rüberretten kann. Ich kann mir das auf jeden Fall besser vorstellen, als die Specci-Version, die zwar mit monochromem Wireframe 3D glänzt aber meines Erachtens eine unterirdische Bildwiederholrate hat. Und M. J. hat ja schon gesagt, dass die beim C64 mit seinem 1 MHz-6510 wahrscheinlich noch schlechter wäre.
Wenn man hingegen der Meinung ist, dass die bunte und schnelle 3D-Darstellung der zentrale Punkt bei Zarch ist, dann sollte man den Versuch aufgeben, eine ausreichend originalgetreue C64-Portierung hinzubekommen.
Natürlich ist alles nicht optimiert und sieht schrecklich aus.
Ich finde, das Programm schaut recht interessant aus. Darauf könnte man sicherlich aufbauen. 
Ist der 3D-Effekt notwendig für das Spiel?
Ja.
Macht es einen Unterschied, ob die Spielfläche Höhenunterschiede aufweist?
Oh ja.
Ist die Framerate wichtig?
Aber sowas von...
Wenn man hingegen der Meinung ist, dass die bunte und schnelle 3D-Darstellung der zentrale Punkt bei Zarch ist, dann sollte man den Versuch aufgeben, eine ausreichend originalgetreue C64-Portierung hinzubekommen.
Genau.
Wenn man die möglichen Höhen begrenzen und vorberechnen würde, könnte man einfach die x und die y Position für den jeweiligen Punkt aus einer Tabelle auslesen.
Problem ist, daß im Original Virus sich die Objekte nicht ruckhaft von Fläche zu Fläche bewegen, denn das würde bedeuten, daß es nur vier Bewegungsrichtungen gibt mit je einer Geschwindigkeit (Fläche ==> Fläche). Die Objekte rotieren aber um die Y-Achse, so daß bei einer Bwegung der X-Anteil und der Z-Anteil der Schrittweite beliebige Werte zwischen 0 und der aktuellen Geschwindigkeit annehmen können. Dadurch bewegen sich auch die Landpunkte nicht in einem festen Raster über den Bildschirm, so daß eine Berechnung über Tabellen aufgrund der hohen Anzahl verschiedener X-, Y- und Z-Werte nicht funktionieren dürfte. Wie ich schon schrieb, könnte man zur Berechnung Logarithmentabellen einsetzen. Das ist ein wenig aufwendiger, erspart aber dafür große Tabellen. Nur was die Genauigkeit anbelangt habe ich halt Zweifel, aber solange man es nicht probiert hat...
Problem ist, daß im Original Virus sich die Objekte nicht ruckhaft von Fläche zu Fläche bewegen, denn das würde bedeuten, daß es nur vier Bewegungsrichtungen gibt mit je einer Geschwindigkeit (Fläche ==> Fläche). Die Objekte rotieren aber um die Y-Achse, so daß bei einer Bwegung der X-Anteil und der Z-Anteil der Schrittweite beliebige Werte zwischen 0 und der aktuellen Geschwindigkeit annehmen können. Dadurch bewegen sich auch die Landpunkte nicht in einem festen Raster über den Bildschirm, so daß eine Berechnung über Tabellen aufgrund der hohen Anzahl verschiedener X-, Y- und Z-Werte nicht funktionieren dürfte. Wie ich schon schrieb, könnte man zur Berechnung Logarithmentabellen einsetzen. Das ist ein wenig aufwendiger, erspart aber dafür große Tabellen. Nur was die Genauigkeit anbelangt habe ich halt Zweifel, aber solange man es nicht probiert hat...
Ja, richtig. Die Objekte, d.h. diejenigen, die über Sprites gelöst werden, sollen sich frei bewegen können und nicht in einem Raster. Dort auch mit "echter" Division bzw. log-Tabellen o.ä..
Mir ging es nur um die Darstellung der Landschaft, die man, ausgehend von der ZX Spectrum Version, auch ohne Multiplikation umsetzen könnte.
Dort wird die Landschaft (scheinbar) nicht pixelweise verschoben, sondern nur im Raster. (Keine Frage, die Original-Version sieht um Längen besser aus.)
Ich gehe davon aus, dass das Player-Raumschiff durch die rasterweise Verschiebung der Landschaft auch so wirken würde, als ob es sich bzgl. der Landschaft nur in dem Raster bewegen würde und bzgl. der Objekte frei/pixelweise, weil das Player-Raumschiff, außer in der Achse, die die Y-Achse des Monitors wiederspiegelt, sich immer an einer festen Stelle auf dem Bildschirm befindet.
Zur Umsetzung über Tabellen hatte ich noch einen Gedanken:
Man benötigt wegen der Symmetrie nur ein Viertel der vorher angegebenen Tabellengröße und könnte so 4 mal mehr Pixel mit dem selben Speicherplatz darstellen.
Ein anderer Gedanke war, dass man die Tabellen weiter verkleinern könnte bzw. die Details im unteren Bereich erhöhen könnte, weil man die Spielfläche nie (?) am oberen Rand sieht, d.h. so als ob man von unten nach oben schaut, so dass sie oben am oberen Rand des Bildschirms dargestellt wird.
Was die Framerate angeht, würden natürlich mehr dargestellte Pixel diese weiter senken.
Und man bräuchte auch, wie von Dir genannt, eine interne Repräsentation für größere Karten, welche die Geschwindigkeit weiter senken würde. (Die Lösung sind aus meiner Sicht Tiles.)
Vielleicht wäre die Darstellung der Landschaft mit mehr Pixeln zufriedenstellend genug, so dass man sich die Divisionen und Polygone dafür spart.
Natürlich würde mich auch interessieren, wie schnell echte Polygone oder Linien wären
------
Einen Hinweis oder Anreiz darauf, wie die max. Güte aussehen könnte, zeigt ein Programm aus dem 64'er-Magazin:
"Superfrac 64" im 64'er Nr. 75 auf Seite 14
https://archive.org/details/64…heft_75/page/n13/mode/2up
Die Berechnungsdauer für einen Ausschnitt dauert, je nach Qualität, mehrere Sekunden bis zu ca. einer Minute und wäre für ein Spiel unbrauchbar.
Nachfolgend einige Screenshots. Es lassen sich MC und Hires auswählen:
Ich glaube nicht, daß sich solch ein Spiel auf den C64 umsetzen läßt, jedenfalls nicht in einer spielbaren Form, eher sowas wie "Hard Driving".
Ich sehe das auch nicht auf einem Stock-C64. Allerdings mit einer U64 und aktiviertem Turbomodus sieht das schon anders aus. Und wenn man schon auf der Plattform ist, kann man die REU noch mit einbeziehen, dann könnte das gut laufen. Aber der normale C64 ist für sowas einfach zu langsam.
Selbst mit U64 und Turbo haette man nach wie vor das Problem, dass es nicht so bunt werden kann, aufgrund der Grafikeinschraenkungen des VIC-II. Man koennte sich vielleicht eine Grafik wie bei Sentinel vorstellen, nur eben bewegt:
Oder mit geditherten Flaechen, so wie bei Driller. Aber das wuerde beides nicht so cool aussehen wie das Original. Vielleicht ist da die Optik der Spectrum-Version gar nicht so schlecht, die geht einen anderen Weg, aber eben einen Weg des Machbaren.
Selbst mit U64 und Turbo haette man nach wie vor das Problem, dass es nicht so bunt werden kann, aufgrund der Grafikeinschraenkungen des VIC-II.
Das ist klar, darauf hatte ich aber auch gar nicht abgezielt, mir ging es erstmal nur um die Geschwindigkeit. Ich habe aber auch gar nichts dagegen, wenn ein solches Spiel weiterhin wie ein C64-Spiel aussieht.
Finde ich eine sehr interessante idee mit Virus auf dem C64.
M. J. wie siehts eigentlich mit Elite aus? Ist das Projekt nun endgültig tot? Deine letzte Version war deiner aussage nach zwar Verbuggt, aber ich habe sie nun ne ganze weile lang gespielt und der einzige Fehler den ich bemerken konte, war das noch immer fehlende Fadenkreuz. ( Leider ist Elite 128 2.0 wegen seines Laser bugs nur als unspielbar zu bezeichen. Deine Version wäre also sobald sie ein Fadenkreuz hätte, die definitiv derzeit beste für den C64 )
Deine Version wäre also sobald sie ein Fadenkreuz hätte, die definitiv derzeit beste für den C64 )
Kleiner Hot-Fix für das Fadenkreuz.
poke53248,161:poke53249,101:poke53271,255:poke53277,255
In Ergänzung zu M.J.'s Beitrag #13 - der Kommentar zum Spieltest in der Happy Computer 4/88, auf Seite 79, spricht eigentlich für sich:
QuoteDisplay MoreZarch und seine Folgen
Ich fahre mit meinem Wagen auf der A9 von München in Richtung Nürnberg. Viele LKWs und der Feierabend-Verkehr machen die Autobahn dicht. Plötzlich drehe ich mich um, damit ich mehr sehen kann, als der Rückspiegel offenbart. Ich war sicher, daß mir eine Zielsuchrakete folgte und mich fast erwischt hätte. Doch da sind nur Autos. Ich sehe wieder nach vorne und suche neben dem Tachometer vergeblich meinen Radarschirm. Aber da ist nichts. Sind meine sämtlichen Radarstationen etwa schon abgeschossen? Die Drone hinter mir feuert mit ihrer Laser-Kanone. Ich reiße mein Steuer hoch...
Ich muß verrückt sein. Auf der A9 gibt es keine Zielsuchraketen und in meinem Auto keinen Radarschirm. Die Drone hinter mir war ein LKW, dem meine Fahrweise aufgefallen ist. Es ist das Spiel, das mich so quält. Zarch auf dem Archimedes hat mich so gefesselt wie kein anderes Spiel zuvor. Ich spiele selten mit meinem Computer und wenn, dann meistens eine gute Partie Schach. Aber da gibt es auch keinen Laser.
Zarch fesselt und wenn man die Steuerung mit der Maus im Griff hat, kann es mitunter schon zu Problemen mit der Steuerung des eigenen PKW kommen.
Einziger Haken bei Zarch: Die Handlung ist etwas geschmacklos und man hätte die Thematik sorgfältiger auswählen sollen. (wo)
ein Programm aus dem 64'er-Magazin
Hättest Du vielleicht den dazu gehörigen Programmcode, damit ich mir das Programm mal ansehen kann? Auf den ersten Blick würde ich sagen, daß a) die Berechnung mit den Fließkommaroutinen des Basic-Interpreters oder einem umständlichen Zahlenformat durchgeführt wird, b) ich mir nicht sicher bin, ob es sich bei der Darstellung wirklich um 3d handelt oder einfach nur um verschobene 2d-Punkte, die mit Linien verbunden werden., So oder so erzeugt solch ein Programm Dreiecks-Polgone, wohingegen ein Spiel wie "Virus" die Landschaften aus Vierecken zusammensetzt, d. h. die zugrundeliegende Symmetrie ist anders.
Ein anderer Gedanke war, dass man die Tabellen weiter verkleinern könnte bzw. die Details im unteren Bereich erhöhen könnte, weil man die Spielfläche nie (?) am oberen Rand sieht, d.h. so als ob man von unten nach oben schaut, so dass sie oben am oberen Rand des Bildschirms dargestellt wird.
Verzeih, eine kleine Frage: Hattest Du bei den Tabellen berücksichtigt, daß die Kamera nach oben und unten bewegt werden kann, wodurch die Punkte anders gestreckt/gestaucht werden?
Die Lösung sind aus meiner Sicht Tiles.
Ich vermute, Du meinst damit sowas wie "Subkarten", d. h. es gibt eine große Karte, z. B. 16 x 16. Jedes Element dieser Karte besteht wiederum aus 4x4 Elementen, die die finale Höhe angeben. WIll man also die Höhe an einem Punkt ermitteln, nimmt man X/Y, teilt diese durch 4, holt sich die "Kachel" aus der großen Map und indiziert dann die Submap/Kachelmap mit den verbliebenen unteren 2 Bits. Dadurch käme man in diesem Beispiel auf eine Gesamtgröße der Karte von 64x64 Werten. Andere Werte sind natürlich nach Belieben möglich.
Natürlich würde mich auch interessieren, wie schnell echte Polygone oder Linien wären
Mich auch. Einfach nur so aus Interesse. Wenn ich mehr Zeit hätte, würde ich ja mal ein kleines Testprogramm schreiben...
wie siehts eigentlich mit Elite aus? Ist das Projekt nun endgültig tot?
Wegen Corona sind leider alle großen Projekte zur Zeit aufs Eis gelegt. In den Fällen, wo ich zwischendurch mal Zeit gehabt habe, habe ich mich bewußt auf kleine Sachen beschränkt, da sie ansonsten im gegebenen Zeitraum nicht fertig geworden wären. Mit "Elite" habe ich mich kurz mal zwischendurch befaßt, aber es dann wieder liegen lassen. Der Grund hierfür ist, daß das Programm an sehr vielen Stellen überarbeitet werden müßte (z. B. auch im Menüsystem für Einkaufen/Verkaufen). Ein vernünftiges Umschreiben des Codes scheitert aber daran, daß es im Programm zu viele Berechnungen mit Konstanten gibt, die darauf ausgelegt sind, mit nur genau der Rechengenauigkeit, die in "Elite" verwendet wird, zu funktionieren. und ansonsten unbrauchbare Werte liefern. Von daher glaube ich nicht, daß ich auf absehbare Zeit auf das Spiel zurückkommen werde.
Hättest Du vielleicht den dazu gehörigen Programmcode, damit ich mir das Programm mal ansehen kann? Auf den ersten Blick würde ich sagen, daß a) die Berechnung mit den Fließkommaroutinen des Basic-Interpreters oder einem umständlichen Zahlenformat durchgeführt wird, b) ich mir nicht sicher bin, ob es sich bei der Darstellung wirklich um 3d handelt oder einfach nur um verschobene 2d-Punkte, die mit Linien verbunden werden., So oder so erzeugt solch ein Programm Dreiecks-Polgone, wohingegen ein Spiel wie "Virus" die Landschaften aus Vierecken zusammensetzt, d. h. die zugrundeliegende Symmetrie ist anders.
Ich gehe auch davon aus, dass es den Basic Interpreter nutzt + bei den Vierecken hast Du recht.
Verzeih, eine kleine Frage: Hattest Du bei den Tabellen berücksichtigt, daß die Kamera nach oben und unten bewegt werden kann, wodurch die Punkte anders gestreckt/gestaucht werden?
Nein, die Kameraperspektive (=der Winkel auf bzw. die Neigung zum das Spielfeld) würde sich in dieser Vorstellung nicht ändern, sondern es würde einfach ein Offset zur Levelhöhe addiert/subtrahiert werden, d.h. aber auch, dass der 3D-Eindruck bestehen bleibt. Anders ausgedrückt: Man bewegt den Kopf nur parallel zum Boden und kann das Kinn nicht nach unten oder oben neigen
Ich vermute, Du meinst damit sowas wie "Subkarten", d. h. es gibt eine große Karte, z. B. 16 x 16. Jedes Element dieser Karte besteht wiederum aus 4x4 Elementen, die die finale Höhe angeben. WIll man also die Höhe an einem Punkt ermitteln, nimmt man X/Y, teilt diese durch 4, holt sich die "Kachel" aus der großen Map und indiziert dann die Submap/Kachelmap mit den verbliebenen unteren 2 Bits. Dadurch käme man in diesem Beispiel auf eine Gesamtgröße der Karte von 64x64 Werten. Andere Werte sind natürlich nach Belieben möglich.
Ja, richtig.
Mich auch. Einfach nur so aus Interesse. Wenn ich mehr Zeit hätte, würde ich ja mal ein kleines Testprogramm schreiben...
Anbei eine Version mit Linien.
- Meine Line-Funktion hat einige Macken, d.h. die Sonderfälle für horiz./vert. Linien habe ich nicht berücksichtigt und es tauchen in bestimmten Fällen horiz. Streifen auf.
- Im Allgemeinen genügt jedoch diese Version, um eine "etwaige" Vorstellung für die Geschwindigkeit zu entwickeln. (Optimieren kann man sicherlich an vielen Stellen. Es werden Tabellen statt der freien Division oder log-Tabellen verwendet. Hires statt MC wäre auch interessant; dann würde ich jedoch lieber nur ein 256 Pixel anzeigen.)
- Eine Version mit Double-Buffering hatte ich angefangen, aber dann verworfen, weil sie zu unordentlich wurde, d.h. hier müsste ich vorher einwenig umstrukturieren.
testzarch2.prg
Ich wollte noch etwas zu Zarch schreiben.
Ich hatte spaßeshalber einen Screenshot aus dem Youtube-Video gemacht (der Balken ist noch zu sehen), um zu ermitteln, wie groß die Fläche ist, die gezeichnet werden müsste und wie die Farben abgebildet werden könnten. Die schwarze Fläche beträgt ca. 63 Prozent, d.h. es müssten ca. 3000 Bytes für die Landschaft gezeichnet werden.
Nachfolgend der Vollständigkeit halber einfach die Screenshots, in die ich aus dem ursprünglichen erstellt hatte, um die Optik/Formate zu vergleichen:
