Interessant, aber wahrscheinlich gerade darum ist Boulder Dash ein wirklich einzigartiges Spiel!
Boulder Dash: C64-typisch vs. Atari 800 Optik
-
enthusi -
12. März 2018 um 09:39 -
Erledigt
Es gibt 300 Antworten in diesem Thema, welches 62.594 mal aufgerufen wurde. Der letzte Beitrag (
-
-
okay, bei Horizontalscrollern scheint der 64er "im Vorteil" zu sein - richtig?
Beim Scrolling ist der C64 praktisch nie im Vorteil, denn genau das ist seine größte Schwäche. Man kann beim VIC weder Screenstart noch Zeilenoffset frei wählen. Wenn man dann auch noch einen virtuellen Screen benötigt, wie bei Boulder Dash, geht das ganz besonders auf die CPU. Das Farb-RAM ist dann nochmal eine zusätzliche Anforderung, und gibt es beim Atari auch nicht.
Der Grafikaufbau bei Boulder Dash ist prinzipiell auf beiden Systemen sehr ähnlich. Aber beim Atari kann man mit dem oberen Char-Bit zwischen zwei Vordergrundfarben umschalten, womit die stets grüne Amöbe oder blauer Schleim umgesetzt wurde. Das ist wohl auch der Grund, warum man diese Elemente im offiziellen Construktion Kit nicht gleichzeitig verwenden kann. Andersfarbige Amöben und Schleims waren wohl tabu.
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
Dr.Zero/CTX hat mal eine SID-Version gebaut, was ansich nicht weiter kompliziert ist, da der Code vom C64 unangetastet vorhanden ist. Leider ist damals sein Plus/4 verreckt, bevor die Scrollroutine fertig war, und weil sie auf einem damaligen Emulator lief, hatten wir das so veröffentlicht. Wenn das ein Plus/4-Spezialist reparieren kann, immer gerne.
Bitte melde dich an, um diesen Link zu sehen.
-
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.
Interessant!! Danke!
Das mit den 760 Zeichen und der schnelleren Bearbeitung im Atari ist klar - aber dass alle Zeichen permanent in 4 Richtungen abgefragt werden müssen, ist doch eigentlich die zeitaufwändigste Variante?! Auf diese Weise würde man natürlich immer ALLES korrekt berechnet haben, aber vieles davon kann man sich doch sparen?! Alles, was nicht in unmittelbarer Nähe von Rockford ist, braucht nicht auf Kollision getestet werden, Objekte, die beweglich sind müssen jeweils berechnet werden, alles was eingeschlossen ist, bleibt im vorherigen Status - ich vermute mal, so wird das bei Spielen üblicherweise gemacht? So würde ich jedenfalls - wenn ich programmieren könnte, an die Sache heran gehen - bestimmte Dinge, wie die Amöben überschreiben sowieso alles, damit ändert sich der Zustand des "Zeichens" - aber im Moment - okay, ich weiß, so simpel ist es natürlich nicht - erscheint es mir, als würde da weitaus mehr Aufwand betrieben werden, als von Nöten ist?!? Klar, wenn 100 Schmetterrlinge im Bild sind, wird es sicher wirklich anspruchsvoll, aber ist das nicht eh nur in Leveln der Fall, wo das Bild nicht scrollt? Da sollte dann der virtuelle Screen weg fallen können?!?
Wie wird es denn beim plus/4 gemacht? Der müsste ja noch mehr "zu kämpfen" haben, weil da ja wirklich ALLES der TED machen muss...?!?
Aber erstaunlicherweise sieht es im Video da recht flott aus. -
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
Dr.Zero/CTX hat mal eine SID-Version gebaut, was ansich nicht weiter kompliziert ist, da der Code vom C64 unangetastet vorhanden ist. Leider ist damals sein Plus/4 verreckt, bevor die Scrollroutine fertig war, und weil sie auf einem damaligen Emulator lief, hatten wir das so veröffentlicht. Wenn das ein Plus/4-Spezialist reparieren kann, immer gerne.
Bitte melde dich an, um diesen Link zu sehen.
SID-Version für den plus/4? Hmm, dann bräuchte man ja auch eine entsprechende Erweiterung - Eigentlich braucht es ja gar keinen SID, hat der Atari ja auch nicht - und die Lauf- & Aufprallgeräusche sollte der Rauschgenerator des plus/4 ja eigentlich auch schaffen - oder zumindest so ähnlich... Aber Totenstille im Spiel, bis auf das doch etwas nervige Start-Pfeifen ist irgendwie demotivierend... da fehlt einfach was...
Da stimme ich Dir völlig zu - wenn ja jemand nochmal programmiertechnisch Hand anlegen würde, dann könnte das Spiel nochmal enorm aufgewertet werden...
-
Ich erkenne bis auf Farben und Sound besonderen Unterschiede zwischen XL, C64 und CPC Version.

Ist Dir da ein Wort abhanden gekommen?


Ups.

Nachreich >>> keine
-
Bitte melde dich an, um diesen Link zu sehen.
-
Bitte melde dich an, um diesen Link zu sehen.
Doch ist es, aber halt keine offizielle Version. Boulder Dash gibt es offiziell gar nicht für den Plus/4. Wurde vermutlich schon recht früh konvertiert, ein Hintergrund dazu ist eine reine Vermutung. Auf der Basis wurden aber 14 verschiedene Versionen rausgehauen.
-
DIESE sieht aber verglichen mit anderen richtig gut aus...
-
Alles anzeigen
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.
Interessant!! Danke!
Das mit den 760 Zeichen und der schnelleren Bearbeitung im Atari ist klar - aber dass alle Zeichen permanent in 4 Richtungen abgefragt werden müssen, ist doch eigentlich die zeitaufwändigste Variante?! Auf diese Weise würde man natürlich immer ALLES korrekt berechnet haben, aber vieles davon kann man sich doch sparen?! Alles, was nicht in unmittelbarer Nähe von Rockford ist, braucht nicht auf Kollision getestet werden, Objekte, die beweglich sind müssen jeweils berechnet werden, alles was eingeschlossen ist, bleibt im vorherigen Status - ich vermute mal, so wird das bei Spielen üblicherweise gemacht? So würde ich jedenfalls - wenn ich programmieren könnte, an die Sache heran gehen - bestimmte Dinge, wie die Amöben überschreiben sowieso alles, damit ändert sich der Zustand des "Zeichens" - aber im Moment - okay, ich weiß, so simpel ist es natürlich nicht - erscheint es mir, als würde da weitaus mehr Aufwand betrieben werden, als von Nöten ist?!? Klar, wenn 100 Schmetterrlinge im Bild sind, wird es sicher wirklich anspruchsvoll, aber ist das nicht eh nur in Leveln der Fall, wo das Bild nicht scrollt? Da sollte dann der virtuelle Screen weg fallen können?!?
Wie wird es denn beim plus/4 gemacht? Der müsste ja noch mehr "zu kämpfen" haben, weil da ja wirklich ALLES der TED machen muss...?!?
Aber erstaunlicherweise sieht es im Video da recht flott aus.Naja man muss zumindest alle Elemente einmal kurz betrachten und dann entscheiden, was passieren soll. Wenn es ein "Sand"-Element ist, passiert natuerlich nichts weiter. Wenn es ein Stein ist, muss geprueft werden, ob drunter ein freies Feld ist, dann muss dieser nach unten fallen. Wenn es ein Gegner ist, muessen alle 4 Richtungen geprueft werden, usw. Also man muss durchaus jedes Element einmal betrachten, damit die Physik funktioniert. Aber man muss nicht fuer jedes Element alle 4 Richtungen abfragen, das hast Du glaube ich etwas falsch verstanden.
-
Nee, hatte ich auch nicht so verstanden, dass man für jedes Element alle 4 Richtungen abfragen muss - aber man kann das ganze doch sicher optimieren - gleiche Elemente - gleiche Abfragen - gleiche Routine?
Das mit dem Betrachten müssen würde ich in meiner Vorstellung über eine Tabelle machen - X-Spalten & Y-Zeilen und die Zustände stehen als Wert darin - Wert 0 - Element muss nicht neu berechnet werden - Element > 0 - Element betrachten - Wert des Elements = Art der Betrachtung... bspw. 1 - nur links Betrachtung nötig, 2 - nur oben, 3 - nur rechts, 4 - nur unten - so könnte man alle möglichen Richtungen abdecken... würde das nicht Zeit sparen?
Ist vermutlich laienhaft, so zu denken.



-
Also ohne jetzt genau die Details von Boulder Dash zu kennen, aber mit der Vorstellung wie ich vorgehen wuerde, und auch davon ausgehe, dass das ungefaehr so ablaeuft:
Das Level IST im Grunde eine solche Tabelle. Nur steht da nicht drin, ob das nochmal betrachtet werden soll oder nicht, sondern es steht einfach die Art des Elements drin. Zum Beispiel 0 = Leer, 1 = Sand, 2 = Stein, 3 = Mauer, 4 = Diamant, 5 = Gegner A, 6 = Gegner B, 7 = Rockford.
Nun MUSS Dein Code sich alle Felder einmal anschauen - das muss er aber bei Dir ja auch. Er muss ueber alle Felder einmal wandern und schauen was zu tun ist. Nun schaut er eben, ist es ein leeres Feld (also 0)? Dann weiter zum naechsten (nichts passiert). Ist es ein Stueck Sand? Dann weiter zum naechsten (nichts passiert). Ist es ein Stein? Wenn ja, dann schaue was sich unterhalb befindet (oder auch seitlich, denn die Steine werden ja auch teilweise davon beeinflusst) und entscheide, ob er 1 Feld nach unten fallen muss. Ist es ein Diamant? Selbiges wie beim Stein, nur anderes Geraeusch. Ist es ein Gegner? Wenn ja, dann schau die umliegenden Steine an um zu entscheiden wohin er muss. Ist es Rockford? Wenn ja, dann schau in welche Richtung der Spieler sich bewegen moechte und schau ob er da hin kann, ob er einen Stein schiebt, ob er einen Diamant sammelt, ob er Sand entfernt, und tu das.
Im Grunde bleibt Dir also nichts anderes uebrig, aber fuer die "einfachen Faelle" (leer oder Sand) passiert ja nichts weiter als dass einfach direkt das naechste Element angeschaut werden muss. Und das waere bei Deiner Idee ja auch der Fall. Nur dass Deine noch zusaetzlichen Verwaltungsaufwand benoetigen wuerde, weil Du noch zusaetzliche Eigenschaften speichern moechtest (ob man nochmal betrachten muss usw). Aber das ist gar nicht notwendig, weil jedes Element sowieso betrachtet wird.
-
Wie wird es denn beim plus/4 gemacht? Der müsste ja noch mehr "zu kämpfen" haben, weil da ja wirklich ALLES der TED machen muss...?!?
Aber erstaunlicherweise sieht es im Video da recht flott aus.Der C64 hat hier keinerlei Vorteile, da ja keine Sprites verwendet werden und alles die CPU berechnen muss. Der C16/Plus4 läuft ja mit rund 1,8 MHz, der sollte bei der Art von Spiel deutlich flinker sein.
-
ZeHa - ja, klingt logisch. Hast gewonnen

Wie wird es denn beim plus/4 gemacht? Der müsste ja noch mehr "zu kämpfen" haben, weil da ja wirklich ALLES der TED machen muss...?!?
Aber erstaunlicherweise sieht es im Video da recht flott aus.Der C64 hat hier keinerlei Vorteile, da ja keine Sprites verwendet werden und alles die CPU berechnen muss. Der C16/Plus4 läuft ja mit rund 1,8 MHz, der sollte bei der Art von Spiel deutlich flinker sein.
Naja, die höhere Frequenz hat er aber nur zu 50% - ich glaube mich zu erinnern, dass er die quasi immer nur in der "Austastlücke" hatte...
Moment...
Neben der CPU kann auch der Spezialbaustein TED direkt auf den Arbeitsspeicher und die Eingabe-/Ausgabegeräte zugreifen (englisch direct memory access, DMA), beispielsweise um das anzuzeigende Bild aus Videodaten zu erzeugen. Dabei geht das System in den Shared-Bus-Modus über, in dem die Speicherzugriffe beider Bausteine in ständigem Wechsel erfolgen. Für die CPU sind dabei nur bei geradzahligen und für den TED nur bei ungeradzahligen Taktzahlen Operationen möglich. Dies entspricht effektiv einer Halbierung des CPU-Taktes auf 884 kHz bzw. 894 kHz. Hat der TED keine weiteren Bilddaten zu bearbeiten, d. h. während horizontaler und vertikaler Bitte melde dich an, um diesen Link zu sehen. sowie bei gelöschtem Bildschirm, werden – bis auf wenige Ausnahmen – wieder sämtliche Takte für die CPU freigegeben.So gesehen ist die CPU eigentlich noch langsamer, als im C64...


-
Ich meine mal gelesen zu haben, dass durch die gemeinsame Nutzung des Busses die effektive Taktrate der CPU bei etwa 1,2 MHz gelegen hätte, da der TED nicht alle "seine" Takte benötigt. Aber ob das so stimmt...

-
So gesehen ist die CPU eigentlich noch langsamer, als im C64...


Der zitierte Absatz erklärt doch, dass das eben nicht der Fall ist!?
In beiden Systemen teilen sich CPU und Videochip den Bus - jeder bekommt erstmal die Hälfte der RAM-Zyklen.
Im C64 kann der VIC dem Prozessor Zyklen klauen, um z.B. Screencodes und Spritedaten zu lesen.
Im C16/+4 kann der TED das ebenfalls, nämlich um Screencodes und Farbbytes zu lesen.
Außerhalb des Bildschirmfensters kann der TED aber seine ungenutzten Zyklen dem Prozessor zur Verfügung stellen, und genau das macht der VIC im C64 eben nicht.
-
naja, in der Beschreibung oben steht ja was von 884 / 894 kHz - in der Austastlücke hat die CPU dann ca. 1,7 MHz
da muss dann alles schnell berechnet werden, was beim Zeichnen wieder drauf geht...
Ist die Frage dann, ob die Rechenzeit nicht mehr für den Sound ausreicht?!?
-
Auf diese Weise würde man natürlich immer ALLES korrekt berechnet haben, aber vieles davon kann man sich doch sparen?! Alles, was nicht in unmittelbarer Nähe von Rockford ist, braucht nicht auf Kollision getestet werden
Das wäre dann aber keine Boulder Dash-Engine mehr. Das spezielle an Boulder Dash ist doch gerade, daß die Physik in der gesamten Höhle kontinuierlich berechnet wird. So kann man z.B. auf Schmetterlinge warten, die am anderen Ende rumschwierren, etc.
Objekte, die beweglich sind müssen jeweils berechnet werden, alles was eingeschlossen ist, bleibt im vorherigen Status
So ist es ja auch. Die Berechnung ist unter anderem die Feststellung, ob etwas bewegt werden muß. Häufig ist das nicht der Fall, und der Scan kann mit dem nächsten Feld weiter machen.
Welche Version ist DAS dann aber?!?!? Ein Fake? Gar nicht plus/4?
Das ist der Port der BD1-Engine. Grausig schiefe Musik und kein vertikales Scrolling. Darauf basiert auch Deluxe Caves mit dem fehlgeschlagenen Versuch, die Scrollroutine zu vervollständigen.
Von der PLCK-Engine gibt es auch einen Plus/4-Port. Wie dort der Sound war, weiß ich nicht mehr, aber das Scrolling funktionierte dort immerhin.
aber man kann das ganze doch sicher optimieren - gleiche Elemente - gleiche Abfragen - gleiche Routine?
Genauso ist es auch. Das Element dient als Index auf eine Code-Zeiger-Tabelle. Steht dort 0, wird nichts gemacht (z.B. bei Erde oder Mauern). Ansonsten wird der dortige Code ausgeführt.
Weniger optimiert ist da die Effekt-Tabelle, die den Bewegtzustand zurücksetzt und gleichzeitig Explosionen durchlaufen läßt. In XDC nutze ich dafür einfach das oberste Bit.
Die Physik braucht aber ohnehin nur einen kleinen Bruchteil der Rechenzeit, so daß sich hier die Optimierungen in Grenzen halten. Auffällig langsam wird es eigentlich nur, wenn man übertrieben viele Diamanten, Steine, Glühwürmchen oder Schmetterlinge in der Höhle hat, wie das Dr. Watson in seinem Boulder Dash 4 gerne gemacht hat. Diese Extremfälle laufen in XDC tatsächlich deutlich schneller.
-
Was haltet ihr von nem kleinen Community-Projekt? Ein kleiner Boulder Dash Klon, vielleicht sogar ohne Scrolling, einfach nur um das Prinzip zu verdeutlichen? Vielleicht gar in BASIC?
Soweit ich weiss wurde das Original sogar erst auf Single Screen konzipiert und programmiert, also mit 1 Char pro Element, aber der Publisher meinte es waere toller wenn die Grafik schoener waere und mit Scrolling und so, deshalb ist ein Boulder Dash Level dann auch genau so gross wie 4 Bildschirme (weil jedes Element nun 2x2 Chars hat). Aber theoretisch koennte man das Spiel nun auch auf Single Screen portieren ohne Scrolling, mit den selben Levels. Nur halt mit 1 Char pro Element dann.
-
Es gibt uebrigens einen solchen Clone (wobe die Levels nicht die gleichen sind): Bitte melde dich an, um diesen Link zu sehen.
-
Ein kleiner Boulder Dash Klon, vielleicht sogar ohne Scrolling, einfach nur um das Prinzip zu verdeutlichen?
Bitte melde dich an, um diesen Link zu sehen.?
-