Hello, Guest the thread was called29k times and contains 230 replays

last post from Retrofan at the

Boulder Dash: C64-typisch vs. Atari 800 Optik

  • Jetzt müsssen wir hoffen, das ein Programmierer Lust auf sowas hat.

    Wenn ich mal dazu komme, wird es wohl erstmal ein Leveleditor für meine XDC-Engine sein. Danach wären weitere Experimente mit alternativen Darstellungsroutinen und REU-Unterstützung sicher denkbar. Allerdings ist meine Routine nicht so REU-tauglich wie die Originale, da ich keinen virtuellen Screen verwende. Während des Cavescans zeichne ich gar nichts, wodurch er sehr schnell ist. Im Interrupt übersetze ich dann die Caveelemente in jeweils einzelne Char-Bytes, und diese werden dann später in 2x2 Chars direkt in den Screen geschrieben, und optional auch ins Farb-RAM übersetzt, wenn ein Turbo genutzt wird.


    Den Ansatz mit 8x16-Zeichen finde ich dennoch interessant, auch wenn ich dafür erstmal wieder einen virtuellen Screen wie in der Original-Engine schreiben müßte. Ein weiterer Vorteil wäre, daß man keine Sonderbehandlung für Zeilenübergänge mehr bräuchte, wie es in 1stB und CrLi der Fall ist und in BD1, BD2 und PLCK gar nicht erst vorgesehen ist. Kenner wissen sicher, daß es zu Grafikfehlern führt, wenn man trotzdem den seitlichen Rand offen läßt und Elemente da durch wandern läßt.


    Mit einer ausgeklügelten REU-Unterstützung sollten auch variable Cavegrößen und Endlosscrollen möglich sein. Der Cave-Vorrat kann dann natürlich auch in die REU und man hätte wieder etwas mehr Platz für andere Sachen.

  • Obwohl ich für Boulder Dash trotz der engen Verwandtschaft mit der Atari-Version eine Lanze brechen muß: graphisch ist das Spiel top am C64, schon alleine für den Release 1984. Es gibt nicht viele angenehm anzusehende Spiele für den C64, manchmal denke ich mir, dass es dür C64 Verhältnisse außergewöhnlich ist. Boulder Dash hat einen ganz eigenen Charm!

  • Eine REU sollte kein Hindernis sein. Ich verstehe schon seit Jahren nicht warum sich die C64 Community global dagegen wehrt dem C64 Flügelunterstützung bei dem Games zugeben.


    Wenn es für den Coder dann ein leichteres ist etwas umzusetzen, dann gerne.

    Darm geht es ja hier nicht. Es gibt halt Entwickler, die nutzen solche Erweiterungen, was auch gut ist, denn sonst hätten die ja keinen Sinn. Aber es gibt halt auch die Mentalität aus einem im original Zustand befindlichen 64er ein Maximum herauszuholen und tlw. auch zu zeigen, was seinerzeit damit möglich gewesen wäre.


    Das hat nichts mit sich gegen etwas wehren zu tun.

  • Quote

    VSP brauchen wir hier eher nicht, da bei Boulder Dash sowieso der ganze Screen für jedes Frame neu erstellt wird. Es wird ja nicht nur gescrollt, sondern es können jederzeit beliebige Veränderungen im virtuellen Screen stattfinden.

    Die Idee wäre ja, den Screen ÜBERHAUPT nicht zu kopieren, sondern den Logik-Screen so aufzubauen, dass er direkt dargestellt werden kann ! Das ginge dann nur mit VSP ...

  • Boulder Dash hat einen ganz eigenen Charm!

    Charme hat es, dagegen habe ich auch nie etwas gesagt. Gerade Rockford ist sehr niedlich und unique geworden. Zudem ist BD ein eher frühes Spiel, gerade mal 2 Jahre nach Hardware-Release entstanden/portiert. Trotzdem ist die Sprite-lose, nur 4-farbige Darstellung halt nicht das, was man sich (zumindest nach 1984) vom C64 erhofft. Er kann grafisch eigentlich mehr, auch wenn hier die Farbmöglichkeiten stark durch die knappe Rechenzeit eingeschränkt wird (was ich anfangs nicht so sehr erwartet hatte). BD ist halt auf dem Atari entstanden, was man ihm auch ansieht. Mir ging es von Anfang an darum, herauszufinden, was auf dem C64 möglich/wahrscheinlich gewesen wäre, wenn BD eine originäre C64-Entwicklung gewesen wäre und keine 1:1-Portierung* von einer Hardware mit anderen Eigenschaften.


    Die Portierung war sogar verlustbehaftet, weil (wie bei einem anderen Atari-Port: Dropzone) die 5. Farbe fehlt – in beiden Fällen im Endeffekt Performance-bedingt (Auslassung des ColorRAMs) – und man sie quasi ersatzlos gestrichen hat.

  • Die Portierung war sogar verlustbehaftet, weil (wie bei einem anderen Atari-Port: Dropzone) eine 5. Farbe fehlt – in beiden Fällen im Endeffekt Performance-bedingt (Auslassung des ColorRAMs) – und man sie quasi ersatzlos gestrichen hat.

    Der Atari hat ja auch kein Color-RAM. Der verwendet einen Zeichensatz mit 128 Zeichen, und das oberste Bit wählt zwischen zwei Vordergrundfarben, was bei Boulder Dash dazu genutzt wird, Amöbe oder Schleim farblich vom Rest zu unterscheiden. Beim C64 ist der Extended-Color-Modus von der Idee ähnlich, aber den gibt es leider nicht als Multicolor-Variante.

  • Der Atari hat ja auch kein Color-RAM.

    Habe ich ja auch nicht gesagt. Nur beim C64 müsste man das ColorRAM nutzen, um mehr als 4 feste MC-Farben zu verwenden. Beim Atari ist die 5. Farbe quasi kostenlos, was die Performance beim Scrollen angeht, beim C64 halt nicht. Aber wenn man das ColorRAM doch nutzt (wie bei meinen BD-Mockups), dann hat man halt gleich mehr als nur EINE weitere Farbe.

  • Wenn du dafür mal Zeit für uns verwendest, finde idh das klasse von von dir. Bin gespannt auf die Dinge die noch folgen für den C64-BD was wäre wenn...gewesen.


    Aber Leute ich möchte nicht wieder einen Streit beschören ob man nun eine REU verwenden darf oder nicht. Denn sonst wäre es kein C64 - Game. Als ich angefangen habe am C64´er zu programmieren war ich nicht wirklich glücklich über die nicht vorhanden Grafikbefehle oder Soundbefehle. Da war damals für mich der Atari XL 600 schon besser in der Befehlsstruktur. Aber mit der Zeit hat es mich doch gefuchst wie manches geht, durch die viele Demos die man hatte. Aber Litaratur war aber auch mangelware. Und wenn man in keine Gruppe war war es noch viel schwieriger. Aber so habe ich mit der Zeit so einiges Erfahren wie Struktur im C64´er war. Muss aber auch zugeben das ich bis heute nicht alles Verstanden habe wie mancher Effekt denn nur wirklich funzt. Aber ich schweife vom Thema ab.


    Also ich freue mich wenn da mal was kommen könnte auf jeden Fall schon im voraus.

  • Ich habe mir überlegt, ob ich den Editor für XDC evtl. doch am C64 mache und dafür dann die REU nutze. In erster Linie soll das dazu dienen, daß man den kompletten Cavesatz in editierbarer Form vorhalten kann, um einen Komfort zu erreichen, der in Richtung GDash geht. Die fertigen Spiele bleiben natürlich weiterhin auf einem nackten C64 spielbar.