Hello, Guest the thread was viewed52k times and contains 300 replies

last post from clarkkent at the

Boulder Dash: C64-typisch vs. Atari 800 Optik

  • Vertikal oder horizontal scrollen macht für den C64 keinen Unterschied

    Das ist bekannt aber gar nicht der Punkt. Es ging mir darum, den Verwaltungs-Speicher, der das gesamte Spielfeld darstellt, möglichst leicht in den sichtbaren Screen zu kopieren. Und ich meine, das wäre einfacher/schneller, wenn die beiden ähnlicher aufgebaut/sortiert wären, man also einen durchgehenden Speicherbereich kopieren kann. Irgendwo im Thread wurde das thematisiert und vielleicht finde ich die Stelle noch wieder. Edit: Hier und hier


    Dh mit dem Remake liefert man ein anderes Titelbild und andere Sprites aus, die in eigenen Dateien liegen.

    Man kann die Dateien am Disk Image aber durch jene aus dem Original ersetzen - dann wird optisch das originale Spiel draus.

    Nur ist das hier überhaupt nicht das Ziel. Es geht nicht darum, BD nachzuprogrammieren und es am Ende genau so aussehen zu lassen. Weder Code noch Grafik noch Name sollen identisch sein.


    Rechtlich: Spielprinzipien sind nicht schützbar. Das einzige, was einem Schutz unterliegt, ist der Code in seiner ursprünglichen Form (wenn man gleiche Ergebnis mit einer abweichenden Anordnung von Befehlen hinbekommt, ist man aus dem Schneider), die Grafik (die ist ohnehin anders, kein Pixel ist aus dem Original übernommen), die Melodie (würde man nicht übernehmen), Der Name, das Logo und das Cover-Art. Auch diese würde man natürlich nicht kopieren.


    Die (zumindest meine) Ziele haben sich über den Thread hinweg etwas verschoben (Stichwort Lernfähigkeit). Ursprünglich dachte ich, man könne Leute damit glücklich machen, BD C64-typischer (= hübscher) aussehen zu lassen und den Rest möglichst nicht anzutasten, um niemanden zu verprellen. Denn BD ist beliebt – also besser nicht zu viel ändern. Der Threadverlauf zeigte mir aber 2 Dinge:


    1) Die Hardcore-BD-Fans wird man ohnehin nur glücklich machen, wenn man gar nichts ändert und höchstens neue Levels für das alte Spiel liefert. In Trillionen Level-Packs und "Nachfolgern" geschehen.

    2) Der C64 tut sich schwer mit der BD-Engine (läuft quasi am Limit), sodass man sie gar nicht so leicht um grafische Features erweitern kann. Die Engine an sich hätte bei einer nativen C64-Entwicklung vielleicht anders ausgesehen.


    Wenn man die "BD-Ultras" ;) mit etwas Neuem also ohnehin nicht glücklich macht und sich der C64 mit der BD-Engine abrackert, warum dann noch möglichst nah am Original bleiben?


    Das Ziel wäre kein 1:1-Clone, der so tut, als sei er BD und käme von der Firma, die die Rechte besitzt (war es auch nie). Das Ziel wäre eher, ein Spiel mit einer BD-ähnlichen Mechanik (davon gibt es dutzende ohne rechtliche Beanstandung), das der C64-Darstellungsqualität und seinen Fähigkeiten schmeichelt. Und ich wäre überhaupt nicht traurig, wenn das Spielfeld anders geformt ist und es zusätzliche Gegner und Gefahren gibt. 1:1-Ripoffs haben mich noch nie großartig interessiert. Ziel bei einer Umsetzung war es für mich immer, dass dabei ein möglichst gutes C64-Spiel herauskommt – Grafisch (natürlich) aber auch vom ganzen Spielgefühl her.


    wie Rockford sich in der Luft halten kann, wird gar nicht erst erklärt.

    Ich habe (mir) das mal so erklärt, dass für Rockford das Spielfeld liegt, während es für den Rest der Mechanik aufrecht steht. Aber das ist natürlich keine physikalische Erklärung. Ich habe aber für den Fall, dass man grafisch weniger abstrakt sein will und alles etwas "logischer" sein soll, auch schon Ideen. In Nachfolgern kann Rockford fliegen (wer denkt da an H.E.R.O.?) aber ich hätte auch Spaß daran, ihn (bzw. seinen entfernten Verwandten Rocky) vertikal an der Rückseite der Gänge entlangkraxeln zu lassen. Wenn er eine Ameise wäre, wäre das nicht ganz weit hergeholt.


    Und für den Fall, dass man es einfach beibehalten möchte, wie gehabt – aber die Spielfigur zumindest nicht seitlich laufen soll, während sie sich nach oben und unten bewegt (eine Sache, die mich schon in den 80ern bei BD nervte), hatte ich ja schon eine grafische Umsetzung gefunden:


    Rocky-Anim.gif


    Das Kraxeln wäre nicht sehr viel anders, da ich für eine rückseitige Wanddarstellung schon gesorgt habe. Der Protagonist würde uns den Rücken zudrehen (also Augen weg) und die Arme würden vielleicht etwas mehr nach oben gehen. That's it.

  • Es ging mir darum, den Verwaltungs-Speicher, der das gesamte Spielfeld darstellt, möglichst leicht in den sichtbaren Screen zu kopieren. Und ich meine, das wäre einfacher/schneller, wenn die beiden ähnlicher aufgebaut/sortiert wären, man also einen durchgehenden Speicherbereich kopieren kann. Irgendwo im Thread wurde das thematisiert und vielleicht finde ich die Stelle noch wieder. Edit: Hier und hier

    Ich glaube das "Genauso ist es" von LogicDeLuxe in deinem ersten Link bezieht sich auf "fehlende Display-List" nicht auf "vor allem weil der Level so breit ist".


    In der Praxis macht es kaum einen Unterschied, ob du einen zusammenhängenden Bereich von 880 Bytes kopierst oder 22 "Streifen" mit je 40 Bytes. Das würdest du so oder so als eine Schleife implementieren, die möglichst selten durchlaufen werden muss und dafür möglichst viel Schreib-/Lese-Operationen in einem Durchgang abarbeitet. Das breitere Spielfeld braucht lediglich ein bisschen mehr Setup vor der Schleife, aber das sollte nicht wirklich viel Unterschied machen.

  • Ich glaube

    Nun ja, wir können ihn hier ja fragen.


    In der Praxis macht es kaum einen Unterschied

    Kann ja sein. Ich bin hier davon ausgegangen, dass es sich anders verhält, als du meinst. Es war halt ein (aus meiner Sicht möglicher) Ansatz, um den Programmierer bzw. den C64 zu entlasten. Wenn das nicht zielführend gewesen sein sollte, dann hat ja vielleicht jemand anderes Ideen, WIE es geht – statt nur, was NICHT geht. Ich wünschte mir also mehr konstruktive Vorschläge.


    Es war aber auch nicht so, dass massenhaft mehr Rechenzeit benötigt wurde, sondern eher nur ein wenig fehlt, um das Color-RAM mitzukopieren – wenn ich mich recht entsinne. Eine (weitere?) Reduzierung der Rechenzeit könnte auch aus einer dezenten Verkleinerung der Spielfläche resultieren, wenn das Spielfeld also nur 3 oder 3,5 Bildschirme groß/hoch wäre statt ca. 4.


    Wir warten also auf Antwort von LogicDeLuxe, der hier wahrscheinlich am Weitesten fortgeschritten und im Thema am Tiefsten drin ist.

  • Die Spielphysik von Boulder Dash folgt schlicht nicht den Naturgesetzen, sondern eher einem abstrakten Konzept. Realistische Sachen wie Fallbeschleunigung, Luftwiderstand, Masse oder Stoßgesetz spielen da schlicht keine Rolle. Und wie Rockford sich in der Luft halten kann, wird gar nicht erst erklärt. Und versuch z.B. mal physikalisch zu erklären, wieso Schmetterlinge zu Diamanten explodieren können. Ein Physikprofessor würde sich dabei wohl ziemlich lächerlich machen.

    So isses. DamalsTM war das halt die "Spielphysik" für uns und den Begriff darf man durchaus so im Kontext verwenden, auch wenn die "Physik" in Boulder Dash nicht der Realität entspricht und nur die simple Interaktion von beweglichen Objekten mit Nachbarfeldern dargestellt wird. Die herunterpurzelnden Felsbrocken sind heut immer noch ne Schau. :)


    p.s. Der richtige Begriff wäre Spielmechanik, aber weil da visuell Steine fallen, wird man direkt dazu verleitet, den Begriff "Physik" zu verwenden, obwohl da keine Physik ist.

    Ich finde es schon ok, von "Spielphysik" zu reden, zumal sich das ganze ja auf die Umwelt bezieht und vor allem auch auf "leblose" Objekte wie Steine und Co.


    Spielmechanik ist fuer mich eher das, was der Spieler direkt macht.

  • Mal ne laienhafte Frage: nun gibts ja seit kurzem sehr erschwingliche REU-Nachbauten, mit denen Spiele realisierbar werden, die früher nicht mal ansatzweise mit einem C64 in Verbindung gebracht wurden - Sonic, mit sehr schnell scrollender Grafik, DOOM - was ja jeder früher als absurd auf dem Cevi angesehen hätte, abgesehen von Briefmarkengroßen echten Nachbauten - KÖNNTE man die Fähigkeiten der REU/RAD eventuell nutzen, Eure Pläne ein wenig voran zu treiben? Es geht ja wohl immer wieder um einen schnellen Grafikaufbau in einer Art und Weise, die dem 64er nicht so ganz in die Wiege gelegt wurde - aber mit erweiterter Hardware vielleicht mehr denn je? Und ich habe so den Eindruck gewonnen, dass insbesondere die RAD durchaus sehr beliebt ist und sich rasant verbreitet?!?

  • Wenn man sich mal von dem Gedanken verabschiedet, einen (von der Wirkung her) hundertprozentigen Clone der Original-Engine zu entwickeln, der in der Lage wäre, die bisherigen Levels "abzuspielen" – was gäbe es dann an Optimierungs-Potential? Ich gehe jetzt mal wieder von etwas aus, von dem ich nicht genau sagen kann, was es bringen könnte (auch weil ich es schon ansprach, ohne eine konkrete Antwort darauf zu bekommen) und das ist: Verkleinerung des Spielfeldes.


    Wenn man also nicht von starren 40 x 22 = 880 Feldern ausgehen würde (die Größe scheint ja entstanden zu sein, weil man ursprünglich von einem einzelnen Screen ausging), sondern von z.B. von 32 x 25 = 800 oder 20 x 35 = 700 Felder (vielleicht sogar variabel) – würden wir damit ausreichend Rechenzeit bekommen für zusätzliche Features?


    Es mag für den einen oder anderen vielleicht "undenkbar" sein, das Spielfeld zu verkleinern aber es erlaubt eben auch neue Levels – und wer will schon immer die gleichen alten Levels spielen?


    (Und man kann es sogar so anlegen, dass kleinere Levels gar nicht "stören", wenn man mehrere kombiniert, die zwar von Rocky erreicht werden können, die aber "zellular" unabhängig wären und deshalb nicht gleichzeitig berechnet werden müssten.)

  • sondern von z.B. von 32 x 25 = 800 oder 20 x 35 = 700 Felder (vielleicht sogar variabel) – würden wir damit ausreichend Rechenzeit bekommen für zusätzliche Features?

    Der Scan würde kürzer werden, aber das ist nicht der kritische Teil. Das Scrollen und die Zeichenanimation passieren im Interrupt, und da ist die Zeit knapp bemessen.


    Tatsächlich verkleinert BD1 physikalisch das Spielfeld bei den Intermissionen auf 40x12 Felder. Zudem regelt BD1 die Geschwindigkeit lediglich dadurch, daß mit einer primitiven Schleife gedrosselt wird, dessen Dauer vom ausgewählten Level abhängt. Deswegen laufen die Intermissionen dort auch deutlich schneller, und einige Caves mit viel Bewegung zeigen deutliche Slowdowns. Ab BD2 werden statt Drosselschleife dann Interrupts gezählt, was die Geschwindigkeit deutlich gleichmäßiger macht.


    Der Cave-Scan läßt auch schon die erste und letzte Zeile aus, um etwas Zeit zu sparen, weshalb bewegliche Objekte da auch kleben bleiben, falls sie dort in eine Lücke laufen. Der Geschwindigkeitsvorteil fällt aber kaum ins Gewicht. Das wurde in 1stB auch geändert, damit man durch den Rand laufen kann.

  • Taja das Problem mit dem Spielfeld ist nicht wirklich das Problem. Das Problem sind die Aktuere im Spiel selber. Es läuft ja quasi alles gleich ab. Das habe ich auch gemerkt als ich angefangen habe BD für den Mega65 in Basic zu schreiben. Nur mit der Hilfe aus dem Forum habe ich das einigermaße hinbekommen und die 40 MHz natürlich. Und später dann durch die Optimierung des Basic-Codes von Acorn. Und für den Mega65 haben wir es auf 1x1 Char gehalten.

  • Es mag für den einen oder anderen vielleicht "undenkbar" sein, das Spielfeld zu verkleinern aber es erlaubt eben auch neue Levels – und wer will schon immer die gleichen alten Levels spielen?

    Es gibt tausende Level, die im Internet verfügbar sind und problemlos ins C64-Format konvertiert werden können. @peiselullis Version hatte beispielsweise knapp 400 Level, meine ich. Die Kompatibilität mit diesem riesigen Angebot aufzugeben, nur um ein paar graphische Verbesserungen einbauen zu können, ist ein schlechter Deal - ganz unabhängig von irgendwelchen Nostalgie-Gefühlen.


    Wenn man die Kompatibilität aufgibt, dann besser gleich ein ganz neues Spiel machen. Das kann ja dann immer noch stark an Boulder Dash angelehnt sein, aber eben auch eigene Ideen mitbringen. Ein Beispiel wäre Emerald Mine auf dem Amiga.

  • Wenn man die Kompatibilität aufgibt, dann besser gleich ein ganz neues Spiel machen. Das kann ja dann immer noch stark an Boulder Dash angelehnt sein, aber eben auch eigene Ideen mitbringen.

    Ja, genau das ist es, was ich seit einigen Posts vorschlage. Hat nur wieder "niemand" gemerkt. ;)


    Das Ziel wäre eher, ein Spiel mit einer BD-ähnlichen Mechanik (davon gibt es dutzende ohne rechtliche Beanstandung), das der C64-Darstellungsqualität und seinen Fähigkeiten schmeichelt. Und ich wäre überhaupt nicht traurig, wenn das Spielfeld anders geformt ist und es zusätzliche Gegner und Gefahren gibt.

    (ich würde dann natürlich auch Rockys Erscheinung noch ein wenig weiterentwickeln usw.)

  • Ja, genau das ist es, was ich seit einigen Posts vorschlage. Hat nur wieder "niemand" gemerkt. ;)

    Hiiier! Hiiier! *springhüpf* Ich hab's gemerkt! :3 Und fand die Optik und Idee sehr gut! Man könnte sogar Zwischenstages einbauen, wo es nur darum geht, schnell den richtigen Weg an die Oberfläche auszuknobel, und das Grundwasser steigt die ganze Zeit ... man fängt also ganz unten an. :3 Könnte die ganze Zeit Ping Pong gehen. Diamanten sammeln auf dem Weg nach unten, das Exit ganz unten benutzen, die Stage "dreht" sich und man ist ein Level weiter auf der anderen Seite dieses Exits, und hier muss man stattdessen wieder ganz schnell rauf die Diamanten in Sicherheit bringen, und dabei den Viechern ausweichen, oder fallenden Steinen. Könnte ein Beben geben, oder steigendes Wasser ... und so geht das die ganze Zeit, rein -- Flucht, rein -- Flucht, immer ein bischen schwerer. :3

  • Um mal einige Fragen hier zu beantworten.

    Mit einer REU könnte man Boulder Dash beschleunigen, so das zusätzlich das Farb-RAM voll nutzbar ist und es wäre sogar noch viel mehr Rechenzeit für die Original Engine übrig. Meine Meinung nach ist eine REU aber gar nicht notwendig, wenn man eine schnelleren Engine verwendet.


    Die Ausmaße des Spielfelds in XY sind nicht entscheiden, sondern die Gesamtanzahl der aktiven Objekte im Cave. Eine schnellere Engine könnte genug Rechenzeit für das Farb-RAM freischaufeln.


    Mit VSP und Co kann man das Scrollen nicht beschleunigen, da laufend der Bildschirmspeicher aktualisiert werden muss. Eine Speedcode-Routine könnte den Bildschirmspeicher schneller beschreiben und beim Aktualisieren kann man jedes zweite Frame auslassen.


    Für das Programmieren einer BD-Engine braucht man bestimmt kein Professor der Physik, dafür reicht ein schnöder Hauptschulabschluss aus.


    Die Engine in Assembler:

    Die Original-Engine ist eher auf Speicherplatz als auf Geschwindigkeit getrimmt. Der Atari hat effektive auch (deutlich) mehr Takt als der C64. Beim C64 läuft die Engine schon am Limit und teilweise darüber.


    Ausblick:

    In der Basic-Version für den Mega65 habe ich die Original-Engine von BD-II nachgebildet, das Verhalten der Cave ist identisch. Im Prinzip ist die Engine auch nicht so komplex wie einige hier meinen, siehe Sourcecode.


    Optimierungen der Basic-Version:

    Da das Basic selbst auf dem Mega65 extrem langsam ist, sind einige Ideen rund um die Engine entstanden. Z.B. nur alle aktiven Objekte eines Cave zu erfassen und das die Engine von unten nach oben abläuft. Leider kommt es dadurch insgesamt zu Abweichungen beim Ablauf. :org:


    Für echte BD-Fans kommt so etwas natürlich nicht in Frage und für mich auch nicht. Also müssen andere Mittel und Wege gefunden werden, wie kompletter Jumpcode, aktive passive Objektwechsel, momentan nur bei der Amöbe. Noch nicht umgesetzt aber angedacht, unmöglich erreichbare Levelbereiche überspringen.


    Es ist also durchaus möglich das Farbram mit vier weiteren Farben in vollen Umfang zu benutzen um die Optik stark aufzuwerten.


    Wer sich das Basic-Dash mal anschauen will, sollte sich einfach den Mega65 Emulator herunterladen, leider muss man sich das Romfile selbst zusammen fummeln. Bis ROM 920377 kann man einfach per Drag-and-drop das Basicfile auf dem Emulator ziehen, bei neueren Roms ist zurzeit den Umweg über ein D81 Image nötig.

  • und beim Aktualisieren kann man jedes zweite Frame auslassen.

    Machen alle BD-Engines am C64 bereits. Auch hier ist der Atari im Vorteil.

    Den Zeichensatz auf 8x16-Pixel-Zeichen aufbohren wäre wohl die Optimierungsmöglichkeit, die weiter oben schon erwähnt aber noch nicht ausprobiert wurde. Das würde Screen- und Farb-RAM praktisch halbieren, was sowohl den Cavescan-Loop, wie auch den Interrupt entlasten sollte.

  • Wenn eine REU/RAD so viel bringen würde - was spricht dann dagegen? Sonic 64 läuft auch nicht ohne - ist eben so - warum also das "originale" BD nicht aufhübschen und optimiert auf der REU/RAD laufen lassen?!?!

  • Meiner Meinung nach sollte die Grundspielmechanik schon vom Originalspiel beibehalten werden. Das ist ja genau das, was Boulder Dash ausmacht. Ansonsten wäre es ja kein Boulder Dash mehr, zumindest keines im Sinne der Fans. Erweiterungen sind natürlich erwünscht, wie es schon CLCK 3.0 oder GDash gezeigt hat. Die Design-Ideen von Retrofan finde ich sehr ansprechend, was ich auch als Erweiterung verstehe.


    Und natürlich braucht man keinen Physikabschluss, ich wollte nur aufzeigen, dass man oft erst mit fundierten Kenntnissen überhaupt auf die Idee eines solchen Spielablaufs kommt. Das ist aber in jedem Beruf so.


    Ein ansprechendes Boulder Dash für den Mega65 wäre schon was. Vorallem mit Höhlen-Editor, um das Ding am Laufen zu halten, sonst geht es irgendwann unter. Es gibt leider noch immer viel zu wenig ansprechende Software für den Mega65.

  • Für den Mega65 wurde ja letztens ein Basic Micro-Compiler vorgestellt.
    Den könnte man definitiv nutzen um einzelne Routinen schneller zu machen.