Aber bei Boulder Dash gehoert fuer mich halt eher dieses dumpfe Geblubber dazu
Du meinst jetzt aber nicht die Beiträge in diesem Thread...? 
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
- enthusi
- Erledigt
-
-
Aber bei Boulder Dash gehoert fuer mich halt eher dieses dumpfe Geblubber dazu
Du meinst jetzt aber nicht die Beiträge in diesem Thread...?
Das muss ich jetzt aber nicht persönlich nehmen???
-
Cool, Danke!! Die GBA-Variante ist aber aufbereitet und nachbearbeitet, oder???
Mann! Einmal so Piano spielen können! Ist schon der Hammer.
Die GBA Variante ist ziemlich sicher komplett neu "Sequenzt" worden :), meiner Meinung nach auch ziemlich gekonnt!
Klare, helle und härtere Sounds, vs weichere, geschmeidige Klänge -- ich mag da schon das ganze Spektrum, aber es wie bei euch sicher auch, einfach von Song zu Song unterschiedlich wo man hängen bleibt. Ich könnte mir z.B. den Soundtrack von Last Ninja 2 nicht ohne diese abgedroschene Metal-artige Schrabbelei vorstellen, das muss kesseln.
-
Die C64 Version klingt in meinen Ohren am angenehmsten.
-
Gameboy Advance
Die kannte ich noch gar nicht. Finde ich richtig cool. Davon sollte es mal eine SID-Version geben.
Atari 2600
Sogar zweistimmig. Hatte Pac Man nicht einen Soundchip im Modul, um überhaupt zweistimmig spielen zu können? Wie hat man das hier gelöst?
Die C64er Version mag ich auch, garkeine Frage, aber sie klingt im Vergleich viel zu soft
Einige Fanspiele spielen die Melodie auch mit Dreieck oder seltener mit Rauschen ab. Und Marathon Dash hat sich auch mal an eine Rechteck-Version gewagt.
-
Stimmt, den Track der GBA version habe ich heute bestimmt knapp 10 mal nacheinander dudeln lassen weil sie wirklich gut gemacht ist! Eine SID version davon wär schon was echt tolles!
Alternative versionen vom BD C64 track muss ich mal suchen und durchhören.
Die Atari 2600er version ist auch vom eigentlichen Spiel her eine eindrucksvolle Umsetzung, wenn man bedenkt worauf sie läuft!
Gibt inzwischen auch ebenfalls eine schicke version für das alte Intellivision. -
Da wir gerade bei Soundtracks sind - den genialsten habe ich bisher weder bei nem Spiel, noch bei ner Demo gehört, aber den könnte ich glatt 100x hintereinander hören - wäre echt mal interessant, den auf anderen Rechnern portiert anzuhören - oder aufbereitet...
-
Das Berechnen des ganzen Spielfeldes (auch außerhalb des sichtbaren Bereichs) muss ja jedes System durchführen, egal ob Atari oder Commodore. Da hat der C64 höchstens dadurch Nachteile, dass die CPU langsamer getaktet ist als bei vielen anderen Rechnern der Zeit. Was ihn aber, so wie ich das verstanden habe, gegenüber dem XL/XE wirklich ins Hintertreffen geraten lässt, ist die fehlende Display-List, wodurch immer umständlich das sichtbare "Fenster" in den Darstellungsbereich des VICs kopiert werden muss. Das hat doch vor allem damit zu tun, dass der Level doppelt so BREIT ist, wie der sichtbare Bereich (und man am C64 nicht einfach Ausschnitte definieren kann), oder?
Hi Leute ich muss doch nochmal das Thema aufgreifen.
Wäre es denn möglich das man das Spielfeld in einer REU ablegt so wie bei Sonic. Das ist mir nämlich gleich durch den Kopf gegangen als ich Sonic gesehen und gespielt habe. Zumal ich noch ein Interview gesehen habe das man damit sehr schnell seine kann. Hört mal ab der 52 Minute zu
[Externes Medium: https://www.youtube.com/watch?v=S0j7yxP7vAI&t=32856s]Könnte man damit eventuell was anfagen, wenn denn ein Coder Lust dazu hätte.
Fände es schade wenn Retrofan seine Grafik untergehen würde.
Gruß Drachen
-
Wäre es denn möglich das man das Spielfeld in einer REU ablegt so wie bei Sonic.
Das würde implizieren, dass dass die Umsetzung ausschließlich mit einer REU gespielt werden kann.
Ich lehne mich mal aus dem Fenster, dass das nicht das Ziel von Retrofan ist.
Zudem müssen wir hier ja auch die aktuellen Lizenzinhaber berücksichtigen. Boulder Dash ist ja nicht frei.
-
Und man müsste ja beim Berechnen ständig die Speicherbereiche griffbereit haben, also DMA-Transfers machen. Ist das nicht zu umständlich dafür? Zumindest stelle ich mir das vor.
-
Ich lehne mich mal aus dem Fenster, dass das nicht das Ziel von Retrofan ist.
Nun ja, meines Erachtens wäre das eine Sache, die ein Programmierer entscheiden sollte. Wenn es nicht anders geht, warum nicht mit REU?
Andererseits bin ich ja immer für LowTec zu haben, also so wenig Hardware wie nötig, um etwas zum Laufen zu bekommen. Und dann ist die Idee des Threads ja, dass Boulder Dash so aussieht und funktioniert, wie es das tut, daran liegt, dass es ursprünglich ein Atari-Spiel war. Und auf diesem Gedanken basierend war dann die Überlegung, wie Boulder Dash als typisches C64-Spiel ausgesehen hätte. Ich als Grafiker bin da natürlich erst einmal auf die Optik eingegangen. Ich hatte dann aber gegen Thread-Ende (nachdem mir erklärt wurde, wo die Herausforderungen liegen) die Überlegung angestellt, dass ein C64-Entwickler wahrscheinlich diesen Display-List-freundlichen Level-Aufbau anders angegangen wäre (da der C64- keine Display-List kennt und Bildschirminhalte nicht so frei (horizontal) verschieben kann). Der einfachste Weg (auf dem C64) wäre wohl gewesen, ausschließlich in die Tiefe/Höhe zu gehen und das seitliche Verschieben einfach wegzulassen. Gerade bei so einem Grabe-Spiel würde es doch durchaus Sinn machen eher in die Tiefe zu gehen, zumal man sich da bei oberen "Fehlern" evtl. unten schnell etwas kaputt machen kann. Ich fände das fast noch spannender als die bisherige Aufteilung.
Klar, das wäre dann natürlich kein 1:1 (Atari-) Boulder Dash mehr. Sondern eher ein zweiter Teil oder Rockfords (C64-typischer) Bruder oder Sohn.
Also, ich bin immer dafür, Sachen umzusetzen. Wenn man eher den klassischen Aufbau möchte und die C64-Ressourcen zu knapp bemessen sind, um meine (anscheinend) aufwendigeren Grafiken in ein Spiel zu gießen – dann gerne mit REU, wenn das die Problemlösung wäre. Aber ich fände die Lösung mit der anderen Aufteilung halt auch attraktiv, auch weil sich dadurch das Spielgefühl (bei gleicher Mechanik) etwas ändern könnte. Und wenn das dann "Rocky – the Story never ends ..." wäre: umso besser bzgl. der Rechte-Frage.
-
Hi
Das mit dem rauf und runter wäre auch nicht schlecht, wäre mal was anderes und auch sehr spannend.
Naja nütz ja leider alles nichts, wenn man dafür keinen Coder findet, wo das angehen würde.
Aber wie gesagt das mit der REU war ja nur so eine spontane Idee als ich Sonic gesehen habe.
Denn wer hätte vor Weihnachten 2021 gedacht das man Sonic auf den C64 spielen könnte.
Aber vielen dank für eure Antworten.
-
Andererseits bin ich ja immer für LowTec zu haben, also so wenig Hardware wie nötig, um etwas zum Laufen zu bekommen.
Eben, deshalb meine Anmerkung dazu.
Teile Deine Meinung dazu übrigens auch, nicht dass Du mich da falsch verstehst. Bei Sonic ist es einfach etwas anders gewesen aus meiner Sicht. Auf einem gewöhnlichen C64 wären die ganzen Animationen gar nicht möglich und Sonic wäre nicht Sonic gewesen. Hier verhält es sich aber etwas anders. Es ist technisch ja möglich, es aufzuwerten, auch ohne zusätzliche Hardware.
EDIT: Was mich aber auch interessieren würde ist, ob man Deine angepassten Zeichensätze nicht testweise mal importieren kann?
Dann müsste das doch eigentlich spielbar sein mit Deinen Mockups, oder?
-
Dann müsste das doch eigentlich spielbar sein mit Deinen Mockups, oder?
Nein, das geht leider nicht, da mein Charset davon ausgeht, dass das ColorRAM mitverschoben wird – und das ist beim Original nicht der Fall. Und der Protagonist ist bei mir nicht mehr Char-basiert, sondern mit Sprites umgesetzt (wenn auch weiterhin mit Tile-weiten Sprüngen, wie hier zu erkennen).
-
Und man müsste ja beim Berechnen ständig die Speicherbereiche griffbereit haben, also DMA-Transfers machen. Ist das nicht zu umständlich dafür? Zumindest stelle ich mir das vor.
Dann machen wir eben ein Chameleon-Exklusiv. Dort kann man direkt beliebige Speicherbereiche aus den 32MB in den 6510-Adressraum einblenden, inklusive Speicher aus der REU.
Wäre natürlich die Frage, ob das Geschwindigkeitsvorteile bringt, wo man ohnehin schon einen Turbo am Start hat. -
Wäre natürlich die Frage, ob das Geschwindigkeitsvorteile bringt, wo man ohnehin schon einen Turbo am Start hat.
Och, auch das TC64 bekommen wir noch in die Knie gezwungen. Wie wäre es mit einem riesigen Würfel, in dem die "Physik"-Berechnungen stattfinden müssen?
-
Man kann die Zeilenzahl von dem Charset mit ein paar Tricks auf 8x16 hochstellen. Habe ich in dieser Demo gemacht, und zwar fast am Ende der letzten Seite ("Profis machen das so"). Als "Dreckeffekt" bekommt man dann 80 Bytes Differenz zwischen diesen Zeilen, daher kann man mit VSP, ohne zu kopieren, von links nach rechts scrollen (habe ich in der Demo auch gemacht) . Mit "line-crunching" könnte man dann ohne zu kopieren auch in Y Richtung scrollen (hab ich in der Demo NICHT gemacht
) .Dann könnte man, ohne zu kopieren, das Videoram über den ganzen Screen scrollen.
Farberam müsste man dann noch umkopieren, aber nur 500 Bytes pro Screen-Durchlauf. Farben im Farbram wären dann aber nur im 8x16 und nicht im 8x8 Raster veränderbar.
-
Wo die REU auf jeden Fall was bei Boulder Dash bringt, ist der animierte Zeichensatz.
Aber auch beim Scrollen dürfte die REU schon was bringen. Die Originalengine schreibt für alle sichtbaren Änderungen jeweils 4 Char-Bytes pro Element in den virtuellen Screen. Der Atari zeichnet per Displaylist direkt einen Ausschnitt aus diesen virtuellen Screen, während das beim C64 komplett per Software umgesetzt ist und den größten Teil im Interrupt ausmacht. Mit REU müßte man nur einmal die Anfangsposition im virtuellen Screen ausrechnen und dann in 24 Transfers jeweils 40 Bytes übertragen und dazwischen 40 Bytes überspringen. Anschließend kann der so generierte Bildausschnitt in einem Rutsch in das Screen-RAM zurück transferiert werden. Die kleinste REU wäre für diese Aufgabe schon mehr als genug. Und das Problem mit dem nicht vorhandenen Direktzugriff gibt es bei dieser Vorgehensweise auch nicht.
Man kann die Zeilenzahl von dem Charset mit ein paar Tricks auf 8x16 hochstellen.
Hatte ich auch schonmal dran gedacht. Vorteil wäre auf jeden Fall, daß man nur halb soviel umkopieren müßte und die gewonnene Zeit für das Beschreiben des Farb-RAMs genutzt werden könnte. So eine Routine wäre hier ganz ohne Sprites wohl auch nicht all zu kompliziert umzusetzen.
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.
-
Farberam müsste man dann noch umkopieren, aber nur 500 Bytes pro Screen-Durchlauf. Farben im Farbram wären dann aber nur im 8x16 und nicht im 8x8 Raster veränderbar.
Wir hatten das ja hier schon besprochen, wenn ich mich recht entsinne. Es wäre auch nicht dramatisch, meine Grafiken daran anzupassen. Ein bisschen Verlust halt – aber noch verschmerzbar. Aber auf diesen Tipp hin hat ja leider auch niemand Lust bekommen, die Sache von der Programmierung her anzugehen. Daher sah ich das erstmal als "abgehakt" an. Dann kam halt meine Idee mit dem vertikalen Spielfeld, um es C64-tauglicher zu machen – aber auch das schien niemanden zu reizen. Jetzt wäre halt REU-Verwendung ein möglicher Ansatz, der vielleicht einen Programmierer interessiert, der schon immer mal was mit der REU machen wollte und "notfalls" dafür einen BD-Clone umsetzen würde.
So eine Routine wäre hier ganz ohne Sprites wohl auch nicht all zu kompliziert umzusetzen.
Allerdings war in meinen Mockups die Spielfigur in Sprites umgesetzt. Alleine schon, um farblich flexibler zu sein – aber auch wegen der Animationen.
-
Das sind alles wunderbare Ansätze.
Jetzt müsssen wir hoffen, das ein Programmierer Lust auf sowas hat.
