Hallo Besucher, der Thread wurde 46k mal aufgerufen und enthält 300 Antworten

letzter Beitrag von clarkkent am

Boulder Dash: C64-typisch vs. Atari 800 Optik

    Zitat von LogicDeLuxe

    Sehe ich nicht. Der wird doch nur anders aufgeteilt, aber dabei nicht größer. Aus einem ganzen Zeichensatz kann man zwei halbe machen, und z.B. jeweils die zweite Hälfte für Code nutzen.

    Stimmt, man kann Sprites / Code oder sonst was darin ablegen.

    Zitat von Acorn

    Da mir der Grafik-style von Retrofan sehr gut gefällt, könnte damit auch der Weg für ein BD64-Deluxe frei sein.

    Erst mal vielen Dank. Freut mich, wenn meine Grafik Anlass war, dass sich einige Leute hier echt Gedanken um eine mögliche Realisierung machen.


    Aber deine Engine hat ja auch Beschränkungen, die sich direkt auf die Grafik auswirken:

    Zitat von Acorn

    Die Grafik wird immer aus Tiles aufgebaut, selbst bei 1x2 Zeichengröße und nur für das obere Zeichen hat man eine Farbe aus dem Farbram.


    Je größer die Tiles desto weniger Farben aus dem Farbram.

    Meine Diamanten, die in jedem der 4 Chars die freie Farbe wechseln, wären damit nicht möglich, oder?


    Zitat von Acorn

    - Sprites sind zwar möglich, aber mit den üblichen Aufwand verbunden.

    Was meinst du mit "üblicher Aufwand"? Also der übliche Aufwand, den Sprites generell so mit sich bringen (eigentlich sind die doch auf dem C64 relativ leicht zu handlen) oder gibt es irgendwelche Einschränkungen?



    Da sich ja schon Mehrere hier Gedanken zu einer möglichen Realisierung machen, habe ich auch ein wenig weiter herumgepixelt. Herausgekommen ist eine Animation, die Boulder Dash bislang ja nicht kennt: Ein Rockford mit einer vertikalen Laufbewegung. Im Prinzip springt Rockford auch hier von Tile zu Tile. Da ich aber von Sprite-Nutzung ausgehe, kann ich ihn leicht mit einem Fuß ins nächste Tile hinein dippen lassen, was den Sprung weniger groß aussehen lässt. So wirkt die Bewegung etwas weniger grob – trotzdem bleibt noch der typische, sprunghafte BD-Style etwas erhalten.


    BD-Rockford-run-down.gif

    Zitat von Retrofan

    Was meinst du mit "üblicher Aufwand"? Also der übliche Aufwand, den Sprites generell so mit sich bringen (eigentlich sind die doch auf dem C64 relativ leicht zu handlen) oder gibt es irgendwelche Einschränkungen?

    Mit der beschriebenen Routine muß man schon das Timing genau im Blick behalten. Da ist es naheliegend, daß Sprites die Sache verkomplizieren.

    Zitat von Drachen

    eigentlich müsste ein Stein nach unten fallen. Ich weis bloss nicht welcher.

    Vom rechten Stapel würden die oberen beiden gleichzeitig, also im selben Scanzyklus nach links abrutschen. Im zweiten Scanzyklus würde der obere von den beiden auf den unteren zunächst zum Liegen kommen, und der untere würde weiter nach unten fallen. Im dritten Scanzyklus würde der obere Stein erneut fallen, da der untere gerade Platz gemacht hat, und der untere kommt auf der Mauer wieder zum liegen (sofern es keine Zaubermauer ist). Im vierten Scanzyklus kommt schließlich auch der obere Stein auf dem unteren Stein zum liegen.
    Anders würde es natürlich aussehen, wenn Rockford sofort nach unten los läuft, und nicht, wie in der Animation dargestellt, erst kurz wartet.

    Hier mal eine Version vom Scrolling, wie sie auch in unserem Demo verwendet wird: scroll.prg Bewegen mit Joystick Port 2. Der graue Bereich im Rahmen zeigt an, wieviel Rechenzeit zum kopieren draufgeht. Wahrscheinlich geht das alles sogar noch besser. Aber ich denke, mit dieser Technologie wäre z.B. Auch eine Sams-Journey-Version für NTSC ohne REU möglich gewesen ...

    Zitat von Drachen

    Wollte mal nachfragen ob es neue Info gibt zum neuen Grafikgewand bei Bolder Dash und eventuell Programmierung eines neuen Bolder Klon mit dieser Grafik.

    Meine Grafik steht soweit und ich würde sie um die noch fehlenden Elemente erweitern, wenn jemand eine Engine fertig programmiert, die er damit verschmelzen möchte. Es hat sich halt gezeigt, dass der C64 mit so einer Engine mehr zu kämpfen hat, als anfangs (von mir) gedacht. BD ist recht gut auf die Möglichkeiten eines Atari 8-Biters zugeschnitten und bei einer Umsetzung auf den C64 muss man immer noch Abstriche bei den eigentlich vorhandenen (z.B. Farb-) Möglichkeiten machen. Trotzdem wäre ein BD mit der hier angedachten Engine und meinen Pixeleien durchaus ein (kleiner?) Fortschritt zum Status Quo. Die Frage ist halt, ob einem Coder das als Ergebnis reicht, um den Aufwand zu rechtfertigen. Wie gesagt, an mir soll es nicht scheitern.

    Geht es noch irgendwo weiter? Oder ist hier abrupt das Thema gestorben?

    Liest sich äußerst interessant! Hätte nie gedacht, dass gerade Boulderdash so eine Herausforderung für den 64er darstellt, wo die Grafik auf den ersten Blick doch recht simpel aussieht, habe mich aber damals schon gewundert, warum es auf dem Atari irgendwie "hübscher" aussieht. Auch die Idee mit dem speziellen C128-BoulderDash klingt sehr interessant - seit dem letzten Post sind ja ca. 500 Tage vergangen - habt Ihr Eure Ideen noch weiter geführt und etwas auf die Beine stellen können??

    Es zeigte sich ja, dass es weniger trivial als anfangs von mir gedacht war, Boulderdash grafisch zu "64ern". Ich nehme an, dass letztlich von den Programmierkundigen gedacht wurde, der grafische Effekt würde den großen Aufwand nicht lohnen. Selbst, wenn man Boulderdash optisch mehr in Richtung typischer C64-Grafik trimmen würde, bleibt das ganze Spiel von Aufbau her ein Game, dass optimalen Gebrauch von bestimmten Atari-Features (Display-List) macht. Auf dem C64 würde man ein ähnliches Spiel vielleicht auf vertikales Scrolling beschränken und die Levels dafür beliebig tief anlegen. Ich hätte durchaus Lust, so einen "Clone" mit meiner (teils ja schon existierenden) Grafik zu unterstützen. Das wäre dann insgesamt noch typischer für den C64.

    Zitat von oobdoo

    Ich erkenne bis auf Farben und Sound besonderen Unterschiede zwischen XL, C64 und CPC Version. :gruebel

    Ist Dir da ein Wort abhanden gekommen? :D:D

    Zitat von Retrofan

    Es zeigte sich ja, dass es weniger trivial als anfangs von mir gedacht war, Boulderdash grafisch zu "64ern". Ich nehme an, dass letztlich von den Programmierkundigen gedacht wurde, der grafische Effekt würde den großen Aufwand nicht lohnen. Selbst, wenn man Boulderdash optisch mehr in Richtung typischer C64-Grafik trimmen würde, bleibt das ganze Spiel von Aufbau her ein Game, dass optimalen Gebrauch von bestimmten Atari-Features (Display-List) macht. Auf dem C64 würde man ein ähnliches Spiel vielleicht auf vertikales Scrolling beschränken und die Levels dafür beliebig tief anlegen. Ich hätte durchaus Lust, so einen "Clone" mit meiner (teils ja schon existierenden) Grafik zu unterstützen. Das wäre dann insgesamt noch typischer für den C64.

    Habe mir ja den Thread soweit durchgelesen, aber leider hab ich zu wenig Ahnung von den hier beschriebenen Hardwarefunktionen der jeweiligen Rechner. Läßt es sich in wenigen Worten auch für den DAU erklären, was der Atari so nebenbei bewältigt, was für den C64 aber ein Kraftakt ist und warum gerade das so entscheidend für das ansonsten grafisch doch eher unscheinbare Spiel ist?

    Ich ziehe für mich immer laienhafte Vergleiche - okay, bei Horizontalscrollern scheint der 64er "im Vorteil" zu sein - richtig? Also ist Katakis/R-Type - um bei meinen Beispielen zu bleiben - eher ein typisches 64er Spiel?!?

    Aber es gibt doch auch diverse Vertikalscroller auf dem 64er und Turrican scrollt in alle Richtungen und noch dazu mit unzähligen Sprites - also die Spielfigur ist viel flexibler, als Rockford und dieser muss der Hintergrund doch auch folgen?!? Mir fehlt da irgendwie gerade die entscheidende AHA-Sequenz, warum daher BD so schwierig umzusetzen ist?!ß

    Aber andererseits seit ihr ja im Dialog auf einige neue Ideen gekommen, die man wohl auch zusammenfassen und kombinieren könnte, um Rechenzeit und Speicher zu sparen und sich Reserven zu schaffen - was sagen denn die anderen "Entwickler", die sich da programmiertechnisch schon intensiver mit beschäftigt haben? Wäre schade, wenn Eure bisher vorhandenen Ressourcen und Routinen da nicht genutzt würden... Wäre schade, wenn das Projekt "sterben" würde!!!

    Hab mich nochmal ganz an den Anfang begeben und den Rest auch gelesen - wußte gar nicht, dass es auch eine plus/4 Version gibt - hätte ich früher liebend gerne gehabt - heute natürlich auch, nur schade, dass da offenbar kein Sound im Spiel selbst vorhanden ist, zumal der plus/4 ja eine Stimme rauschen lassen kann, was die Grabgeräusche sicher gut wiedergegeben hätte...


    Zu den neuen Bildern und Animationen - die HIER oben gezeigten sind schon recht interessant, wobei ich mich ZeHa anschließen muss - die originalen Diamanten sind einfach perfekt, wie sie sind - Deine 6-eckigen sind auch nicht schlecht, aber die Originale haben einfach was... Die neuen Fireflys hingegen gefallen mir ganz gut - ob Rockford nun etwas runder sein sollte, oder eher originaler - das müsste man im Spiel einfach sehen... Da könnte ich jetzt nicht mal sagen, was mir besser gefällt...

    Zitat von Boulderdash64

    Habe mir ja den Thread soweit durchgelesen, aber leider hab ich zu wenig Ahnung von den hier beschriebenen Hardwarefunktionen der jeweiligen Rechner. Läßt es sich in wenigen Worten auch für den DAU erklären, was der Atari so nebenbei bewältigt, was für den C64 aber ein Kraftakt ist und warum gerade das so entscheidend für das ansonsten grafisch doch eher unscheinbare Spiel ist?

    Warum Boulderdash so viel Rechenzeit benötigt gegen über anderen Spielen. Ein Level besteht aus 40x22 Zeichen, ohne Ränder bleiben davon 38x20=760 übrig. Jedes dieser 760 Zeichen ist ein Objekt im Level und diese werden als einfache Software-Sprite verwaltet.

    Es ist dabei auch egal ob dies Sand ein Diamant oder eine Mauer ist, alles wird abgefragt. Damit das Spiel noch schnell genug läuft, müssen alle Objekte eines Levels in ca. 200 MS (10 FPS) abgearbeitet sein. Die Abfragen der Objekte im Level kostet teilweise aber richtig viel Zeit, beim Schmetterling werden vier Richtungen auf Kollision getestet, danach auf abbiegen, weiter in die selben Richtung oder doch nur drehen. Für das bewegen der Objekt wird weitere Rechenzeit verbraucht. Da der C64 nur ca. 1 Mhz Takt hat, benötigt dieser schon mal deutlich länger als der Atari mit 1.77 Mhz.


    Bildschirm und Scrolling.

    Beim Atari wird einfach ein Ausschnitt der Level-Daten angezeigt, beim scrollen wird dieser einfach in X oder Y verschoben. Der C64 kann dies nicht und muss die Level-Daten in den Bildschirmspeicher als Ausschnitt umkopieren. Das sind ca. 900 Bytes zusätzlich die der Atari nicht bewegen muss. Da die Level-Daten immer kopiert werden müssen, sind auch Tricks wie VSP nutzlos.


    Die meisten Spiele haben solche komplexen Abfragen gar nicht und es werden nur die gerade sichtbaren Gegner berechnet.