Ausser dass REU und EF zusammen keinen Sinn ergibt....
Wieso das? es geht ja hier nur darum viele Daten unterzubringen und beim EF Oder allgemein im CRT format ist das doch ganz gut Machtbar, oder meinst du wegen der übertrangungsgeschwindigkeit?
Es gibt 871 Antworten in diesem Thema, welches 127.693 mal aufgerufen wurde. Der letzte Beitrag (
Ausser dass REU und EF zusammen keinen Sinn ergibt....
Wieso das? es geht ja hier nur darum viele Daten unterzubringen und beim EF Oder allgemein im CRT format ist das doch ganz gut Machtbar, oder meinst du wegen der übertrangungsgeschwindigkeit?
Ausser dass REU und EF zusammen keinen Sinn ergibt....
Wieso das?
Weil man nicht beides einstöpseln kann ![]()
Tobias ich frag Stephan mal, was er von den ganzen Ideen zu seinem Programm hält.
Ausser dass REU und EF zusammen keinen Sinn ergibt....
Wieso das?
Weil man nicht beides einstöpseln kann
Was so gesehen nicht stimmt, wenn man eine Weiche zur Hilfe nimmt.
Nützt aber nichts, denn REU und EF beißen sich im I/O-Bereich des C64.
Vielleicht kann man sich Abhilfe mit D71/D81 SD2IEC oder sowas schaffen, und dazu dann REU benutzen. ^^'
Vielleicht kann man sich Abhilfe mit D71/D81 SD2IEC oder sowas schaffen, und dazu dann REU benutzen. ^^'
Abhilfe ist da nicht so der passende Begriff, denn irgendwie soll die zu verwendende REU ja sowieso befüllt werden. Es sei denn, es wird eine emulierte REU verwendet (bzw. bestimmte Nachbauten). Dann wäre man prinzipiell weder auf ein eigenes Laufwerk angewiesen, um Daten in die REU zu schaufeln, noch auf zusätzlichen Speicherplatz außerhalb der REU. Die könnte dann nämlich Kapazitäten von 16 MB und mehr haben. EF dagegen "nur" 1 MB. Zugegeben, mit SD2IEC ohne Nutzung von Dxx-Images ginge da auch noch was.
Leute ihr vergesst wohl, das es auch REU Emulation gibt. Jeder der eine 1541 Ultimate besitzt oder einen U64 kann beides nutzen. EF CRT Image UND 16MB REU.
Das so ein Game auf einen Standart gerät mit Disketten nicht umsetzbar ist, sollte klar sein. Eine echte REU hat kaum einer, also bleibt zumindest zum jetzigen Zeitpunkt
als größte Zielgruppe die sowohl REU Programme nutzen kann, als auch ein massenspeicher format nutzt, quasi nur noch diese Kombination über.
Ich denke mal das von denen die z.b. Sonic spielen, die aller meisten das über eine 1541U2+ oder einen U64 tun und eher wenige über eine echte REU.
Und selbst wenn diese sich beißen sollten, gibts immernoch D81 ect.
Leute ihr vergesst wohl, das es auch REU Emulation gibt. Jeder der eine 1541 Ultimate besitzt oder einen U64 kann beides nutzen. EF CRT Image UND 16MB REU.
Ändert nichts daran, daß die beiden sich in die Quere kommen.
Aber war hier nicht mal ein Modul in Entwicklung, das beides vereinen will? Das müßte dann gezwungenermaßen eine Umschaltlogik mitbringen.
Für so Spezialfälle wie U64 und Chameleon wäre es sicher möglich, ein CRT mit REU-Unterstützung zu schreiben. Aber wer will das schon? Sowas würde dann auf keinem echten Modul laufen können.
Leute ihr vergesst wohl, das es auch REU Emulation gibt. Jeder der eine 1541 Ultimate besitzt oder einen U64 kann beides nutzen. EF CRT Image UND 16MB REU.
Ändert nichts daran, daß die beiden sich in die Quere kommen.
Aber war hier nicht mal ein Modul in Entwicklung, das beides vereinen will? Das müßte dann gezwungenermaßen eine Umschaltlogik mitbringen.
Für so Spezialfälle wie U64 und Chameleon wäre es sicher möglich, ein CRT mit REU-Unterstützung zu schreiben. Aber wer will das schon? Sowas würde dann auf keinem echten Modul laufen können.
Aber wäre D81 dann nicht die Lösung??? Das kommt sich doch dann nicht in die Quere und wird von etlichen Modulen und natürlich echter Hardware unterstützt
Eher dann die SD2IEC-Lösung imho. Da Du da kein Größenlimit hast, könnte man darüber auch die größte emulierte REU schnell befüllen - oder man hätte ggfls. auch wieder mehrere .D81, die aber auch nicht 'so einfach' von jedem System emuliert/unterstützt werden, da 'richtige' Floppyemulation eben auch nicht alle Cartridges unterstützen. Oder man müsste dann mit Kernal-Loadern arbeiten, aber bis die eine große REU befüllt haben, hast Du auch lange Zähne.
Für echte Hardware finde ich D81 auch eher problematisch, ich behaupte fast mal, dass es mittlerweile mehr SD2IEC-Lösungen (in den Kreisen, die sich dafür interessieren) gibt, alleine schon aus Kostengründen, wie 1581er Laufwerke.
Eher dann die SD2IEC-Lösung imho. Da Du da kein Größenlimit hast, könnte man darüber auch die größte emulierte REU schnell befüllen - oder man hätte ggfls. auch wieder mehrere .D81, die aber auch nicht 'so einfach' von jedem System emuliert/unterstützt werden, da 'richtige' Floppyemulation eben auch nicht alle Cartridges unterstützen. Oder man müsste dann mit Kernal-Loadern arbeiten, aber bis die eine große REU befüllt haben, hast Du auch lange Zähne.
Für echte Hardware finde ich D81 auch eher problematisch, ich behaupte fast mal, dass es mittlerweile mehr SD2IEC-Lösungen (in den Kreisen, die sich dafür interessieren) gibt, alleine schon aus Kostengründen, wie 1581er Laufwerke.
Ok klingt erstmal Plausibel, aber eine Sache verstehe ich noch nicht ganz. Du sagts das SD2IEC kein Größenlimit hat. Von welchem Dateiformat redest du dann da? Immernoch D81? Ich frage, weil eine 1541U2+ ja auch D81 files kann. Sind diese dann dort aber Größen gebunden? Oder verstehe ich dich da gerade komplett Falsch?
Du sagts das SD2IEC kein Größenlimit hat. Von welchem Dateiformat redest du dann da? Immernoch D81?
Direktzugriff aufs Dateisystem der SD-Karte. Dafür sind keine Dxx-Images notwendig. Genau das meinte ich hiermit:
Zugegeben, mit SD2IEC ohne Nutzung von Dxx-Images ginge da auch noch was.
Um eine emulierte REU zu befüllen, kann man ein REU-Image laden. Macht man bei Bitte melde dich an, um diesen Link zu sehen. etc. schließlich auch so.
Ansonsten ist das SD2IEC durchaus ein sinnvoller Massenspeicher auf C64-Seite. Mit Bitte melde dich an, um diesen Link zu sehen. existiert sogar ein IRQ-Loader, der damit läuft.
Moin Leute,
anbei einmal die Gedanken von Stephan zu euren ganzen Überlegungen zum "Aufbohren" der D42-Engine
ich find's toll, dass da so eine Begeisterung entsteht, und wie sich die ganzen Leute für die Grafikkonvertierung reinknien.
Prinzipiell sollten die meisten Vorschläge realisierbar sein, wenn man die nötige Arbeit investiert. Wahrscheinlich geht nicht alles gleichzeitig...
Ich hätte z.B. gern einen schnelleren Lader drin, und REU-Support wäre auch fein. Fragt sich, wer das alles macht - ich werd's nicht sein.
Zu den Spekulationen über das Datenformat und die Speicherbelegung: Im Buch ist das Datenformat ja beschrieben, im Prinzip sollte man damit einen eigenen Player schreiben können. Ich hoffe, ich habe keine groben Bugs in der Beschreibung...
Wenn sich jemand dranmachen will, kann er auch gern den Sourcecode haben. Das ist ein leidiges Thema - das System sollte von vorn herein Open Source sein, aber als es dann draußen war, kam gleich das nächste Projekt, und seitdem schiebe ich es vor mir her, den Source mal "fein zu machen". Ich hätte den gern z.B. auf Github stehen.
Der Source ist halt doch etwas durcheinander - vor ein paar Monaten wollte sich ja mal ein Freund von Jakob dranmachen, das System auf Modul umzuschreiben, und hat es gleich wieder bleiben lassen...
Was man aber auch mal sagen muss: Wenn man dem System eine Scumm-Oberfläche verpasst Texte übers Bild legt, den Lader austauscht usw., dann bleibt außer dem Kern mit der Logik-Abarbeitung nicht mehr viel übrig. Jemand, der das kann, schreibt dir auch gleich eine komplette Custom Engine für Monkey Island. Dann könnte er auch gleich manche Dinge, die du in D42 nicht oder nur über Verrenkungen machen kannst "richtig" einbauen.
Hallo zusammen,
ich les hier auch sehr interessiert mit und finde es super, dass daran gearbeitet wird.
Mir kam noch der Gedanke, ob man vielleicht auch eine Engine aus dem Adventure Wettbewerb von 2015 verwenden könnte. Z.B. die von Caren oder Awakening...
Ich weiß aber nicht, ob da etwas zur Verfügung steht, wie die dokumentiert sind und was es für Tools drumrum gibt.
Aber eigentlich ja sehr schade, die Engines nicht für mehr Spiele zu verwenden.
Nur so ne Idee...
🙋♂️
Hallo Leute,
ich habe im Verlauf der Arbeit mit den Bildern von Monkey Island gemerkt, dass bei den 120er Ausschnitten einfach zu viele
Details verlorengehen (außer bei den close-ups der Gesichter) und deswegen befinden sich im Pack 5 nur ein neues Bild,
dafür aber alle bisher als 120er ausgeschnittene Bilder noch einmal im 96er Format.
Sorry, dass ihr jetzt noch einmal alle diese Bilder bekommt. In Zukunft wird dann alles außer den close-ups auf 96 Pixel
ausgeschnitten. Die Verluste der Bild-Infos sind eindeutig zu verschmerzen.
Gruß
Sönke
Bolzgramm Sofern jemand aber dabei geht, das zu pixeln, ist das nachteilig. Bspw. im linken Teil der Scumm-Bar ist der Typ an dem Leuchter dann nicht mehr ganz drauf, Kopf abgeschnitten. Wenn man einen größeren Ausschnitt hat, kann man den dann noch etwas nach unten kopieren. Und wenn Guybrush vor etwas Detailreichem steht, wäre ein zweiter Shot gut, wo er woanders steht. Dreifach (so wie bei den Bildern vor Stan's pov) ist allerdings nicht nötig, weil mit zwei unterschiedlichen Positionen von Guybrush ja schon alles freigegeben ist. Wie kommst Du eigentlich an die Bilder?
atomcode oh. Ich dachte, ich hätte in der scumm bar links so ausgeschnitten, dass der Kopf
vom Leuchter-Typ noch drauf ist. Guck ich noch mal nach.
Ich komm an die Bilder, indem ich die EGA Version spiele und dann an den entsprechenden Locations Screenshots mache.
atomcode oh. Ich dachte, ich hätte in der scumm bar links so ausgeschnitten, dass der Kopf
vom Leuchter-Typ noch drauf ist. Guck ich noch mal nach.
Ich komm an die Bilder, indem ich die EGA Version spiele und dann an den entsprechenden Locations Screenshots mache.
Es gibt da aber auch ein Tool für, mit dem man die Hintergründe Anzeigen und Rippen kann.
Heisst Scumm Revisited: Bitte melde dich an, um diesen Link zu sehen.
Edit: Hab gerade mal Probiert. Bei der VGA VErsion funktioniert es einwandfrei, bei EGA mache ich entweder was Falsch, oder benutze die Falsche version.
Ich habs mal umgekehrt gemacht und die VGA Version durch nen Upscaler gejagt ![]()
Bitte melde dich an, um diesen Anhang zu sehen.