Hallo Besucher, der Thread wurde 257k mal aufgerufen und enthält 1436 Antworten

letzter Beitrag von ogd am

Bomb Jack DX (C64): Neue Portierung

    Zitat von TheRealWanderer

    Hammer! Heißt die Version dann nachher "Bomb Jack Arcade"?


    Danke. Das wäre aus meiner Sicht ein denkbarer Name. Nur leider wird es wohl nicht zu einem Spiel werden.


    Zitat von PARALAX

    Ich hoffe die fertige Version schafft es bis zum 30.5. zu unserem 15. Retro- Hörer-Treff in Wuppertal.


    Falls du die Grafik meinst: Machbar. Aber selbst um die Grafik auf einem C64 darzustellen, müsste schon "ein bisschen" programmiert werden, weil sie ja aus Hintergrund-Bitmapgrafik plus Gegner-Sprites besteht. Wenn du ein Spiel meinst: keine Chance. Schon alleine deswegen nicht, weil es von mir erst einmal nur als Mockup gedacht war. Ich habe keinen Programmierer an der Hand, der das umsetzen würde (mit ALeX zusammen sitze ich ausgelastet an einigen anderen Projekten). Ich wollte halt ausprobieren, zu was der C64 fähig ist (bzw. zu was er auch damals schon fähig gewesen wäre) und gucken, ob der C64-Port des Spiels hätte der hübscheste und originalgetreueste 8-Bit-Port werden können, wenn man nur deutlich mehr Mühe reingesteckt hätte.


    Wenn ich ein C64-Spiel sehe und denke, dass hätte man aber grafisch besser machen können, probiere ich manchmal aus, ob das überhaupt stimmt. Denn oftmals standen dem C64-Software-Entwicker Restriktionen im Weg, die man auch heute nicht einfach zur Seite wischen kann. Deshalb war das als Experiment zu sehen: Ich wollte einerseits gucken, wie nah man an das Original herankommen könnte (obwohl ich mir auch grafische Freiheiten erlaube, wenn ich meine, dass es besser aussieht, als wenn ich sklavisch versuchen würde, das Original zu kopieren) und andererseits war durch den optisch schon sehr guten XL/XE-Port mein Ehrgeiz geweckt, eine noch eindrucksvollere C64-Vesion zu basteln.


    [Externes Medium: https://www.youtube.com/watch?v=Vv6DKTwgJYc]



    Nicht mehr und nicht weniger: Es ist nur eine Pixelei, um die Möglichkeiten auszuloten. Ich hätte zwar auch Spaß dran, dass zu einem Spiel auszubauen und alle Sprites durchzuanimieren (und die noch fehlenden Hintergründe zu ergänzen) aber wo kein Programmierer ist, ist eben auch kein Spiel.

    Chic :)
    Eine kleine technische Anmerkung:
    Im C64-Original gibt es 'verschiedene' Bomben mit Hintergruenden, damit es nicht noch blockiger aussieht als ohnehinschon.
    Dein Mockup beruecksichtigt das bisher allerdings noch gar nicht (das das Bombchar in die Hintergrundgrafik gesetzt wird).
    Oder hast Du das groib durchgezaehlt und pro Level eigene Bomb-Bloecke vorgesehen, so dass die Bombe ueber der Pyramidenseite tatsaechlich so passt?
    Den screen als PRG inkl. (statischer) Sprites bekommt doch bestimmt jemand hin hier - das waere doch ein super Einstieg ganz ohne Timingkritische Dinge und es wuerde hier sicher gut geholfen werden!
    Nur zu! :-)

    Zitat von Retrofan

    Ich habe keinen Programmierer an der Hand, der das umsetzen würde (mit ALeX zusammen sitze ich ausgelastet an einigen anderen Projekten).


    Wäre aber schade weil da wirklich viel Potential drin steckt. Da würde sich bestimmt auch ein Programmierer finden, der bereit wäre das spielerisch um zu setzen. Vielleicht könnte man mal die Jungs von "Genesis Project" fragen und das ganze ggf. auch als Cartridge veröffentlichen. Wie schön remasterte Fassungen aussehen können haben wir ja zuletzt an Ultima IV gesehen. Und dein Screenshot ist definitiv mehr Wert als noch ein "Versuch" ;)


    Zitat

    ...aber wo kein Programmierer ist, ist eben auch kein Spiel.


    Damit ziehst Du Dich nur selbst runter. Nicht aufgeben und einfach mal ein paar Demogruppen kontaktieren. Ich könnte mir vorstellen, das es auf Dauer ein wenig frustig ist, wenn man so tolle Ideen hat, die alle im Sande verlaufen nur weil sie nicht von den richtigen Personen entdeckt und umgesetzt werden. Das fand ich auch seinerzeit schon bei der C64-Version von Pinball Dreams schon so schade, von der es bis heute keine fertige Version gibt. Aber man soll die Hoffnung ja nie aufgeben. :)

    Zitat von enthusi

    Im C64-Original gibt es 'verschiedene' Bomben mit Hintergruenden, damit es nicht noch blockiger aussieht als ohnehinschon. Dein Mockup beruecksichtigt das bisher allerdings noch gar nicht (das das Bombchar in die Hintergrundgrafik gesetzt wird).


    Doch, mein Mockup berücksichtigt das. Aber trickiger! Im Gegensatz zum C64-Original arbeite ich hier nicht im Char-Modus, sondern im Multicolor-Bitmap-Modus (wie auch z.B. bei Monster Buster, falls das jemand interessiert). Gewiefte Programmierer sind im Bitmap-Mode nicht darauf angewiesen, nur plump rechteckige Screenbereiche durch alternative Chars auszutauschen, sondern sie können entweder, wenn genügend Speicher vorhanden ist, jede Bombe mit ihrem eigenen Hintergrund ablegen (es gibt ja keine Char-Mengenbegrenzung) oder eben (wie es ALeX schon gemacht hat) Elemente miteinander verrechnen (quasi blenden), sofern der Grafiker das bei den verwendeten Farben berücksichtigt hat.


    Zitat von enthusi

    Den screen als PRG inkl. (statischer) Sprites bekommt doch bestimmt jemand hin hier - das waere doch ein super Einstieg ganz ohne Timingkritische Dinge und es wuerde hier sicher gut geholfen werden!


    Da keimt schon eine kleine Hoffnung.


    Ohne timingkritische Dinge wäre allerdings nur der Hauptscreen mit den Spieler-Sprites möglich, die Sachen in den offenen Bordern (oberer und unterer Rahmen-Verlauf und Scores) müsste man erst weglassen (man muss nicht nur den Rahmen öffnen, sondern auch einen Sprite-Multiplexer basteln).



    Ich habe hier mal (fast) ausgeblendet, was wegfallen würde, wenn man (erst einmal) auf Multiplexer und offene Border verzichten würde.

    Zitat von Drachen

    Vielleich findet sich ein Proger mal dazu bereit, das orginal Prgamm um zu schreiben mit der neuen Grafik von Retrofan. Wenn das überhaupt machbar wäre.


    Möglich wäre das aber ein Coder müsste gucken, was einfacher ist: Neu machen oder herumbasteln. Angeblich ist die Atari XL/XE-Version aus dem C64-Code entstanden. Es geht also wohl. Die Frage ist halt, wie gut man in den bestehenden Code reinkommt und wie flexibel man damit ist. Ich habe hier ja nicht einfach die Grafiken ausgetauscht. Im Gegensatz zum Original arbeitet meine angedachte Version im Bitmap-Mode (platziert damit auch die Bomben mit anderer Technik), hat ein breiteres Spielfeld, geöffnete Borders (vertikal), einen Sprite-Multiplexer und Rasterbars (für die oberen und unteren Rahmen-Farbverläufe, welche wiederum von Sprites überlagert werden). Ich weiß nicht, ob man das alles um den bestehenden Code herumbasteln kann.

    Zitat von Retrofan

    Elemente miteinander verrechnen (quasi blenden), sofern der Grafiker das bei den verwendeten Farben berücksichtigt hat.

    Was beim C64 nicht so einfach ist. Da müßte vorher genau festgelegt werden, welche Farben überschrieben werden dürfen und welche nicht, also z. B. Multicolour #1 und #2 werden durch ein Shape neu gesetzt, aber die Hintergrundfarbe und die $d800-Farbe werden an der jeweiligen Stelle übernommen. Machbar wäre es aber durchaus.
    Das Problem bei einer Neuumsetzung dürfte eher hierin liegen:

    Zitat von Retrofan

    Im Gegensatz zum Original arbeitet meine angedachte Version im Bitmap-Mode

    Bitmap-Graphik verbraucht wesentlich mehr Speicher als Char-Graphik. Dafür ist das Ergebnis auch deutlich besser, wie man hier schön sieht (Gute Arbeit, Retrofan!). Von daher wäre echte Bitmap-Graphik bei einem Spiel mit statischer Hintergrundgraphik eine gute, nachvollziehbare Wahl. Daneben gibt es jedoch noch viele Kleinigkeiten, die man mitberücksichtigen muß, weil sie sich schnell aufsummieren. Es sind nicht nur mehr Interrupts oder Spritemultiplexer am Werk. Hinzu kommen auch Sachen wie z. B. die Scoreanzeige, die nicht mehr über Chars (ein Poke reicht für eine Ziffer) dargestellt, sondern per Prozessor byteweise in die Rahmensprites gemalt wird. Natürlich muß auch die Graphik an sich gemalt werden, ebenso wie die Bombenshapes, die später mittels Ersetzen durch Teile der Hintergrundgraphik (wo liegt diese im Speicher?) gelöscht werden. Das ist bei echter Graphik halt alles ein wenig aufwendiger und kostet dadurch schlicht mehr Speicherplatz für die dafür notwendigen Routinen und Daten. Der erste Schritt wäre also zu gucken, ob es beim Originalprogramm noch ausreichend Platz im Speicher gibt (z. B. Ram bei $d000-$dfff), oder ob man notfalls Programmteile auf Diskette auslagern muß. Bei der tollen Graphik könnte sich sowas aber durchaus lohnen.
    Meine Frage als Nichtspieler von Bombjack (sorry, kenne es nur vom Sehen her) wäre: Wieviele Sprites sind in der Spielfläche maximal gleichzeitig sichtbar? Braucht man dafür bereits einen speziellen Spritemultiplexer oder reicht es für die Gesamtdarstellung aus, wenn man die Sprites auf konkrete in Y-Richtung getrennte Bereiche verteilt (also Rahmen und Spielfläche)? Falls ja, sollte es nicht so schwer sein, ein kleines Progrämmchen zusammenzuschustern, welches Retrofans Graphik zu Demozwecken auf einem C64 real anzeigt.

    Zitat von M. J.

    Was beim C64 nicht so einfach ist. Da müßte vorher genau festgelegt werden, welche Farben überschrieben werden dürfen und welche nicht, also z. B. Multicolour #1 und #2 werden durch ein Shape neu gesetzt, aber die Hintergrundfarbe und die $d800-Farbe werden an der jeweiligen Stelle übernommen. Machbar wäre es aber durchaus.


    ALeX hat es ja in Monster Buster schon mit meinen Grafiken gemacht (der "weiche" Schatten, der den Game Over Screen umfasst, wird on-the-fly in die bestehende Grafik reingerechnet). Sonst würde ich sowas ja nicht vorsehen. An vielen Stellen ist bei Bomb Jack die Bitmap-Grafik von Vorteil. Das Spiel schreit förmlich danach, in MC-Grafik angelegt zu werden: kein Scrolling, sehr statischer Bildaufbau mit wenigen Veränderungen innerhalb eines Levels, viele unterschiedliche Grafikelemente, viele Farben.


    Speicherplatz ist natürlich im Bitmap Mode ein größeres Problem, allerdings dürfte das trotzdem machbar sein. Üblicherweise hat doch ein MC-Bild rund 9KB, oder? Bomb Jack hat 4 (oder sind es 5?) Hintergrundbilder, das wären 36 KB, die man mit Exomizer wahrscheinlich auf 18 KB komprimieren kann. Dazu kommt natürlich der Framebuffer (damit man dem VIC nicht beim "Malen" zusehen" kann), die Alternativ-Tiles für Bomben und Plattformen und die ganzen Sprite-Animationsphasen (das sind bei Bomb Jack nicht wenige). Ich denke aber, dass man mit einem 64 KB Modul hinkommen sollte (das ist immer noch weit weniger als die 320 KB, die die Atari XL/XE-Version haben möchte).


    Zitat von M. J.

    Wieviele Sprites sind in der Spielfläche maximal gleichzeitig sichtbar? Braucht man dafür bereits einen speziellen Spritemultiplexer


    Für das Arcade-Original kann ich das nicht genau sagen aber die C64-Version ist sicherlich ohne Multiplexer ausgekommen, sodass man wohl mit dem Protagonisten plus 7 Gegner hinkommen wird. Der Multiplexer beschränkt sich also darauf, frische Sprites für die offenen Border unten und oben zur Verfügung zu stellen.


    Zitat von M. J.

    Falls ja, sollte es nicht so schwer sein, ein kleines Progrämmchen zusammenzuschustern, welches Retrofans Graphik zu Demozwecken auf einem C64 real anzeigt.


    Da hoffe ich drauf. Wobei es noch kleine Herausforderungen bei den Sprite-Farbwechseln im Border gibt. Aber das dürfte schon irgendwie lösbar sein.

    Zitat von Retrofan

    Dazu kommt natürlich der Framebuffer (damit man dem VIC nicht beim "Malen" zusehen" kann)

    Falls Du damit sowas wie Double-Buffering meinst: Das wird teuer. Da man beide Bitmaps (Spielanzeige und Framebuffer) nicht in eine VIC-Bank packen kann, müssen diese auf zwei Banks aufgeteilt werden, also eine Verdoppelung der 9k auf 18kb. Hinzu kommen dann aber auch die Verdoppelungen der Sprites, da diese ebenfalls in beiden Banks vorrätig gehalten werden müssen. Benötigt das Originalspiel beispielsweise 2kb für Sprites, wird eine Bitmap-Version mit Framebuffer nochmals 2kb verbrauchen. Zum Vergleich: Geht man davon aus, daß das Originalspiel 3kb braucht für die Graphik (Zeichenspeicher + Zeichensatz) sowie 2kb für Sprites> ==> 5kb insgesamt, dann verlangt die Bitmapversion mal eben 22kb.

    Zitat von Retrofan

    Ich denke aber, dass man mit einem 64 KB Modul hinkommen sollte

    Eigentlich mache ich mir mehr Sorgen um den Arbeitsspeicher. Der beträgt halt nur 64kb, und wenn mehr als ein Viertel allein für die Graphikdarstellung draufgeht, wird es eng im Speicher. Aus dem Grunde meinte ich, daß zur Lösung des Speichermangels Teile von Diskette (oder vom Modul) nachgeladen werden müssen. Dennoch würde ich eine echte Bitmap-Darstellung bevorzugen wollen. Meiner Meinung nach gab es viel zu wenig Spiele, die von der guten Graphikmöglichkeit des C64 gebrauch gemacht haben.

    Zitat von Retrofan

    Das Spiel schreit förmlich danach, in MC-Grafik angelegt zu werden

    +1
    Kleine Frage: Liegen die Bild- und Spritedaten auch als Binärdateien vor oder nur als Jpg-Datei?



    EDIT: Hab gerade mal nachgesehen: Beim Originalspiel liegt der Code von ca. $800 - $33ff mit Soundroutinen bei $7448 ff. Erstaunlich ist, daß das Spiel die Roms überhaupt nicht ausblendet. $1 enthält den Wert #$37; BASIC und Kernal sind also dauernd aktiv. ==> Da ist noch viel freier Speicher vorhanden.

    Zitat von M. J.

    Falls Du damit sowas wie Double-Buffering meinst:


    Richtig, das meinte ich. Haben wir bei Monster Buster so gemacht. Und da sind auch massig Sprites, Musik, Programmcode und Char-Monster zusätzlich im Speicher. In der kommenden 64 KB-Modul Version können blitzschnell Daten nachgeladen werden und werfen sich gegenseitig aus dem RAM. Deswegen würde ich so eine Technik auch für Bomb Jack anvisieren.


    Zitat von M. J.

    Kleine Frage: Liegen die Bild- und Spritedaten auch als Binärdateien vor oder nur als Jpg-Datei?


    Ich kann die Daten demnächst zumindest als 16-Farb-PNG-Dateien liefern, so wie ich das für ALeX auch immer mache. Wenn damit niemand sonst etwas anfangen kann, könnte ich zumindest die Hintergrundgrafik als Koala-Bild liefern, die Sprites alle zusammen auch in einem Koala-Bild, da ich nicht mit Charpad oder ähnlichem arbeite, sondern ausschließlich mit Photoshop.

    Muss man denn da wirklich mit Double Buffer arbeiten? Soviel ändert sich doch da nicht gleichzeitig auf dem Schirm? Bestenfalls wird pro Frame eine Bombe aufgesammelt, das sind dann 4 * 8 Bytes? Das sollte doch problemlos im Rahmenbereich möglich sein.


    Oder meinst du beim Level-Wechsel? Da muss man dann doch sowieso schwarz blenden, das Farb-RAM muss ja auch geändert werden während man den nächsten Level einblendet (wenn man denn richtig in die vollen gehen will).

    Ich habe ein wenig weiter optimiert, Unterschiede wird man aber nur im direkten Vergleich sehen. Einige wenige (nicht die wichtigsten) Sprites sind auch schon animiert, damit sich interessierte Programmierer etwas austoben können.



    Ich packe den Kram noch kurz zusammen, schreibe noch ein wenig dazu und dann verschicke ich die Daten.