Hello, Guest the thread was called7.6k times and contains 191 replays

last post from wizball6502 at the

Zarch (Virus) auf dem C64 1:1 machbar?

  • 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:


  • Ganz ehrlich, ich kann mir nicht vorstellen, dass der C64 in der Lage ist, ein PEFORMANTES Spiel in der Art zu wuppen. Schon die Specci-Version zeichnet sich durch eine extrem niedrige Framerate aus (gefühlt 4 fps, und das bei einem Z80 mit 3,5 MHz) – was will der C64 da reißen? Dazu kommt, dass bei Virus Farbe eine gewisse Rolle spielt (die verseuchten Flächen werden in rot/braun-Tönen dargestellt) und dass man mit einem 1-Button Digital-Joystick auch nur schwer in der dritten Dimension navigieren (und dann noch schießen etc.) kann.


    Ich hatte ja schon mal darüber nachgedacht, ob man das ganze Prinzip nicht viel weiter herunterbricht – auf ein 2D oder 2.5D-Spiel. Das ist von der Steuerung her mit einem C64-Joystick einfacher machbar und man bekommt wenigstens ein schnelles Action-Spiel hin, statt einer 3D-Demo, die nicht wirklich gut spielbar wäre. Die denkbare Kritik, dass dabei ein ganz anderes Spiel herauskäme, kann man auch als Chance sehen – wer will schon den schlechten 8-Bit-Abklatsch eines 16/32-Bit-Klassikers spielen, wenn er (und sei es per Emulation) genauso gut das schnelle Original zocken kann. Dann doch vielleicht lieber ein (neues) Spiel, dass zwar genügend Anleihen aus dem Original bewahrt – aber andere Qualitäten hinzufügt.


    Es gibt ja Spiele, die den Sprung aus der 2D-Welt der 8-Bitter in die 3D-Welt der 32-Bitter geschafft haben – z.B. Mario oder Sonic. Mein Grundgedanke ist nun der, dass man quasi den gleichen Weg geht – aber in die umgekehrte Richtung. Man würde also den imaginären 2D-Vorgänger vom 3D-Zarch erfinden – "den Vater, den Zarch nie hatte". ;)


    Das könnte dann vielleicht ungefähr so aussehen:



  • Das sieht schon ziemlich nice aus, erinnert mich ein bisschen an ein Flugzeug-Spiel, das es auf dem Spectrum gab und recht gute Grafik hatte, allerdings komm ich grad nicht auf den Namen. Das war aber tatsaechlich auch ein Spiel, an das ich beim Lesen des Threads schon denken musste, aber eher mit dem Gedanken dass das ja nix waere. Der Mockup von Dir sieht aber schon cool aus und macht auch Lust auf ein solches Spiel, selbst wenns gar nix mit Virus zu tun haette, sondern einfach nur generell ein Spiel mit netter Grafik waere.


    Die Frage waere lediglich, koennte man das Flugzeug auch sinnvoll "auf und ab" steuern lassen? Vermutlich waere das schwierig, sofern das fuers Gameplay notwendig waere.

  • Habs gefunden, "Tornado Low Level / TLL":



    Vielleicht waere so ein Spiel dann auch was fuers upcoming Protovision Pad, welches ja wie ein SNES-Pad aufgebaut ist und dementsprechend auch Knoepfe fuer "steigen und sinken" haette...

  • Ganz ehrlich, ich kann mir nicht vorstellen, dass der C64 in der Lage ist, ein PEFORMANTES Spiel in der Art zu wuppen. Schon die Specci-Version zeichnet sich durch eine extrem niedrige Framerate aus (gefühlt 4 fps, und das bei einem Z80 mit 3,5 MHz) – was will der C64 da reißen? Dazu kommt, dass bei Virus Farbe eine gewisse Rolle spielt (die verseuchten Flächen werden in rot/braun-Tönen dargestellt) und dass man mit einem 1-Button Digital-Joystick auch nur schwer in der dritten Dimension navigieren (und dann noch schießen etc.) kann.

    Schnell und bunt? Der CPC kann das. :D


  • Der Mockup von Dir sieht aber schon cool aus

    Dankeschön – das freut mich.


    macht auch Lust auf ein solches Spiel, selbst wenns gar nix mit Virus zu tun haette, sondern einfach nur generell ein Spiel mit netter Grafik waere.

    Wenn man sich inhaltlich weiter von Virus entfernen möchte, könnte ich mir vorstellen, dass man so eine Leute-Retten-Mechanik (wie bei Shoplifter) einbaut.


    Die Frage waere lediglich, koennte man das Flugzeug auch sinnvoll "auf und ab" steuern lassen?

    Nun ja, da könnte man drüber nachdenken. In der simpelsten Form könnte man darauf verzichten und alles (technisch gesehen) auf der gleichen Ebene stattfinden lassen. Optisch könnte man trotzdem natürlich die Höhe variieren – über den Schatten-Abstand – z.B. wenn man vom Strand übers Wasser fliegt (oder über andere optische Höhenunterschiede) das Raumschiff leicht absacken und federn lassen etc. Sodass das nicht so steif aussieht, wie bei vielen anderen Games.


    Schon beim Drehen gibt es ja unterschiedliche Möglichkeiten – ich würde erst einmal folgendes probieren: Mit [links] und [rechts] könnte man das Schiff (in 15°-Schritten) drehen, mit [hoch] könnte man beschleunigen, mit [runter] könnte man abbremsen, mit [Feuer] würde man schießen.


    Man könnte aber auch gucken, wie es ist, mit einer Auto-Geschwindigkeit zu fliegen und [hoch] und [runter] zur Höhenkontrolle einzusetzen. Gleichzeitig könnte man unten langsamer fliegen und weiter oben automatisch schneller. Dann müsste man sich auch in einer ähnlichen Höhe wie der Gegner befinden (am Schattenabstand zu erkennen), um ihn zu treffen (und umgekehrt natürlich auch).

  • Ich denke, dass bei so einem 2D-Spiel genügend Herausforderungen für einen Programmierer drinstecken – angefangen bei einer schnellen 360°-MC-Char+ColorRAM-Scrollroutine mit unterschiedlichen Geschwindigkeiten. Dann ein Landschaftsgenerator, der aus Höhenwerten und Tile-Bestandteilen diese 2.5D-Kacheln generiert und darauf die weiteren Char-Objekte (Bäume, Häuser etc.) platziert. Und auch eine schöne Pseudo-Physik, damit sich die beweglichen Objekte wirklich cool bewegen, vor allem das eigene Raumschiff – nachziehen, bouncen usw., damit man ein gutes Flug-Gefühl bekommt. Das Ganze wäre selbst in dieser 2D-Ansicht noch eine ganz gute Coding-Herausforderung.

  • Ganz ehrlich, ich kann mir nicht vorstellen, dass der C64 in der Lage ist, ein PEFORMANTES Spiel in der Art zu wuppen. Schon die Specci-Version zeichnet sich durch eine extrem niedrige Framerate aus (gefühlt 4 fps, und das bei einem Z80 mit 3,5 MHz) – was will der C64 da reißen? Dazu kommt, dass bei Virus Farbe eine gewisse Rolle spielt (die verseuchten Flächen werden in rot/braun-Tönen dargestellt) und dass man mit einem 1-Button Digital-Joystick auch nur schwer in der dritten Dimension navigieren (und dann noch schießen etc.) kann.


    Ich glaube, dass das Zeichnen/Scrolling der Landschaft mindestens genau so "gut" aussehen kann, wie auf dem ZX Spectrum.
    Die Umsetzung der Farben stellen mit Sicherheit die Herausforderung dar.
    Die Festlegung auf MC mit 4 Farben einscheint mir rein techn. gesehen sinnvoll.
    Für den Spielspaß im Vergleich zum Original wäre das bestimmt ein Negativpunkt; im Vergleich zur ZX Spectrum Version dann jedoch wieder nicht.
    Falls eine Steuerung über den Joystick, den Ansprüchen nicht gerecht wird, könnte man die Maus in Betracht ziehen.
    (Die anderen Versionen lassen sich ja auch irgendwie über den Joystick und/oder die Tastatur steuern; also sollte es auf dem C64 auch genauso gut (=ohne Abstriche) gehen.)

    Bis vor einigen Minuten, wäre ich auch Deiner Meinung, was die Umsetzbarkeit der Darstellung angeht.
    Dann habe ich gemerkt, dass der Screenshot, den ich zur Hilfe verwendet habe, sehr unvorteilhaft war.
    Es gibt eine Online-DOS-Box mit dem Spiel. Von dort heraus habe ich einen neuen Screenshot erstellt.
    https://classicreload.com/zarch-lander.html



    Der Vorteil ist, dass man eine saubere 320x200 Auflösung hat und das Spielfeld anders als im Video (=den anderen Versionen) aufgebaut und proportioniert ist.
    Der Ausschnitt ca. 8x9 (?) Kacheln groß und max. 256 Pixel breit. Die schwarze Fläche beträgt ca. 84%, d.h. der Ausschnitt ist ca. 16% bzw. 1280 Bytes groß.
    Das sollte doch mit dem C64 machbar sein, oder nicht?

    Für eine "imaginäre" C64 Version könnte man also die Landschaft (ca. 32x8+ Zeichen) links zeichnen und hätte dann rechts 8 chars für die Map.
    Bei der Online-Version kann man einwenig ausprobieren und sehen, wie das Raumschiff immer an der selben Stelle gezeichnet wird und wie eine Maussteuerung umgesetzt werden könnte.
    (...)

    M.M.n. müsste zuerst eine schnelle Füllroutine für die Vierecke her; dann könnte man wieder was zur Geschwindigkeit/Umsetzbarkeit sagen und ob man für den Rest evtl. vorberechnete Sprites nutzen könnte/müsste.
    (((Ein Wort noch zum Vergleich: Das Testprogramm mit den Linien testzarch2.prg hatte fast doppelt soviele Punkte/Flächen, wie die Version im neuen Screenshot.)))

    ------
    Zu Deinem Mockup: Ich mag die klaren Farben und Linien + Es ist interessant zu sehen, in welche Richtung die Vorstellung gesponnen werden kann.

  • Ich mag die klaren Farben und Linien + Es ist interessant zu sehen, in welche Richtung die Vorstellung gesponnen werden kann.

    Danke. Ich denke, ich werde da erstmal nichts weiter machen. Wenn ein Programmierer Lust auf eine Umsetzung in der Art hat (und von mir Assets haben möchte), kann er sich ja mit mir in Verbindung setzen.

  • Da das per PN diskutiert wird: Mein Entwurf ist nach 1. Durchsicht optimiert für den Multicolor-Character-Mode. Alle Landschaften inkl. der Häuser und Bäume sollten (meines Erachtens) innerhalb der Spezifikationen liegen. Das eigene Raumschiff, die Gegner und deren Schatten, sowie die Schüsse sollten mit Sprites umgesetzt werden (weiß und mittelgrau für alle – plus individuelle Farbe). In dem Mockup wären also 7 Sprites zu sehen: Raumschiff plus Schatten und Antriebs-Ausstoß, Gegner plus Schatten und 2 x Schüsse. Ein Sprite-Multiplexer wäre von Vorteil, wenn man noch mehr Gegner gleichzeitig zeigen will. Background- und MC-Colors wären Hellrot, Dunkelgrau und Hellgrün (wie zu verteilen, müsste man noch gucken). Für die individuelle Char-Farbe sind ausschließlich die ersten 8 verwendet worden.


    Aber wenn mir da irgendein Gedankenfehler unterlaufen ist, bitte ich hiermit um Korrektur. Merci. [Edit: ich habe Denkfehler gemacht, war doch noch zu sehr im Bitmap-Mode verhaftet – ich versuche die Bugs zu beheben und hoffe, dass das Ergebnis nicht zu trist wird]

  • Nun habe ich die Farben korrigiert, sodass der Untergrund, die Bäume und die Häuser vollständig im Multicolor-Character-Mode darstellbar sein müssten. Was mich jetzt interessieren würde, ist, ob es eine Scrollroutine gibt, die man für so eine Art Spiel verwenden könnte. Sie müsste ja MC-Chars inkl. ColorRAM scrollen und zwar möglichst performant (sodass vielleicht sogar noch CPU-Zeit für einen Sprite-Multiplexer übrig bliebe?). Man müsste eine große Spielfläche verwalten können – wahrscheinlich über größere Tiles. Und man muss in unterschiedlichen Geschwindigkeiten (wenn sehr langsam, dann soft/pixelweise) und in diversen Winkeln scrollen können. Gibt es sowas schon? Oder hat jemand eine Idee, wie das zu lösen wäre? Wäre sowas überhaupt realistisch?


  • Nun habe ich die Farben korrigiert, sodass der Untergrund, die Bäume und die Häuser vollständig im Multicolor-Character-Mode darstellbar sein müssten. Was mich jetzt interessieren würde, ist, ob es eine Scrollroutine gibt, die man für so eine Art Spiel verwenden könnte. Sie müsste ja MC-Chars inkl. ColorRAM scrollen und zwar möglichst performant (sodass vielleicht sogar noch CPU-Zeit für einen Sprite-Multiplexer übrig bliebe?). Man müsste eine große Spielfläche verwalten können – wahrscheinlich über größere Tiles. Und man muss in unterschiedlichen Geschwindigkeiten (wenn sehr langsam, dann soft/pixelweise) und in diversen Winkeln scrollen können. Gibt es sowas schon? Oder hat jemand eine Idee, wie das zu lösen wäre? Wäre sowas überhaupt realistisch?


    Also da ich ja Progging noob bin, kann ich nur die Optik beurteilen und die gibt schon ein eindeutiges VIRUS Feeling her. Eine Sache die zumindest für mich wichtig wäre ( Falls machbar ) wäre ein möglichst weich rotierentes Spielerschiff, also viele Abstufungen. Wird wohl aber eher nicht gehen, oder?

  • Eine Sache die zumindest für mich wichtig wäre ( Falls machbar ) wäre ein möglichst weich rotierentes Spielerschiff, also viele Abstufungen. Wird wohl aber eher nicht gehen, oder?

    Von der Steuerung her schon. Wie ich ja schon schrieb: Mit [links] und [rechts] könnte man das Schiff (z.B. in 15°-Schritten) drehen, mit [hoch] könnte man beschleunigen (oder sinken) ... Das Spielerschiff müsste man natürlich in allen Winkeln pixeln. Was das Scrolling in den verschiedenen Winkeln anginge, müsste das jemand beantworten, der sich mit Scrolling auskennt. Bei 15° wären das 6 Winkel auf dem Viertelkreis (15/30/45/60/75/90), also insgesamt 24 Winkel auf 360°. Man könnte natürlich auch mit weniger Winkeln arbeiten, 16 z.B. Wenn man hingegen eine Steuerung wählt, wie in vielen anderen Games ([links] steuert das Raumschiff direkt nach links/westen statt es gegen den Uhrzeigersinn zu drehen), benötigt man halt nur 8 Richtungen (für die 8 Joystick-Möglichkeiten).

  • Man kann auch einfach die Grafik von Parallax ändern

    :thumbdown:


    Parallax' Engine finde ich für den Zweck eher ungeeignet. Den namensgebenden Parallax-Effekt benötigt man hier nicht, dafür ist das Scrolling des alten Spiels eher langsam, kann nur 8 Richtungen (geht überhaupt mehr mit dem C64?) und es wird wahrscheinlich nicht einmal das Color-RAM mitgescrollt. Das Spielersprite bewegt sich auch viel zu starr und man bekommt keinerlei "Fluggefühl". Wenn man auch nur ein bisschen Zarch-Feeling bekommen will, muss der Coder schon mehr tun, als nur eine Fläche in 8 Richtungen zu schieben. Deswegen ja meine Fragen dazu ...

  • Was mich jetzt interessieren würde, ist, ob es eine Scrollroutine gibt, die man für so eine Art Spiel verwenden könnte. Sie müsste ja MC-Chars inkl. ColorRAM scrollen

    Im 64er Sonderheft gibt es einen Artikel zu Freedirectionalscrolling mit unten angehängtem Beispielcode, aber ohne Farbram wimre.


    Auch Lasse hat ein paar dazu aufgeschrieben: https://cadaver.github.io/rants/scroll.html