Adventure Spiel für den C64 - Grafiker gesucht

Es gibt 871 Antworten in diesem Thema, welches 128.088 mal aufgerufen wurde. Der letzte Beitrag (5. März 2025 um 12:10) ist von FXXS.

  • "Secret of Monkey Island" auf dem Apple II von Vince "deater" Weaver (inkl. cc65 Sourcecode):

    Bitte melde dich an, um dieses Medienelement zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

    Weitere interessante Demakes/Techdemos von ihm, anhand derer man sehen kann, was auf alten Rechnern umsetzbar ist, bspw. Apple II Peasant's Quest

    Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um dieses Medienelement zu sehen.


    --------------------------------------------------------------------

    Zurück zum C64:
    Anbei ein kleines Update zu dem muscu-Test mit den DT100 Daten.

    Bitte melde dich an, um diesen Anhang zu sehen.

    Bitte melde dich an, um diesen Anhang zu sehen.

    - pro:
    -- Man kann die Screens bewundern.
    - contra:
    -- kein Speedloader, da zusammengeschusterte Floppy-Routinen (Am besten Warp in Vice nutzen).
    -- Es gibt eine Rasterzeile mit einem Grafikfehler.
    (...)

  • Das sieht echt gut aus. Krass ist aber bestimmt der Speicher, der benötigt wird. Im D42 krieg ich ca. 25 Räume mit Bildern + etwas Musik auf eine Diskettenseite. Pro Raum ca. 25 Blöcke. Kannst du abschätzen, wieviel Blöcke ein Raum bei deiner Methode braucht?

  • Bolzgramm:
    Die ursprünglichen Raumdaten sind mit einer einfachen RLE Kodierung gespeichert.
    Max. werden ca. 31 Blöcke verwendet (=bestehend aus 12 Blöcke Daten und ca. 19 Blöcke Grafik).
    Falls sich die Daten gut komprimieren lassen, wird entsprechend weniger Speicher benötigt.

    -----
    Ein MUSCU-Bild aus dem Beispiel beansprucht ca. 38 Blöcke, wobei keine Komprimierung verwendet wurde.
    Die Idee war, dass man die Bilder einfach* mit auf die Disketten bei den jeweiligen Räumen speichert und die Endung ".muc" hinzufügt.

    * = Im Endeffekt war es dann jedoch doch sinnvoll ein Skript zu nutzen, welches einmal die nicht benötigten/unsichtbaren Teile des ursprünglichen MUSCU-Bildformats entfernt. Statt 64 Blöcke (mit Lücken) werden jetzt also nur noch 38 für eine Raumgrafik mit 18 Zeilen Höhe (=144 Pixel) benötigt.
    Zusammen mit den ursprünglichen unberührten Raumdaten ergibt das max. ca. 69 Blöcke pro Raum bzw. 664/69 = ca. 9 Räume pro Diskettenseite.
    (Soweit wäre das für die DT100-Demo ausreichend.)


    ------------------------------
    Bei der Anwendung des Konvertierungsskripts könnte man einen Schritt weiter gehen und auch über eine Komprimierung nachdenken bzw. man könnte ein komplett neues Raumdatenformat erzeugen, welches aus den ursprünglichen Raumdaten und einer neuen Grafik besteht, so dass die ursprünglichen Raumdaten nicht mehr auf der Diskette vorhanden sein müssten.

    Das neue Raumdatenformat würde dann pro Raum unkomprimiert 50 Blöcke (= 12 Blöcke Daten und 38 Blöcke für die MUSCU-Grafik) benötigen.
    664 / 50 = ergibt ca. 13 Räume pro Diskettenseite.

    -----Ich habe gerade aus Neugier Exomizer mit den MUSCU-Grafiken getestet:
    - im Durchschnitt gab es eine Reduktion um ca. 40-55%, d.h. von 38 Blöcke auf ca. 22.
    - Bei dem Bild "13.muc" gab es einen Ausreißer und es konnte nur um ca. 23% reduziert werden, d.h. von 38 Blöcke auf ca. 29.
    Hier würden schätzungsweise also ca. 20 Räume pro Diskettenseite Platz finden.

    (...)
    Es fehlt noch ein Test mit dem oben beschriebenen neuen zusammengesetzten Raumformat.
    Ich denke, dass man so auf ca. 22 Räume pro Diskettenseite kommen könnte;
    Gedanken dazu:
    - der Workflow würde sich dadurch jedoch auch ändern, d.h. falls man Korrekturen oder Änderungen mit dem D42-System an seinem Adventure vornehmen würde, müsste man danach erst immer das neue Format erzeugen, um im neuen Player zu testen usw. usf.
    (...)

  • Kann die MUSCU-Methode denn eigentlich auch die Overlays mit Sprites?

    Anbei einmal zwei Bilder der Küche.

    Im ersten Bild sind das Stück Fleisch, der Topf, der rote Hering und die Möwe zu erkennen.

    Alle diese Objekte sind Sprites, die auf der eigentlichen Raumgrafik liegen.

    Im zweiten Bild hat Guybrush sich das Fleisch, den Topf und den Fisch genommen und die Möwe ist weggeflogen.

    Das ist dann das eigentliche "leere" Raumbild ohne die Overlay-Sprites.

  • "muscu-Test mit den DT100 Daten."

    Sorry, Handybetrieb.

    Welches Format ist es denn genau? MUCSU-Hires?

    Werden da nicht auch Sprites benutzt, die dann für Cursor, Gegenstände.... fehlen?

    MfG Tobias

  • Echte Hardwaresprites sind bei der MUSCU-Methode nicht möglich, da sie alle (7 + Mauszeiger) verwendet werden.

    -----

    Worüber man nachdenken könnte, wäre die benötigten Objektgrafiken für einen Raum separat als Grafikausschnitt (=Screen+Bitmap+Spritedaten) statt Sprites zu speichern.

    Im D42-System sind für die ersten 56 Objekte jeweils 1 Sprite (="SpriteGrafik") definierbar.

    In einem Raum können max. 8 Objekte gleichzeitig vorhanden sein bzw. initial mit einem Sprite und einer XY-Spriteposition definiert werden.

    Im Verlauf des Spiels gehen diese Referenzen zwischen den Objekten und Spritepositionen verloren, so dass die max. 8 ursprünglich definierten Objekte, höchstens einmal zu Beginn beim Anzeigen eines Raumes an bestimmten Stellen gezeichnet werden müssen.

    Darüberhinaus können sich die definierten Spritepositionen auch während des Spiels nicht ändern, was die Umsetzung für die "MUSCU-Methode" sehr vereinfacht.

    -----

    Es gibt mehrere Lösungen für eine Umsetzung der Objektgrafiken im MUSCU-Grafikmodus.

    Sie sind abhängig davon,

    - wie man die 8 initialen Objektgrafiken definieren möchte,

    - wo man sie speichern/unterbringen möchte,
    - ob zusätzliche Metadaten in irgendeiner Form mitgegeben werden, und
    - wieviel Aufwand man betreiben möchte.

    -----

    Im besten (erträumten) Fall, wären bspw. größere Flächen und Animationen u.ä. möglich.

    Im einfachsten "Realrelevanten"-Fall, welchen ich bevorzugen würde, wären die max. 8 benötigten Spritegrafiken in der Bilddatei ".muc" unterhalb der 144. Pixelzeile definiert.

    Der Bereich könnte bspw. folgende Maße haben: 8 * 32 Pixel (Breite) * 24 Pixel (Höhe).

    Warum nicht 24*21 ?

    Die Breite sollte durch 16 teilbar sein und die Höhe durch 8, um Schiebeoperationen/Colorclashes für die Darstellung in MUSC zu vermeiden und die Spritekoordinaten (8-Bit) aus dem D42-System einfach nutzen zu können.

    Die Grafiken würden als Blöcke ohne Transparenz gezeichnet werden.

    -----

    Im primitivsten/trivialsten Fall, ignoriert man einfach die Sprite-Geschichte.

    (Im DT100-Adventure werden Sprites nicht genutzt (bzw. habe ich keine gesehen ;))

    ==================

    Noch ein Hinweis zu einer künstlichen Einschränkung, welche ich in meinem Beipsiel gesetzt habe:

    - Obwohl das MUSCU-Format für jedes Sprite eine eigene Hintergrundfarbe ermöglicht, d.h. jeder vertikale Streifen im Abstand von 48 Pixel könnte eine eigene Spritefarbe haben, habe ich sie einfach auf Schwarz gesetzt.

    Der Hintergrund ist der, dass in meiner Vorstellung, die Schrift, die auf der Raumgrafik gezeichnet werden soll, einen schwarzen Rand (4-Pixel grob!) haben können sollte.

    Diese Einschränkung würde sich auch auf die Objektgrafiken auswirken.

    ----

    Und noch ein Zusatzgedanke/ Gedanke am Rande:

    Ich habe jetzt wieder viel geschrieben.

    Ich denke mir, dass mittlerweile so tolle Dinge (=IDE + Compiler/Transpiler ?), wie Bitte melde dich an, um diesen Link zu sehen. jedem ermöglichen, schnell "etwas" zu erstellen/"programmieren".

    M.M.n. ist TRSE sehr gut dokumentiert und mit vielen Beispielen versehen.

    (Ich bin positiv sehr beeindruckt und werde das Programm mit Sicherheit in der Zukunft benutzen/ausprobieren!)

    Als Anregung/Motivation/Einstiegspunkt für die Nutzung von etwas "Turbo Pascal"-ähnlichem für die Erstellung eines SCUMM-artigen Adventures könnte folgender Link dienen:

    Bitte melde dich an, um diesen Link zu sehen.

    (Soweit ich das sehe, wird im Link kein Interpreter genutzt/umgesetzt, sondern jeder Raum ist eigens "programmiert".)

    Im Internet findet man nat. noch mehr Turbo-Pascal Code/Beispiele/Anregungen.

  • Tobias
    Ich hoffe ich habe Deine Fragen richtig verstanden.

    Wie wird die MUSCU Grafik dann erzeugt

    Soweit ich weiß, existiert derzeit kein Editor, d.h. eine Nachbearbeitung ist schwierig bzw. unpraktikabel bis fast unmöglich (?).

    Ich habe die Screenshots mit dem Tool Bitte melde dich an, um diesen Link zu sehen. von Algorithm konvertiert.
    - Das Tool stellt neue Features für sein "MUSC-Format V2" Format bereit, welche ich in meiner Demo nicht verwenden wollte bzw. nicht als sinnvoll erachtet habe.

    - Es enthält jedoch zumindest Bugfixes im Vgl. zur Vorgängerversion.

    Bitte melde dich an, um diesen Anhang zu sehen.

    Meine Vorgehensweise je Screenshot war:

    1.) Bild geladen

    2.) "none" beim Dithering gewählt.

    3.) Im rechten Dropdown "$d027-$d02d - Manual selection" gewählt und die Felder $d027-$d02d auf 0 gesetzt.

    4.) Im linken Dropdown "MUSC - Underlay Perceptual" gewählt und einmal auf "Process" gedrückt.

    5.) Im linken Dropdown "MUCSU - Manual" gewählt und die 2 prominentesten Farben "durch scharfes hinsehen" identifiziert und in die Felder für $d025 und $d026 eingetragen.

    6.) Nochmal auf "Process" gedrückt und die Datei als ".raw" gespeichert.


    --------------

    Um die unnötigen Daten aus den gespeicherten ".raw"-Dateien zu entfernen, habe ich folgendes ".lua" Skript ausgeführt.
    Aufruf mit:
    lua54.exe muc2bin.lua dateiname.raw dateiname.muc
    also bspw.: lua54.exe muc2bin.lua 00.raw 00.muc

    Für weitere Infos bzgl. lua siehe Bitte melde dich an, um diesen Link zu sehen.

    Um mehrere ".raw"-Dateien auf einmal zu konvertieren habe ich nat. eine Batch Datei verwendet.

    --------------
    Als letztes habe ich das Tool Bitte melde dich an, um diesen Link zu sehen. von Style verwendet und die ".muc"-Dateien auf meine modifizierte DT100 .d64 zu bringen.
    (Modifiziert in dem Sinne, dass die "main.prg" vorhanden ist und die Dateinamen wirklich nur aus 2 Buchstaben bestehen, d.h. die .d64 enthält keine Directory-Art.)

    Es existieren natürlich auch andere Tools, welche auch automaisiert aufgerufen werden können, um Dateien auf eine .d64 zu übertragen.

    Wo ist der Vorteil?

    Der Vorteil bei diesem Grafikmodus ist, im Vergleich zu MC, dass das Ergebnis im Falle von MI näher an die EGA Darstellung herankommt.
    Der Vorteil im Vergleich zu NUFLI, liegt darin, dass er speicherplatzschonender, simpler aufgebaut und anzeigbar ist, und auch ein Sprite für den Mauspfeil frei ist.
    Zusätzlich weiß ich nicht, ob bei NUFLI das Einfügen von Inhalten Colorclashes oder andere Auswirkungen auf den Rest der Grafik hat.
    Und der subjektiv wichtigste Grund für mich ist, dass mein Skilllevel nicht ausreichend für eine Umsetzung mit NUFLI ist/wäre.

    Hast Du mal die "technischen Daten" aus Anwendersicht?

    Da gibt es nicht viel:
    - Hires-Bitmap-Modus mit einem SpriteLayer darunter, bestehend aus 7 horizontal gestreckten Multicolor-Sprites und in unserem Fall über 7 Sprites in der Höhe, da 7*21 = 147 Pixel hoch.
    - Die aktuellen Speicherpositionen lassen sich aus dem lua Skript entnehmen. Jedoch handelt es sich bei dem hier verwendeten ".muc" Format um eines, welches sich noch kurzfristig ändern kann.
    -- Zusätzlich haben wir folgende Einschränkung in dieser Demo bzgl. des Spritelayers:
    --- Sprite-Mutlicolor1 und Sprite-Mutlicolor2 sind je Raumgrafik festgelegt.
    --- Die SpriteColor ist für alle Sprites immer auf Schwarz festgelegt.


    Ich hoffe ich konnte einige Unklarheiten beseitigen.

  • Danke für die Erklärung.

    Wir haben also 2 Farben pro Hires 8x8 Bitmap-Kachel plus 3 Farben in einer 48x21 "Sprite-Kachel" , wobei ein "Pixel" hier 4x1 groß ist.

    Pro Sprite-Kachel hätte das Format alle 3 Farben individuell, Du nimmst aber 2+schwarz.

    So weit korrekt?

    Übrig bleibt ein für den Pfeil nutzbares Sprite. Braucht man denn für die Gegenstände im "Fundus" keine Sprites?

  • "Findet" der Konverter für die EGA-Farben immer zuverlässig die (zumindest 14) entsprechenden C64 Farben oder würde es was bringen, die Farben schon vorher auszutauschen?

    Weißt Du, auf welche Palette hin der Konverter umwandelt?

    MfG Tobias

  • Hier ein kurzer Gedanke bzgl. Hilfswerkzeugen beim Pixeln: Bitte melde dich an, um diesen Link zu sehen.

    Und hier noch ein monochromes Diff-Bild zwischen Konvertierung und Überarbeitung des Intro-Pics:

    Bitte melde dich an, um diesen Anhang zu sehen.

    skaliert und konvertiert:

    Bitte melde dich an, um diesen Anhang zu sehen.

    überarbeitet:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Bei diesem Bild hatte ich übrigens auch die inhaltsbasierte Skalierung von Photoshop angewendet. Denn sonst hätte es nicht ganz drauf gepasst. Und noch ansatzweise das essentielle Dorf am unteren Rand. Will sagen, die Beschränkung auf 96px Höhe macht die Sache nicht einfacher. Andererseits muss ich auch feststellen, dass Pixeln eine sehr beruhigende Tätigkeit ist, die mir gut tut. Zum Glück habe ich bald viel mehr Zeit für diesen ganzen schönen Shice.

    Ein Bild ist bei mir auch so schnell nicht wirklich fertig, d.h. beim erneuten Ansehen muss da nochmal was gemacht werden, z.B. bei den VIP-Piraten:

    alt:

    Bitte melde dich an, um diesen Anhang zu sehen.

    neu:

    Bitte melde dich an, um diesen Anhang zu sehen.

    diff:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Bei dem Fenster in der Küchentür hatte ich mich zuvor vertan; die Farbe im Fenster war wohl schon richtig. Außerdem war der Tisch in allen Version ziemlich schief, was ich weitgehend korrigiert hab.

    Im linken Teil der Scumm-Bar ist die Höhe auch ein Problem, wenn man den Heini an dem Leuchter nicht verwerfen will. Der Leuchter reicht etwa bis zu obersten Querstrebe des Fensters links daneben. Wenn man für 96px unten nichts abschneiden will, muss man ihn wesentlich tiefer hängen, fast bis zum unteren Rand des Fensters, was viel zu tief für einen Leuchter ist; man würde sich den Kopf stoßen. Der Leuchter und der Typ muss also neu designt werden.

    Das Bild von Hokuto Force benutzt übrigens Sprite-Overlays, denn sonst sähe Guybrush da auch nicht so gut aus. Hier mal ohne die Sprites:

    Bitte melde dich an, um diesen Anhang zu sehen.

  • neu:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Leider komplett mit Z-Bug. Eigentlich sollten die Hände und Krüge auf dem Tisch zu sehen sein, aber das wurde wohl verpatzt. In späteren Versionen wurde dieser Bug behoben. Leider ist auch die Atari-ST-Version betroffen, so daß die hier keine Alternative ist.

    Aber mit einem Tool wie ScummRev oder ähnliches sollte es möglich sein, die EGA-Sprites der Piratenanführer zu extrahieren, um sie manuell über die Tischplatte zu kopieren.

  • Wir haben also 2 Farben pro Hires 8x8 Bitmap-Kachel plus 3 Farben in einer 48x21 "Sprite-Kachel" , wobei ein "Pixel" hier 4x1 groß ist.

    Pro Sprite-Kachel hätte das Format alle 3 Farben individuell, Du nimmst aber 2+schwarz.

    So weit korrekt?

    Übrig bleibt ein für den Pfeil nutzbares Sprite.

    Fast richtig.
    2 Farben pro Hires 8x8 Bitmap-Kachel plus eine Farbe in einer 48x21 "Sprite-Kachel".
    Der Grund ist, dass die 2 Sprite-Multicolor-Farben für alle Sprites (((je Rasterzeile))) gelten.
    Bzgl. der Demo mit der Einschränkung ergibt sich für den Sprite-Layer für das gesammte Bild nur die freie Wahl von 2 Farben (+ Schwarz ist fix).
    Der Rest ist korrekt.

    Braucht man denn für die Gegenstände im "Fundus" keine Sprites?

    Ich hatte in der DT-100 Demo nicht vor Gegenstände darzustellen, weil dort keine Sprites für die Objekte verwendet werden (siehe den Post Bitte melde dich an, um diesen Link zu sehen. für mögliche Umsetzungen).

    Falls Du mit "Fundus" unten das Panel meinst, dort habe ich nur 2 Sprites für das MouseOver bei den grünen Befehlen verwendet, weil dort der Zeilenabstand 9 Pixel beträgt.
    Mouseover über den Rest der violett gefärbten Gegenstandslisten und der blauen Pfeile, die im Moment nicht sichtbar sind, sind einfach mit einer üblichen Farbänderung im Bitmapmodus umsetzbar, d.h. hier benötigt man keine weiteren Sprites, weil die Zeilenpositionen durch 8 teilbar sind und somit im Raster liegen.

    "Findet" der Konverter für die EGA-Farben immer zuverlässig die (zumindest 14) entsprechenden C64 Farben oder würde es was bringen, die Farben schon vorher auszutauschen?

    Weißt Du, auf welche Palette hin der Konverter umwandelt?

    Bzgl. der ersten Frage müsstest Du das selbst austesten.
    Bzgl. der zweiten Frage: In der Vorgängerversion des Konverters sind Paletten in der .zip-Datei enthalten. Evtl. werden diese auch in der neueren Version verwendet. (Konnte ich wegen der Dateiendung nicht anghängen.)
    Bitte melde dich an, um diesen Link zu sehen.

    Andererseits muss ich auch feststellen, dass Pixeln eine sehr beruhigende Tätigkeit ist, die mir gut tut. Zum Glück habe ich bald viel mehr Zeit für diesen ganzen schönen Shice.

    :lol27:

  • Leider komplett mit Z-Bug. Eigentlich sollten die Hände und Krüge auf dem Tisch zu sehen sein, aber das wurde wohl verpatzt. In späteren Versionen wurde dieser Bug behoben. Leider ist auch die Atari-ST-Version betroffen, so daß die hier keine Alternative ist.

    Aber mit einem Tool wie ScummRev oder ähnliches sollte es möglich sein, die EGA-Sprites der Piratenanführer zu extrahieren, um sie manuell über die Tischplatte zu kopieren.

    Z-Bug?

    Wie sollte die Szene richtig aussehen und sind noch andere Szenen davon betroffen?

  • Hier die Szene mit Händen und Krügen.

    Bitte melde dich an, um diesen Anhang zu sehen.

    P.S. Mal eine alte, schöne News zum Thema:

    Bitte melde dich an, um diesen Link zu sehen.

    Referral Code für Einkäufe bei commodore.net - Kauft den neuen Commodore 64 Ultimate
    Ihr erhaltet 10 Dollar Rabatt
    Bitte melde dich an, um diesen Link zu sehen.

  • Wie sollte die Szene richtig aussehen und sind noch andere Szenen davon betroffen?

    Soweit ich weiß, ist das die einzige Szene in der EGA-Version mit so einem Fehler. Insgesamt hatte die EGA-Version auch die wenigsten Fehler. In späteren Versionen sind mehr Fehler hinzugekommen als gefixt wurden. Bei meiner Bitte melde dich an, um diesen Link zu sehen. ist eine readme.txt dabei, die eine lange Liste mit Fehlern enthält, die alle behoben wurden.

    P.S. Mal eine alte, schöne News zum Thema:

    Ja, das hatten die sogar bei Tales of Monkey Island aufgegriffen und den Grog XD im Spiel eingebaut.

  • Bitte melde dich an, um diesen Link zu sehen.

    :)

    Es ist immer wieder herzerwärmend, ikonische Momente aus dem eigenen (jüngeren) Gamer-Leben in anderer Form zu sehen, also wie Monkey Island auf C64 oder als Diorama. Aber Selbermachen macht mehr Spaß, als dafür 75 Euro abzudrücken. Den Hintergrund muss man nachbearbeiten und neupixeln und die Figuren nur ausschneiden und aufkleben - voilà! Hatte ich schon lange vor, werd ich in den aktuellen Ferien mal mit Junior basteln. Danke für den Reminder.