Neue SCUMM-Engine für C64

Es gibt 76 Antworten in diesem Thema, welches 13.646 mal aufgerufen wurde. Der letzte Beitrag (3. Oktober 2008 um 17:31) ist von matthes.

  • Zitat

    könnte man nicht "einfach" die scumvm auf den cevi portieren und dann die daten der anderen plattformen nutzen? also zb die amiga files der DOTT version auf dem cevi mit der "neuen" scum nutzen?

    das würde ich schnell vergessen :)

  • ich hatte ja nicht nur auf eine neues spiel gehofft sondern auch auf die möglichkeit eben andere für scumvm zu zocken.

    eine auswahl vor beginn des spiels (oder automatische erkennung) wäre SUPER!

    zb:
    1541
    1581
    sd2iec
    iec2ata
    ide64
    cmd HD

    und reu:
    512
    1mb
    2mb
    4mb
    16mb

    auf jedenfall sollte es vom medium her recht unabhängig sein. nur auf 1541 bringt nichts denke ich.
    1581 haben nicht allzuviele
    dann eher die möglichkeit einfach ein laufwerk (Bitte melde dich an, um diesen Link zu sehen. oder Bitte melde dich an, um diesen Link zu sehen.) anzugeben oder gar einen pfad
    so könnte man entweder disks wechseln oder halt einfach alle files in einen ordner auf sd2iec oder iec2ata etc kopieren.

    zudem wäre eine möglichkeit nicht nur von ID9 zu zocken echt praktisch. denn ne 1581 haben die wenigsten als Bitte melde dich an, um diesen Link zu sehen. laufen denke ich.
    denke das könnte man ggfs halt mit angabe der nummer zu beginn des spiels machen


    @sauhund
    war mir irgendwie klar :D
    aber da ich nicht weiß was dahinter steckt dachte ich, fragen kostet nix!

  • Allein schon wegen der Grösse der Grafikdaten von 16+ -Bit Computern (Die ganzen vielen Farben, höhere Auflösung etc., von denen man am C64 gar nix hat) dürfte das problematisch werden. Aber wozu soll das auch gut sein, die Amiga-Versionen z.B. gehen ja eh schon mit ScummVM für PC, (fast) ohne grafische Einschränkungen...

  • Wieder etwas vergessen:

    Das könnte man dann vielleicht im Extremfall so machen daß man Dateien verwendet die 156K an einem Stück sind. Die Verwaltung wird dann innerhalb dieser Dateien gemacht, [...]


    Stichwort IFFL. Dazu habe ich auf die Schnelle leider keinen Link zur Erklärung gefunden. Auch nicht im C64-Wiki. Kurz gefaßt, damit sollte das, was Du Dir diesbzgl. vorstellst, möglich sein.

  • IFFL ist eigentlich ne dumme idee wenn man verschiedene typen von laufwerken unterstützen will, das funktioniert auf allem was keinen direkten sektorzugriff bietet überhaupt nicht. wenn man das will (also alle möglichen laufwerke unterstützen) gibts zu normalen einzelnen files keine wirkliche alternative.

  • IFFL ist eigentlich ne dumme idee wenn man verschiedene typen von laufwerken unterstützen will, das funktioniert auf allem was keinen direkten sektorzugriff bietet überhaupt nicht. wenn man das will (also alle möglichen laufwerke unterstützen) gibts zu normalen einzelnen files keine wirkliche alternative.


    Wie wäre es mit relativen Dateien? :wink:

    10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    20 forj=1to5:printchr$(rnd(1)*16+70);:next
    30 printint(rnd(1)*328)-217

    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.

  • dann eher die möglichkeit einfach ein laufwerk (Bitte melde dich an, um diesen Link zu sehen. oder Bitte melde dich an, um diesen Link zu sehen.) anzugeben oder gar einen pfad

    Also das aktuelle Laufwerk in abzufragen ist ja schon in BASIC kein Problem, das geht mit PRINT PEEK(186). Ob es jetzt so sinnvoll ist, alle angeschlossenen Laufwerke (Können von 8-29 gehen) abzusuchen ob da eine bestimmte Datei drauf ist weiß ich nicht. Außerdem haben viele User an unterschiedlichen Geräteadressen unterschiedliche Laufwerke, und ein Spiel zur Hälfte auf 5,25" und 3,5"-Disketten zu halten ist wäre etwas konfus... :gruebel

    Könnte man ein ähnliches VLIR-ähnliches Dateiformat wie bei GEOS nutzen? Die daraus resultierende Datei (z.B. USR) muß dann allerdings mit einem normalen C64-Kopierprogramm kopierbar sein, nicht wie bei GEOS.

    2 Mal editiert, zuletzt von Naquaada (1. Oktober 2008 um 00:25)

  • IFFL ist eigentlich ne dumme idee wenn man verschiedene typen von laufwerken unterstützen will, das funktioniert auf allem was keinen direkten sektorzugriff bietet überhaupt nicht. wenn man das will (also alle möglichen laufwerke unterstützen) gibts zu normalen einzelnen files keine wirkliche alternative.


    Verdammt, an Kompatibilität habe ich jetzt natürlich nicht gedacht. Dabei fällt mir ein: Funktioniert IFFL i.d.R. eigentlich auf einer 1581? Das hab ich nie getestet.

  • Könnte man ein ähnliches VLIR-ähnliches Dateiformat wie bei GEOS nutzen? Die daraus resultierende Datei (z.B. USR) muß dann allerdings mit einem normalen C64-Kopierprogramm kopierbar sein, nicht wie bei GEOS.


    Interessante Frage, da VLIR m.W. das Standardformat unter GEOS ist. Und für GEOS gibt es ja schließlich Anpassungen an alle möglichen Laufwerke. Wie ist das da gelöst?

  • Interessante Frage, da VLIR m.W. das Standardformat unter GEOS ist. Und für GEOS gibt es ja schließlich Anpassungen an alle möglichen Laufwerke. Wie ist das da gelöst?

    Gar nicht. Die "Floppy"-Treiber von GEOS arbeiten auf Track/Sektor-Ebene, ohne eine Emulation davon läuft nichts. Mit Dateien an sich kommt man da nicht weiter. Natürlich kann man spezielle Treiber für das jeweilige Laufwerk schreiben, die "sehr viele" Tracks und Sektoren nutzen, aber schön ist das nicht.

    Mein Senf zum Thema "Zak McKracken und Co. mit modernen Laufwerken nutzbar machen": REU unterstützen, Diskettenimage da reinladen und daraus "nachladen". Wird bei der C64DTV-Version von Zak McK so gemacht, klappt prima, ist schnell und macht kaum Programmieraufwand. Keine REU? Pech. Sind immerhin heutzutage leicht zu bekommen oder zu bauen.

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

  • @trb: heute ist wirklich dein Tag der Doppelposts, hm :wink:

    Wie funktioniert denn das ältere LucasFilm-Games-Dateiformat auf dem Amiga mit den ganzen .LFL-Dateien? Zusätzlich gab's dann noch eine Datei mit dem Namen 'Disk X Rooms here.info' um zu zeigen welche Diskette vorhanden war. Eigentlich ziemlich unsichere Sache :wink:

    Auf jeden Fall sollte man auch bei Einzelfiles die Grenze von 156K pro Disk nicht überschreiten damit die Daten auf allen Laufwerken verwendet werden können. Auch die Anzahl der Dateieinträge ist zu bedenken. Die 1581 kann zwar 5 x die 156K speichern, hat aber nur 296 Directoryeinträge. Also sind mehr als 59 Dateienträge pro 156K-Disk nicht drin. Damit würde eine durchschnittliche Dateigröße von 2,63K rauskommen, also etwa 10-11 Blocks. Damit wäre man recht flexibel denke ich. Wenn das Game natürlich umfangreich wird und zwei 1581-Disketten benötigt hätte man in einer HD Native-Partition schon fast 600 Dateieinträge... :freak Allerdings werden viele Dateien wohl größer als 10 Blocks sein.

    3 Mal editiert, zuletzt von Naquaada (1. Oktober 2008 um 00:38)

  • Gar nicht. Die "Floppy"-Treiber von GEOS arbeiten auf Track/Sektor-Ebene, ohne eine Emulation davon läuft nichts. Mit Dateien an sich kommt man da nicht weiter. Natürlich kann man spezielle Treiber für das jeweilige Laufwerk schreiben, die "sehr viele" Tracks und Sektoren nutzen, aber schön ist das nicht.


    Also ist IFFL im Grunde an VLIR angelehnt? Von CMD-Laufwerken läuft das dann also auch nur über die entsprechende Emulation.


    Mein Senf zum Thema "Zak McKracken und Co. mit modernen Laufwerken nutzbar machen": REU unterstützen, Diskettenimage da reinladen und daraus "nachladen". Wird bei der C64DTV-Version von Zak McK so gemacht, klappt prima, ist schnell und macht kaum Programmieraufwand. Keine REU? Pech. Sind immerhin heutzutage leicht zu bekommen oder zu bauen.


    Eine REU geht auf eBay aber immer noch zu hohen Preisen weg. Andere (mehr oder weniger günstigere) Möglichkeiten ohne originale REU gibt es natürlich. Aber das ist m.E. auch nicht Sinn der Sache, aus Diskimages von der REU nachzuladen. Das mag in dem Fall Zak und DTV eine gute Lösung sein. Bei einer Neuentwicklung würde zumindest ich mir wünschen, daß die Hardware besser unterstützt wird.

  • Gibt es nicht noch den GeoRAM-Nachbau NeoRAM? Ist es auch mit einer GeoRAM möglich ein Scrollen großer Bildbereiche zu ermöglichen oder ist dazu der DMA-Chip der 17xx REU nötig? In so einem Spiel kommen ja dann richtige Grafiken vor, so ein 'Graphics Construction Kit' mit Grafik-Modulen á là Katakis wird nicht funktionieren. Für Grafik- und Sounddaten wäre eine REU natürlich sehr gut geeignet, um sie schnell abrufen zu können. Vielleicht sollte das auch der Hauptzweck der REU werden, daß solche Daten dort abgelegt werden. Wer keine hat, muß die Grafiken erst jedes mal neu laden.

    3 Mal editiert, zuletzt von Naquaada (1. Oktober 2008 um 00:48)

  • naja wer ne ide64 hat wird wohl auch ne reu kaufen können

    wer ne 1541u+ hat, hat eine
    wer die neue hardware von IC kauft, hat eine

    anfangs war sogar in der abstimmung die angabe scpu möglich... nun solls an ner reu scheitern?

    @naquadaa

    ich meinte ja nicht den bus absuchen! ne einfache angabe vom laufwerkstyp und ID# wäre doch simpel und machbar und würde arbeit ersparen denke ich.

    ich wünsche mir ne version mit REU unterstüztung weil ich denke das dann nicht mehr geladen werden muß und das spiel flüssiger wird. (keine wartezeiten für diskwechsel oder andere sachen)
    dazu halt 1581, iec2ata, sd2iec, 1541
    1541 hat jeder, zudem ists dann möglich von 1541u zu zocken
    sd2iec ist sehr günstig zu bekommen bzw zu bauen
    iec2ata ebenfalls sehr günstig als bausatz erhältlich
    nur die 1581 ist halt was teurer, aber dafür original commodore

    ide64 + CMD HD sind teuer und selten bzw nicht mehr erhältlich. somit würde ich die raus lassen.

    was man auch überlegen könnte wäre eine "füllung" der reu zb über rr-net oder ethernet der 1541u+ (die neue)
    alle daten direkt reinballern udn go. kein laden mehr. aber das sind nur so überlegungen

    zudem wäre es mehr als geil wenn man so ein game zu zweit spielen könnte, aber das würde den rahmen mehr als sprengen.

  • Also die Abfrage des aktiven Laufwerks, des Laufwerktyps der Commodore- und CMD-Floppies bis hin zur CMD HD ist einfach. Ich mache das in BASIC immer über den Floppykanal. Nur bei den neueren Laufwerken kenne ich mich nicht mit aus.

    Wenn man Standard-Dateien verwendet, ist das Laufwerk eigentlich egal, das Programm muß allerdings wissen, welche Daten es in welcher Datei zu finden hat. Bei einer Verwendung von Einzelfiles hat man übrigens einen Vorteil: Bestimmte Dateien können doppelt auf einer Diskette vorkommen. Wenn man diese Dateien z.B. im Format Disk.Nummer (also z.B. MONKEY5-PART1.23) speichern würde, könnte man häufig benötigte Dateien auf mehreren Disketten ablegen. Das könnte Diskwechsel bei kleineren Laufwerken einsparen. Beim Kopieren aller Disks auf ein größeres Laufwerk würden die doppelten Dateien überschrieben werden. Das Ganze setzt dann natürlich schon allein bei der Erstellung des Spiels eine ziemliche Logistik voraus. Bei Monkey Island 2 war es so, daß man während des Intros, als Guybrush da mit seiner Schatztruhe am Seil hängt, nochmal kurzzeitig Disk 10 einlegen mußte. Nicht so super gelöst...

    Zu zweit spielen kann man ja so ein Game kaum, man kann ja nur jeweils einen Mauszeiger im Spiel haben. Allerdings KÖNNTE man ein Spiel kreieren, wo zwei Charaktere vorkommen, wie z.B. Indy und Sophia in Indiana Jones and the Fate of Atlantis, die unabhängig voneinander gesteuert werden können. Das würde aber dann wohl zwei miteinander gekoppelte Rechner voraussetzen und es dürfte äußerst schwer werden, den Spielverlauf dann denentsprechend anzupassen, weil beide Spielfiguren den Spielablauf beeinflussen. Besipielsweise könnten beide Spieler versuchen einen Gegenstand zu nehmen, aber nur einer kann ihn bekommen. Und was der damit anstellt könnte völlig andere Ergebnisse bringen als wenn der andere Charakter ihn bekommen hätte. Das ist sehr schwer das zu koodinieren, und dann auch noch auf zwei Rechnern gleichzeitig. Die Bildschirmausgabe müßte auch auf beiden Rechnern in bestimmten Situationen synchron ablaufen, es wäre ein irrer Programmieraufwand. Trotz allem: Faszinierend wäre diese Idee schon! :bgdev

  • hehe, so ein spiel für 2 player zu basteln wäre sicher interessant - ABER würde das ganze schon viel komplexer machen, besonders wenn man ein spiel im lucasarts stil haben will (in dem man zb niemals "sterben" oder sich so verrennen kann das das spiel unlösbar wird - letzteres ist mit die schwierigste sache bei dem ganzen). bei zwei (oder mehr) spielern landet man dann schnell bei einem andren spielprinzip das eher richtung action-adventure geht, sowas wie spy vs spy zb.

  • Im kleinen Maßstab könnte man das schon machen, z.B. wenn in einem Indy-Nachfolger die Klopp-Szenen kommen, da könnte der andere Spieler zum Joystick greifen und anstelle des Computers spielen. Ist nur frustrierend wenn man dann einen Gewinner der IK+Competition hat... Auch für 'Beleidigungsschwertkämpfe' wie in Monkey Island könnte ein zweiter Spieler kurzzeitig einspringen und den Gegner übernehmen. Wie wird ein Multiplayerspiel mit mehreren Rechnern überhaupt aufgebaut, z.B. Wizard of Wor Tournament. Wird der Userport dafür benutzt?

  • Allerdings KÖNNTE man ein Spiel kreieren, wo zwei Charaktere vorkommen,

    das meinte ich

    eher wie in maniac mansion wo man mehrere charaktere hat

    dort nimmt man auch mit jedem was anderes auf und teilweise gibt man es dem nächsten damit der es verwendet.

    2 leute könnten jeweils eine der 4 personen spielen. oder gar 4 spieler-netzwerk

    das das ganze mehr als schwer wird ist klar... war ja auch nur son traumgedanke. denke nicht das es wirklich umsetzbar ist, außer vielleicht als richtig kommerzielles game mit ordentlich aufwand

  • oder gar 4 spieler-netzwerk

    So mit Hardware-Zweckentfremdung gebaut. Eine kleine Hardware für den Userport mit einem Netzwerkstecker, dann in einen LAN-Switch rein und auf mehrere angeschlossene Rechner verteilen. Goile Sache! :tanz:Aber ich möcht' mal den Programmierer sehen der das realisieren könnte! Obwohl... bisher wurden wir stets eines besseren belehrt, auf dem C64 scheint ja alles möglich zu sein.