Adventure Spiel für den C64 - Grafiker gesucht

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

  • Bolzgramm , Tobias , He-Man1982

    Die d42_system.zip enthält das Skript "d42_dump.lua", welches
    - gut kommentiert ist und
    - die D42-Dateiformate beschreibt und
    - den internen Aufbau des D42-Systems bzw. eines erstellten Adventures erahnen lässt.

    d42_dump.lua
    Ausgabe des Skripts 'd42_dump.lua' für das DT100-Adventure (Achtung: Lösungsweg ablesbar!)

    Es wäre also evtl. nicht zu abwägig die "Game-Engine", so gut wie möglich bzw. es die eigenen Fähigkeiten hergeben, nachzuprogrammieren.

    Alternativ könnte ein Cracker vielleicht den Einsprungspunkt zum Anzeigen einer Raumgrafik finden und auf eine eigene Routine umleiten, welche den benötigten Speicher auslagert/rettet und ein Bild in einem besseren Format nachlädt und anzeigt. ( He-Man1982 hattest Du ja bereits vorgeschlagen. Die Kommentare im Skript könnten jemanden diesen Vorgang erleichtern. Schwierig würde ich mir die Nutzung der vorhandenen Loader-Routinen vorstellen...)

    ----

    Die Nachprogrammierung würde ich bevorzugen, wenn man alles auf einem einfachen/primitiven Niveau belässt.

    Die Linie würde ich folgendermaßen ziehen:

    Die Daten aus dem D42-System dürfen nicht verändert oder ergänzt werden, d.h. die neue "Game-Engine" würde/müsste auch mit allen anderen bereits erstellten/zukünftigen Adventures arbeiten können. Bolzgramm

    Die neuen Bilder würden einfach am Dateinamen (bspw. Prefix + Raumnummer o.ä.) erkennbar/auffindbar sein.

    Die Verbesserungen könnten im Detail sein:

    - Oben die Grafik in 160x144 MC anzeigen

    -- In dieser Vorstellungen sprechen viele Gründe diesmal für MC. (*)

    - Die Bedienung unten in Hires und Proportionalfont, wie im Original-Scumm-UI.

    -- Links die Verben; mitte bzw. rechts die Inventargegenstände; weiter rechts die Gegenstände im Raum.

    -- Die Funktion in die Richtungen zu gehen würde ich in den Rändern der angezeigten Grafik verstecken. (Hier könnte es sein, dass bei einigen Adventures die Logik nicht mehr stimmt, wenn unten im Bild nicht mehr Süden ist o.ä..,)

    -- Das Hervorheben mit Farben beim "Mouseover" würde ich auch mit Sprites machen, d.h. die Schrift müsste also nicht auf einer durch 8 teilbaren Y-Koordinate liegen. (Die Ausgabe erfolgt invertiert und lässt ein Sprite beim "mouseover" durchscheinen.)

    - Die Texte (Raumbeschreibung/Antworten) würde ich auf der Grafik anzeigen.

    -- Hierzu würden die verbleibenden 7 Sprites genutzt werden, d.h. die Schrift wäre in Hires lesbar. Die Farben der Bitmap an den Stellen, an der Zeichen dargestellt werden, könnten einfach auf Schwarz gesetzt werden. Dadurch müsste man die Bitmap nicht retten, sondern nur Screen und Colorram + die Lesbarkeit wäre besser als bei einfachen einfarbigen Chars über einer MC-Bitmap. Leider ergeben 7 Sprites nur 168 Pixel Fläche.

    - Sprites für Gegenstände würde ich nicht anzeigen, sondern auch als Bitmaps nachladen (bspw. Prefix + Raumnummer + Objektnummer)

    -- (*) Der Grund ist einfach der, dass keine Sprites mehr übrig sind, wenn Text über der Grafik angezeigt wird bzw. das zu kompliziert werden würde. Tobias

    Was meinerseits unklar ist bzw. wo ich selbst Schwierigkeiten bei einer "Umsetzung" (Proof-Of-Concept ;)) hätte:

    - Die Loader-Routinen (Beim Laden würde ich den Bildschirm ausschalten und den Kernal einsetzen, statt einen IRQ-Loader zu nutzen.)

    - Musik würde ich auch erstmal nicht einsetzen, weil diese 1.) ja auch beim Laden unterbrochen werden würde und 2.) weil ich noch nicht weiß in welcher Datei die Musik gespeichert ist. (Die SongNr. wird bei den Räumen gespeichert.)

    - Evtl. hätte ich Schwierigkeiten beim "originalgetreuen" Textumbruch der Nachrichten o.ä..

    - Ob die Endsequenzen eine spezielle Behandlung benötigen oder einfach aufgerufen und ausgeführt werden können, weiß ich nicht.
    ...

    Ansonsten scheint alles recht überschaubar, soweit man sich das DT100-Adventure anschaut, weil hier

    1.) Allgemeinbedingungen und -Texte nicht verwendet werden und

    2.) die O2-Datei nicht benötigt wird, weil max. 56 Objekte verwendet werden und
    3.) es werden keine Sprites verwendet.

    Und das könnte auch ein erstes Ziel sein, dieses "einfache" Adventure umzusetzen. Sobald es geschehen ist, könnte ein Grafiker die 8 Bilder nachbearbeiten.
    (... soviel zur Vorstelllung/Idee ...)

    Was sind eure Gedanken dazu?


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

    Zurück zum Topic:
    - Für die Konvertierungsschritte am PC gibt es für die Schneideoperationen Programme mit einer Batch Funktion. Für die Konvertierung nach MC nutze ich bspw. Bitte melde dich an, um diesen Link zu sehen. oder online Bitte melde dich an, um diesen Link zu sehen.
    -- Tobias Welches Tool nutzt Du im letzten Schritt für die Konvertierung nach Multicolor? (Evtl. gibt es ein gutes für die Kommandozeile? Dann wäre es möglich 100 Bilder unkompliziert auf einen Schlag zu konvertieren.)

    - Bolzgramm Wieviele Objekte und Räume verwendest Du? Passt alles auf eine Diskette? Benutzt Du Allgemeinbedingungen/Texte ?

  • Was ist DT-100?

    Edit, sorry, partiell Alzheimer. :)

    Kurz zum Hintergrund: in der Digital Talk 100 gab es ein Monkey Island Demo, das mit dem D42 Adventure System von Out of Order Softworks erstellt wurde.

    Muss ich mir dann wohl doch mal anschauen.
    Bitte melde dich an, um diesen Link zu sehen.

    Die Verbesserungen könnten im Detail sein:

    - Oben die Grafik in 160x144 MC anzeigen

    -- In dieser Vorstellungen sprechen viele Gründe diesmal für MC. (*)

    -- (*) Der Grund ist einfach der, dass keine Sprites mehr übrig sind, wenn Text über der Grafik angezeigt wird bzw. das zu kompliziert werden würde.

    Mit z.B. NUFLI könnte man die EGA-Fassung (scheint nach etwas "Recherche" auch die Urfassung aller SoMI Versionen zu sein) fast 1:1 umsetzen.

    Die Unterscheidung der beiden Helligkeiten für cyan und magenta in EGA fällt weg, und einige Color Clashes wird es immer geben.

    Aber ich verstehe, dass dieses Format außer für "passive" Bilder leider eher ungeeignet ist.

    Aus Konvertierungssicht wäre die Erweiterung von 96 auf 144 Linien auch bei Multicolor ein deutlicher Qualitätssprung:
    Ein Beschneiden auf 96 Linien kommt nicht in Frage, da sonst zuviel Bildinhalt unterschlagen wird.
    Andererseits macht das Stauchen von 1xx Lininen auf 96 das Ergebnis nicht schärfer/detailierter.

    Was sind eure Gedanken dazu?

    Du willst also diese D42-"Engine" umschreiben/verbessern, richtig? So ne Art "ScummVM-ultralight"-D42?
    Davon hab ich keine Ahnung.
    @Bolzmann muss abschätzen, ob das machbar ist bzw. für ihn in Frage kommt. Es ist ja sein Projekt und er hat dazu schon diverse Vorüberlegungen angestellt.
    Was mich betrifft, ist mir der Kult um diese Spielereihe bekannt, ich persönlich bin dazu aber emotional nicht gebunden.:D

    Aus Konvertierungssicht würde ich wie gesagt die 144 Linien durchaus begrüßen. :)

    Welches Tool nutzt Du im letzten Schritt für die Konvertierung nach Multicolor? (Evtl. gibt es ein gutes für die Kommandozeile? Dann wäre es möglich 100 Bilder unkompliziert auf einen Schlag zu konvertieren.)

    Noch nicht final, vermutlich aber Retropixels online. Alles Handarbeit, auch die Schritte vorher in Photoshop.:whistling:

    Die von Dir genannten Konvertierungsprogramme probiere ich aber gerne aus.

    mfg Tobias

  • Mit z.B. NUFLI könnte man die EGA-Fassung (scheint nach etwas "Recherche" auch die Urfassung aller SoMI Versionen zu sein) fast 1:1 umsetzen.

    Die Unterscheidung der beiden Helligkeiten für cyan und magenta in EGA fällt weg, und einige Color Clashes wird es noch geben.

    Aber ich verstehe, dass dieses Format außer für "passive" Bilder leider eher ungeeignet ist.


    Aus Konvertierungssicht wäre die Erweiterung von 96 auf 144 Linien auch bei Multicolor ein deutlicher Qualitätssprung.

    Pro: Das NUFLI müsste nur über 144 Pixel gehen.
    Contra: Die Frage ist, ob man einen Mauszeiger auf der Grafik darstellen kann und, ob transparenter Text möglich ist.

    Es gibt einige Alternativen zu NUFLI:

    Erst das modifizierte original Bild, d.h. die Farben etwas dunkler gemacht, damit nicht soviele auf engem Raum sind:
    Bitte melde dich an, um diesen Anhang zu sehen.

    EHires: trans. Text ohne Clashes möglich, falls die Farbe korrekt gewählt wurden, bspw. Ink = schwarz.
    Bitte melde dich an, um diesen Anhang zu sehen.

    MC: Hires-Text nur über Sprites lösbar

    Bitte melde dich an, um diesen Anhang zu sehen.

    AFLI (Godot mit unmodifiz. Bild):

    Bitte melde dich an, um diesen Anhang zu sehen.

    MUSC-V1: gefällt mir rein techn. am besten von den alternativen Grafikmodi
    Bitte melde dich an, um diesen Anhang zu sehen.

    MUSC-V2: Evtl. Flicker mit zus. Maussprite ?

    Bitte melde dich an, um diesen Anhang zu sehen.


    Ich habe mir bereits Quellen zu NUFLI herausgesucht und angeschaut, aber das Thema scheint mir zu kompliziert.
    Evtl. gibt es irgendwo einen Viewer der gut erklärt ist. Dann könnte man schauen, ob sich das Format nutzen lässt.
    Das Problem mit dem Mauszeiger bleibt m.M.n. jedoch bestehen.
    Wenn man sich einen Schritt von der SCUMM-UI entfernt, könnte man auch auf die Maus verzichten und per Keyboard die Befehle wählen.

    Du willst also diese D42-"Engine" umschreiben/verbessern, richtig?

    ((("Wollen" ist übertrieben.)))
    Aber ein Nachprogrammieren würde ich besser finden, weil auch der Spielfluss mit dem scrollenden Text und dem kleinen begrenzten Fenster im aktuellen D42-System geändert/verbessert werden könnte und alles einwenig mehr nach SCUMM, passend zum Threadthema, aussehen würde.
    Emotional bin ich da auch nicht drin.
    Mich interessiert nur, ob man gute Lösungen für bestimmte kleine Probleme finden kann.
    (((Ich habe diesbezgl. ja auch einige Tests gemacht.)))

    Alles Handarbeit, auch die Schritte vorher in Photoshop

    In Photoshop gibt es angeblich auch Batch-Processing.

    Edit:
    Im Anhang ist noch das MUSC-V1-Bild als .prg zum selber anschauen angehängt.
    Ich denke, dass das die einzige einfache Alternative mit Hires-Pixeln zum subjektiv komplizierteren NUFLI ist. (Im Grunde sind damit auch alle Punkte, die ich oben beschrieben habe umsetzbar, falls ich nichts vergessen habe...)

    (Ich wollte noch schreiben, dass ich kein Brute-Force o.ä. bei der Konvertierung verwendet habe.)

  • Aber ein Nachprogrammieren würde ich besser finden

    Am Ende muss so ein Nachprogrammieren umsetzbar sein und es muss eben auch jemand machen (wollen/können).

    Es gibt einige Alternativen zu NUFLI:

    Die Bilder sind schwierig miteinander zu vergleichen, da sie teils stark unterschiedliche Paletten in den PC-Screenshots haben.

    Pro: Das NUFLI müsste nur über 144 Pixel gehen.

    Würde das was für die verfügbaren Sprites nutzen? Ich bin kein Programmierer, aber ich glaube NEIN. Die Sprites werden ja nach unten "unendlich" erweitert, ob das Bild da 144 oder 200 Pixel hoch ist, reduziert die Anzahl der Sprites nicht. So mein Verständnis.

    MUSC-V1-Bild

    Gibt's irgendwo ne Übersicht mit den Spezifiaktion zu den diversen Algotech-Formaten? Die txt-Dateien zu den Konvertern sind meist nicht sehr aufschlussreich.

    EHires

    Was ist das?

    AFLI

    Sieht am oberen Bildrand schlimm aus.

    Ich sage es nochmal:
    Klassisches MC über 144 Zeilen fände ich für diesen Zweck eigentlich ausreichend. Klar würde Hiresauflösung besser aussehen. Wenn es dann aber viele Color Clashes gerade an sehr "gleichmäßigen" Bildelementen gibt und wenn das das Programmieren der anderen Elemente ungleich aufwändiger macht, würde ich es hier sein lassen.

    Wie schaut es mit MC-FLI aus? Damit müsste man einige Color Clashes vermeiden können und hätte "ehrliche", C64 typsiche Mutlicolor-Auflösung.

    Nachteil von Hires wäre, dass auch Black Bleeding (deutlich stärker als bei MC) auftritt, wenn z.b. blau mit schwarz gedithert wird. Da säuft das blau fast komplett ab.

    In Photoshop gibt es angeblich auch Batch-Processing.

    Ja so ne Stapelverarbeitung gibt es sicher. Ich benutze das Programm nur Hobby-mäßig und kann z.B. sowas nicht. :)

    mfg Tobias

  • Was sind eure Gedanken dazu?

    Äh...sorry, aber das ist mir dann doch zu hoch...

    da ich nahezu keine c64-Ahnung habe und mich deswegen umso mehr über das D42-System freue, kann ich selbst daran nichts ändern und auch wenn ich es könnte, würde ich es nicht machen wollen.

    Es hat ja schon seinen Grund, warum Stephan Lesch und Tobias Erbsland das System so programmiert haben, wie es jetzt ist.

    Ich habe Stephan auch schon ein paar Mal darum gebeten, kleine Änderungen in der Engine vorznehmen, aber da ging es v.a. um andere Farben für die Ausgabetexte (im Original schwarz auf grau), mehr Textspeicher für das Intro, Änderungen im Scrollspeed usw.

    Vielen Dank für die ganzen Überlegungen, aber aufgrund meiner geringen Kenntnisse begnüge ich mich mit dem vorhandenen System und bin da auch total zufrieden mit.

    Gruß

    Sönke

  • Woow, ich wäre so baff, wenn ihr diese schöne Geschichte in dieses Adventuresystem übertragt! Neu erfunden oder nicht. Beides wäre der Hammer! Es gab ja schon einige Experimente in diese Richtung, aber etwas fertiges habe ich glaube ich, noch niemals gesehen. Meine grosse Hoffnung läge ja da. Wobei ich tatsächlich am schönsten fände, man würde diese bekannten Hintergründe neu interpretieren. Also anpassen.

    Die Strasse zum Beispiel, da könnte man das Muster für die einzelnen Kopfsteine ändern, die Steine vergrössern, bis es passender aussieht, und weniger nach zu groben Pixeln.

  • Wieso nicht einfach schneiden und in MC konvertieren?

    So kann es im D64 System verwendet werden.

    Schneiden finde ich ganz persoenlich unendlich angenehmer als stauchen (autsch...). Das mag Geschmacksache sein, aber einige Menschen (ich zB) reagieren sehr empfindlich auf derart defekte aspect ratios :wink:

    Es sind ja Standbilder und genau dafuer ist das D64 gedacht.

    Einige der EGA->MC Konvertierungen fand ich recht gelungen, um die Stimmung rueberzubringen.

    Natuerlich ist das was anderes als NUFLI oder gar handgepixelte Grafiken.

    So wie D64 kein Scumm ist. Macht ja nichts.

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

  • MUSC-V1: gefällt mir rein techn. am besten von den alternativen Grafikmodi

    Finde ich auch. Gibt es irgendwo eine genaue Spezifikation des Formats? Auch enthusi stimme ich voll zu, plattgedrückt geht gar nicht...

    Arndt

    GoDot C64 Image Processing
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Schneiden finde ich ganz persoenlich unendlich angenehmer als stauchen (autsch...)

    Wie genau?
    D42 (Du meinst das mit D64, oder?) kann 320 (hier 160 doppelt breite) x 96 px darstellen.
    Das Original hat 320x144 px. Wenn wir jetzt nur 96 Zeilen ausschneiden und das A/R beibehalten, muss ich ~214x96px auschneiden. Diese stelle ich dann mit schwarzen Rändern auf 320x96px dar. Was bringt das, außer dass ich 2x 53x96 px verschenke?
    Oder meinst Du 320x96 aus 320x144 ausschneiden? Das hatten wir jetzt schon mehrmals, dass auch so in einigen Szenen zuviel Info verloren geht.

    Je nach Szene durchschnittlich ~120 Linien auf 96 Linien zu reduzieren, halte ich für einen angesichts der Beschränkungen vertretbaren Weg. So geht nur die Hälfte an Originalinhalt flöten und das Bild wird nur die Häfte gequetscht.
    Also "Comic" sieht das nicht so schlimm aus als wenn man das mit einem Foto von echten Menschen/Gegenständen machen würde.

    mfg Tobias

  • Ja, genau das meine ich sollte man (meiner Meinung nach) auf gar keinen Fall machen.

    Sondern:

    einen 320x96 (Doppelpix) grossen Ausschnitt auswaehlen, gut konvertieren. Fertig.

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

  • Weiseigentlich jemand was aus diesem Projekt geworden ist? Das wäre ja eine gute Basis für ein richtiges "Demake": Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um dieses Medienelement zu sehen.

    Bitte melde dich an, um dieses Medienelement zu sehen.

    Bitte melde dich an, um dieses Medienelement zu sehen.

    Bitte melde dich an, um diesen Link zu sehen. Unser Maniac Mansion Remake Projekt

  • Weiseigentlich jemand was aus diesem Projekt geworden ist? Das wäre ja eine gute Basis für ein richtiges "Demake": Bitte melde dich an, um diesen Link zu sehen.

    Indy III - Fake oder nicht Fake, das ist hier die Demo. :) Laut Wiki kam da nix, vermutlich nur ne Grafikdemo oder er wurde im Vorfeld von Lucas zugeklagt. :emojiSmiley-01:

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

    Back to Monkey Island:

    Finde auch, dass "multicolor crop" passend wäre, da man eh nicht rumlaufen kann und ein "authentischer SCUMM Port" nur richtig geil wäre, wenn man die Grafik nahezu 1:1 portieren würde und das fräße Arbeitsstunden ohne Ende.

    Hatten wir ja quasi schon aber hier nochmal im Vergleich:

    Bitte melde dich an, um diesen Anhang zu sehen.

    links: 96p hoher Ausschnitt (Treppe ist im Ansatz zu sehen) - rechts: 144p auf 96p skaliert mit Rändern an den Seiten

    Das Erstellen der individuellen Ausschnitte macht natürlich auch viel Arbeit.

  • 5ace
    Wenn Du das D42 System verbessern / flexibler machen kannst, ist das sicher eine gute Sache und viele werden Dir dankbar sein, solange es rückwärtskompatibel bleibt.
    Das wird aber eher ein mitterlfristiges Projekt werden, oder?

    @all
    Es wird wohl am zielführensten sein, wenn Bolzgramm das jetzt so durchzieht, wie besprochen. Auch mit gestauchten und plattgedrückten Konvertierungen. ;)

    Ich bin der letzte, der nicht immer rummäkelt und es am liebsten 120%ig hätte.

    Aber wenn wir uns da jetzt schon am Anfang verkünsteln, wird es so werden, wie mit den beiden existierenden tSoMI-"Demos" oder dem gerade oben gezeigten Indiana Jones: es wird nie fertig werden. Wird schon seine Gründe haben, dass dem so ist.

    Wenn das Vorhaben gelingt und später mal eine verbesserte D42 Engine exisitert, kann man immer noch eine aufwändigere tSoMI-Version nachlegen.
    Es ist bestimmt schon alleine eine riesen Arbeit, die ganzen "Pfade", Kombinationen usw. zu programmieren. Das alles gibt's dann ja schon und man kann darauf zurückgreifen.

    mfg Tobias