Posts by 5ace

Jive
Ich habe einige kleinere Dinge geändert bzw. mir überlegt. (...)
Ich werde die Änderungen demnächst präsentieren.

Quote from Retrofan

Mein Plan wäre:

1) Der Text sollte kompatibel zu modernen PCs/Macs sein, daher nicht PETSCII, sondern ISO 8859 (also ASCII mit internationaler Erweiterung) und Plaintext ohne irgendwelchen Steuercodes. Allenfalls Markdown sollte zur Formatierung erlaubt sein, da klartextliche "Tags" ohne problematische Konvertierung. So kann man ein und den gleichen Text abwechselnd mit C64 und PC bearbeiten und letztendlich vom PC aus drucken oder per Mail verschicken oder was auch immer.

2) Es wäre nicht unrealistisch, auf dem C64 einen PDF-Output zu generieren. Ein Minimal-PDF-Header ist sehr überschaubar (mit PS vergleichbar), der Rest ist auch wieder Plaintext. In Kombination mit einer Netzwerk-Verbindung (ich denke dabei vor allem an das WiC64, also WiFi) könnte man so ein Minimal-PDF wahrscheinlich zu einem modernen Netzwerkdrucker schicken, der auch Druckaufträge von iOS-Geräten oder Androiden entgegen nimmt. Das funktioniert ohne Treiber oder Konfiguration.

Auch gut erklärt. Also soll es ein Textverarbeitungsprogramm/Editor werden?

Quote from Retrofan

Ja, im Prinzip wäre das schon, was die meisten Anforderungen erschlagen würde. Bei der Zeilenhöhe wäre es noch toll, wenn man irgendwie neben 8 auch 16 px hinbekommen würde. Das wäre für manche GUI-Sachen klasse. Also 8 px hohe Zeichen mittig in 16 px gelegt. Das müsste aber nicht unbedingt gescrollt werden und könnte notfalls statisch bleiben.

Die Routinen von TD1334 können das ja bereits. Er hat es mit seiner Demo bewiesen.
(Und ohne horiz. Scrolling ist die Darstellung einer Textdatei noch sehr viel einfacher.)

Ich selbst bin kein Fan von doppelt hohen Zeilen, weil ich finde, dass alles minimalistisch umgesetzt werden sollte/muss; aber das ist ja auch nur Geschmackssache und subjektiv.
(...)
Meiner Meinung nach gibt es 2 Wege: entweder man versucht sich an einem Programm oder an einem OS.

Quote from JamiroDrache

Der Punkt für mich wäre: Der C64 könnte verschiedene Fonts, ggf. noch kleine Bilder im Text. Aber dann? Drucken würde ich es nicht, da kein Drucker passt bzw. was macht man damit? Am 68k Mac kann man daraus ein PDF erzeugen und das Ganze weitergeben. Und am C64?

Ich möchte hier keine Stellung beziehen, oder Partei für oder gegen die Aussage ergreifen, ob das Drucken direkt vom C64 aus möglich ist.

Evtl. bin ich auch nur einwenig naiv, was die Druckfunktion angeht.

Die "Druckfunktion" ist für mich erstmal einfach nur ein Programm, welches die Daten (Text + Zeichensatz und/oder Grafiken) erhält und an den "Drucker" sendet.
"Drucker" bedeutet hier an irgendeinen Port o.ä..
Es könnte ja auch eine Datei sein oder direkt eine Übertragung durch irgendeine Hardware irgendwo hin.
(((Ich wäre bspw. schon zufrieden, wenn eine Bitmap o.ä. als Ausgabedatei erstellt werden würde/könnte.
Zur Info: Ich selbst "arbeite" nicht mit oder am C64, sondern nutze nur den Emulator hobbymässig, d.h. um zu schauen, auzuprobieren und darüber nachzudenken/fantasieren, wie oder ob man etwas besser umsetzen kann oder könnte. etc...)))

Wie dieses Programm arbeitet, bleibt ihm selbst überlassen.
1.) Es gibt/gab eine Centronics-Schnittstelle für den C64. Im C64-Wiki gibt es sogar ein Programmbeispiel: https://www.c64-wiki.de/wiki/Centronics-Schnittstelle
2.) Eine kurze Google Suche hat ergeben, dass es angeblich noch Drucker mit Centronics Schnittstelle geben soll: https://windowsreport.com/parallel-port-printer/

3.) Es gibt sogar Centronics-zu-Usb Adapter. Ob diese Verbindungen miteinander funktionieren würden, weiß ich nicht.

Zum Format/zur Sprache für die Druckeransteuerung:
4.) Angeblich gibt es noch Drucker, die ESC/P verstehen können sollen: https://www.c-nw.de/drucker-mf…prachen/esc-p-raster.html (Hier kann man auch nach anderen Druckersprachen filtern.)
5.) im Internet existieren auch Beispiele/Beschreibungen für HP PCL u.ä..

Ich denke mir, dass wenn ein DOS-Rechner mit Assembler oder C, ohne zusätzliche Treiber, einen Drucker über LPT 1 ansteuern kann, dass dies dann auch mit dem C64 möglich sein sollte.
Ob das wirklich funktioniert, weiß ich nicht.
Ich würde die Möglichkeit jedoch nicht einfach ausschließen.

Ob man das dann überhaupt nutzen möchte oder würde, ist wieder eine ganz andere Frage.
Für mich bleibt die "Druckfunktion" erstmal nur ein externes Programm, welches "irgendetwas" mit den Daten anstellt.
----
Das sollte jetzt alles keine Kontra Auflistung sein, sondern Deine Frage ist schon berechtigt: Die Frage nach dem "Wozu?"
Meine Antwort wäre: Um zu sehen, ob es möglich ist.

Quote from Retrofan

In dem Text wurde schon gesagt, dass man mehre Zeichen aus dem Puffer gleichzeitig zeichnen könnte, wenn das Rendern mit der Eingabe nicht mitkommt. Ich würde noch die Idee beisteuern, dass man, solange zügig getippt wird, nur die aktuelle Zeile aktualisiert (und zwar vielleicht auf Bitmap-Zeilen-Basis, nicht durch Neuzeichnen der einzelnen Zeichen) und gegebenenfalls Text rechts heraus schiebt – und erst bei der nächsten kleinen Eingabe-Pause dann der Absatz aktualisiert/umbrochen wird.

Das ist in etwa auch das Vorgehen, das ich vorgeschlagen hätte.
Man sieht es konkret unter Windows Write 3.10 unter folgendem Link: https://www.pcjs.org/software/pcx86/sys/windows/3.10/ (Einfach Doppelklick auf die "Read Me"-Datei.)
(Und etwas schlechter bei Windows 3.11 unter folgendem, weil die Emulation etwas schneller ist: https://classicreload.com/win3x-windows-311.html )

Es gibt also 3 (?) unterschiedliche Arten von Refreshs bei Tastatureingaben:
- Bei sehr wenig Zeit: An der Cursorposition werden nur die neuen Zeichen gerendert und alles rechts vom Cursor in der aktuellen Zeile wird bitmapmäßig einfach nach rechts bis max. an den Bildschirmrand geschoben.
- Bei wenig Zeit: Nur die aktuelle Zeile wird gerendert und, falls die nachfolgende Zeile durch das Erreichen des Zeilenendes oder von einem Zeilen- oder Wortumbruch betroffen ist, wird die nächste Zeile mit gerendert. (Die alte Zeile wird einmal gerendert und die Ausrichtung wird sichtbar, da sie ja durch einen Zeilenumbruch "abgeschlossen" ist. Insgesamt werden also max. 2 Zeilen gerendert.)
- Nach einer kurzen Pause: Es findet ein Rendering von der ersten veränderten Zeile bis nach unten an den Bildschirmrand statt. (Hier könnte man auch evtl. nur bis an den nächsten Absatz gehen.)

Bei Scrolling nach oben oder unten: Der vorhandene brauchbare Bildschirmteil wird bitmapmäßig verschoben und es wird nur der neu hinzugekommene, vorher nicht sichtbare, Teil gerendert. (Ist ja auch einleuchtend.)
Bei Scrolling nach links oder rechts, wird der bereits vorhandene Teil einmal bitmapmäßig verschoben (=wahrscheinlich ergibt sich daraus ein psychologischer positiver Wahrnehmungseffekt) und es findet ein kompletter refresh statt.

Quote from Retrofan

Das ist schon die x-te Disziplin, bei der GEOS unterperformt. Es wurde schon gezeigt, dass man Punkte/Linien 4 Mal so schnell zeichnen kann, wie GEOS es tut. Auch Scrolling ginge viel schneller (zeilenweise, also fast "smooth") und mit REU-DMA (sonst ja von GEOS unterstützt) besonders flink. Wie GEOS Dialogboxen (z.B. Filerequester) zeichnet, ist auch komplett ineffektiv. Da sind so viele Sachen, die man beschleunigen könnte – da würde wahrscheinlich niemand mehr meckern, der Bitmap-Mode sei zu langsam zum "Arbeiten".

GEOS wurde anscheindend so konzipiert, dass es auf externe Speicher angewiesen ist. (Bspw.: Fonts als VLIR und beim Erstellen einer neuen Datei wird sie gleich angelegt und es wird Speicherplatz auf der Disk reserviert.)
((( Richtig: Die Dialogboxen sind ein Alptraum Aber hey, es war 1985. )))
Für schnelles Scrolling wäre auch die Simulation einer Bitmap mit 24 Zeilen (zweifarbig) im Textmodus interessant.

Quote from Retrofan

Wenn es wirklich um eine Realisierung gehen würde, dann bräuchte ich persönlich z.B. keine unterschiedlichen Schriftgrößen und -arten oder WYSIWYG im engeren Sinn. Ich würde mit Plaintext (ISO-Encoding) arbeiten und Formatierungen (wenn überhaupt) über Markdown realisieren (was man dann rendern könnte – oder eben auch nicht).

Also etwas in der Art des "hires grafik scrollen möglich"-Programms von Acorn nur mit Eingabemöglichkeit?
(Ich meine Zeilenabstand 8 Pixel. Müsste man in Deiner Vorstellung den Bildschirm horiz. scrollen können?)

--------------
Bsp-Formel zum Zeichensatz:
Gesamtgröße = ((Summe der Zeichenbreiten in Pixel) / * 8 Zeilen + 3*Anzahl der Zeichen + sonst.Headergröße
Angenommen der Zeichensatz hat 102 Zeichen und die Zeichen wären (nur als Abschätzung) 8 Pixel breit, dann würde sich daraus ergeben:
826 + 306 = 1102 Bytes, d.h. kleiner als 2048, weil die leeren Zeichen nicht im Font gespeichert werden. Wie sie intern bei der Verwendung repräsentiert werden, kann natürlich wieder ganz anders aussehen.

Retrofan

Die gesamte Thematik rund um GUI/OS und möglichen Anwendungen inkl. Textverarbeitungsprogramme ist sehr spannend.
Ich könnte seitenweise darüber schreiben.

Quote from Retrofan

Aus meiner Sicht wäre das eine gute Basis für einen Font-Renderer, wie ihn GEOS verwendet, also für den WYSIWYG-Gebrauch, bzw. irgendwas DTP-artiges. Über ein Programm für einen solchen Renderer könnte man mal nachdenken.

Ja, mich hat interessiert, was speicherplatztechnisch möglich ist und wollte auch mal "Arial", "Helvetica" usw. auf dem C64 sehen.

Mit .ttf-Fonts würde der C64 auch ein Stück weiter "up-to-date" wirken.
Zum Speicherplatzverbrauch: Im Programm "bmfont" kann man noch die spacings auf 0 setzen, d.h. man würde evtl. noch einige wenige Bytes einsparen.

Quote from Retrofan

Mir schwebte bisher ja eher ein (beschränkter) Renderer für typische GUI-Aufgaben oder einen No-WYSIWYG-Editor vor, der sich vor allem durch 2 Merkmale hervortun sollte: Performance (auch weil von der Text-Performance die Scroll-Performance abhängt) und geringe Größe. Dafür muss er dann aber auch weniger können: 8x8 px Chars wären das Maximum, das zu rendern wäre. Aber dein Ansatz hat auch was – wie gesagt, vielleicht fällt einem ein Programm ein, das davon profitieren könnte.

Bzgl. Performance:
Alle Bitmap-Textverarbeitungsprogramme/Editoren, die ich mir auf dem C64 angeschaut habe, inkl. Geowrite und Jasword, machen etwas grundsätzliches beim Aktualisieren von Benutzereingaben falsch.
(Tricks, die Geowrite verwendet: https://www.pagetable.com/?p=1490)

Dadurch wird der Trugschluss verstärkt, dass allgemein diese Art von Programmen auf dem C64 lahm sind.
Natürlich dauert ein Fullscreen-Refresh im Bitmap-Modus seine Zeit und es werden auch keine 1000 Seiten á 1800 Zeichen in den 64KB-Speicher passen, aber ein "besseres" Gefühl bei den Eingaben ließe sich m.M.n. durch eine andere Refresh-Strategie einfach realisieren.
(... bei Gelegenheit schreibe ich mehr dazu...)

Bei max. 8x8 Chars hast Du recht bzgl. der Performance. Der Font-Renderer ist dann natütlich auch kleiner.
Bei der Größe des Zeichensatzes selbst, könnte man ja mal ausrechnen, ob Dein Font in dem anderen Format weniger Bytes in Anspruch nehmen würde: 3 Bytes je Zeichen + die Font-Bytemuster (entspr. Anzahl der Zeichen * 8).
(Ich weiß, dass es Dir darum ging, Fonts mit Standard-Tools (8x8 Editoren) erstellen und austauschen zu können.)

Quote from Retrofan

Wie zu erwarten, wird mit Kerning-Tabellen gearbeitet (da die ohnehin in TT- und ähnlichen Fonts verwendet werden und übernommen werden können). Ich hatte auch schon gesagt, dass man das vielleicht auch auf dem C64 ausprobieren könnte, wobei ich Kerning an sich schon fast zu viel für den kleinen 64er finde. Ich habe bei meinem handoptimierten Font die beiden größten Störenfriede (vor allem, wenn sie auf einander trafen), r und a, soweit entschärft, dass sie kein Problem mehr darstellen dürften. Von daher ist, von seltenen Ausnahmen abgesehen, das Schriftbild und der Lesefluss auch ohne Kerning sehr ruhig und angenehm.

Kerning würde bedeuten, dass man nach jedem ausgegeben Zeichen in der Liste nachschauen müsste. Evtl. gibt es hier auch Tricks, aber ich denke, dass man die Umsetzung mal ausprobieren sollte.
Zu Deinem Font: Er ist sehr brauchbar und ich denke auch, dass er noch Verwendung finden wird.

Eigentlich möchte ich noch viel mehr schreiben (...);
Es folgt jedoch ein weiteres Testprogramm, welches diesmal auf Geschwindigkeit ausgelegt ist:
- Es ist noch immer fehlerbehaftet.
- Es zeigt jedoch in etwa die obere Grenze beim Plotten.
-- Die Positionsberechnung könnte noch optimiert werden; das Plotten nicht, d.h.
--- es werden keine Zeropageadressen für die Zeichen verwendet und die Zerichen werden vertikal aufgebaut, d.h. mögliche Font-Effekt wären höchstens "underline" und "strike-through"...
--- zusätzlich werden 4KB für Rotationstabellen verwendet und ein Speicherbereich von max. 8KB ist für Speedcode reserviert. (Pro Pixelhöhe kostet der Speedcode ca. 208 Bytes, d.h. es sind Fonts bis zu einer Höhe von 39 Pixel möglich.)
---- Dadurch hatten nur noch die ersten 5 Fonts Platz im Speicher.

fontsizetest2.prg


Man erkennt den Geschwindikeitszuwachs, obwohl die Zeilen nicht voll ausgefüllt sind.
(...)

--------------------------------------
Edit: Ich wollte Dich noch auf das Programm "Interword" (wegen der GUI) aufmerksam machen, bestimmt kennst Du es bereits.
Ich finde, dass es, bis auf die Wahl der Schriftart/Größe, vom Funktionsumfang inhaltlich Dein Mockup aus dem Thread "Textverarbeitung" Leben füllen könnte.

Moderne Fonts auf dem C64

Mit dem Programm
https://www.angelcode.com/products/bmfont/
lassen sich .ttf Fonts als Bitmap + Metadaten exportieren.

Die Schriftart "segoeui" (mit 219 Zeichen) benötigt nach einer Umwandlung in ein eigenes experimentelles Format folgenden Speicherplatz:

Der Header umfasst hier immer 1290 Bytes je Schriftgröße, wovon je 512 Bytes Pointer für das Kerning enthalten sind.
* = Eine Page (sog. "Texture Page") ist eine Bitmap mit den Bitmustern für die Zeichen des Fonts. "Nicht vollständig" bedeutet hier, dass nur die erste Page berücksichtigt wurde und der Speicherplatzbedarf höher ausfallen würde, wenn mehr Grafikdaten berücksichtigt werden würden. Derzeit wird nur eine Page mit max. 256*8 = 2048 Pixel unterstützt.

Beispiel-Page für "Segoeui" Schriftgröße 12:

Metadaten aus dem "bmfont"-Programm dafür:

Folgendes Testprogramm konnte die ersten 6 Schriftgrößen im Speicher des C64 unterbringen:
fontsizetest1.prg

Kommentare zum Programm:

- Die Speicherplatzbelegung stand im Vordergrund.
- Die Ausgaberoutine ist fehlerbehaftet (Fehler im Shifting; deshalb habe ich auch kein Kerning verwendet, obwohl es einfach ist und möglich, d.h. vorbereitet).
- Die Ausgaberoutine ist sehr allgemein gehalten und deshalb auch sehr langsam. Theoretisch ist eine Fonthöhe von 255 Pixel möglich und eine Char-Breite bis 128 Pixel (oder sogar 255?).
- Der erste Font (Schriftgröße ist kaum lesbar, weil das Ausgangsmaterial bereits schlecht war, d.h. der Font braucht etwas mehr Platz, um gut auszusehen.
- Die wirr dargestellten Zeichen in der letzten Zeile (Schriftgröße 22) sind diejenigen, die auf einer anderen Page liegen würden. (siehe folgenden Screenshot für Schriftgröße 36 aus einem anderen Testprogramm.)

Fazit:

- Die Bitmapgröße ändert sich bei Verwendung weniger Zeichen entsprechend.
Bspw. Schriftgröße 12:

-- 102 Zeichen 740 Pixel breit 1395 Bytes statt 3120 Bytes

-- 95 Zeichen 680 Pixel breit 1275 Bytes

-- 91 Zeichen 653 Pixel breit 1230 Bytes

- Wenn man einwenig Zeit für das Wechseln eines Fonts in Kauf nimmt, kann man
-- den Header für nicht genutzte Zeichen verkleinern.
--- Formel mit Kerning: 10+(5*Zeichen). Formel ohne Kerning: 10+(3*Zeichen).
-- die Bilddaten komprimieren, weil viele 0 Bytes vorkommen. (Wahrscheinlich nur bei größeren Fonts sinnvoll; Das Entpacken müsste schnell sein.)

- Das Kerning (inkl. Header) beansprucht in diesem Format ca. 25%-35% der Gesamtgröße. Es könnte direkt auch anders gespeichert werden, so dass man ca. 1 Byte pro Zeichen, für das ein Kerning angegeben ist, spart. (Hatte ich der Einfachheit halber nicht gemacht.)

- Mehr oder breitere Pages gehen mit einer Vergrößerung des Headers einher. (Wäre sinnvoll für größere Fonts, d.h. ab ca. durchschnittlich 2048/91 = 23 Pixel Breite pro Zeichen. Hier gibt es mehrere Methode. Für eine doppelt breite Page würde man bspw. 256*1Bit = 32 Bytes extra benötigen.)

- Die Geschwindigkeit wäre optimal, wenn beim Wechseln eines Fonts ein Speedcode für den jeweiligen Font generiert werden würde, so dass trotzdem alle Größen möglich sind. (Es gibt nat. noch viele weitere Features, die man einbauen könnte. Stichwort: Fonteffekte.)

Ein durchschnittlicher Font benötigt derzeit also ca. 2 - 2,5 KB ohne Kerning und ca. 4 KB mit Kerning.
(...)

Antwort auf: "kann man 2022 noch produktiv mit dem C64 arbeiten":
Ja, mit der vorhandenen, genannten Software, lässt sich ein Text "retromäßig" erstellen, bearbeiten und evtl. auch einigermaßen ausreichend ausdrucken.
Unter "modernen" Gesichtspunkten, fallen jedoch der Vorgang (Aufwand/Komfort), die Möglichkeiten (Formate/Funktionen) und das Ergebnis (Qualität), negativ zu Lasten des C64 aus.

Ich bin mir sicher, dass auf einem C64 in der Grundausstattung (C64+1541), mit einem neu geschriebenen Textverarbeitungsprogramm,
deutlich "mehr" in den o.g. Bereichen herausgeholt werden kann und auch machbar ist.
(...)

Quote from 5ace

2 Farben pro Hires 8x8 Bitmap-Kachel plus eine Farbe in einer 48x21 "Sprite-Kachel".

Edit: Sollte heißen plus eine freie Farbe... Natürlich hat jedes MC-Sprite 3 Farben.

Quote from Tobias

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.

Quote from Tobias

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 #246 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.

Quote from Tobias

"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.)
https://csdb.dk/release/?id=76055

Quote from atomcode

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.

Tobias
Ich hoffe ich habe Deine Fragen richtig verstanden.

Quote from Tobias

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 MUSC-Hires Converter 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.

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 https://www.lua.org/

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

--------------
Als letztes habe ich das Tool DirMaster 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.

Quote from Tobias

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.

Quote from Tobias

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.

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 TRSE 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:

https://www.loekvandenouweland…-game-that-never-was.html

(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.

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.
(...)

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

http://www.deater.net/weave/vmwprod/monkey/

https://github.com/deater/dos33fsprogs

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

http://www.deater.net/weave/vmwprod/demakes/

http://www.deater.net/weave/vmwprod/peasant/

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

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



mi-scummui-002.d64

- 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.
(...)

Quote from Tobias

Du willst also diese D42-"Engine" umschreiben/verbessern, richtig? So ne Art "ScummVM-ultralight"-D42?

Genau, aber ganz ungezwungen, d.h. sofern Zeit, Lust und Energie da ist, ausprobieren, was machbar wäre.

Quote from Tobias

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

Quote from GoDot

Gibt es irgendwo eine genaue Spezifikation des Formats?

Ich kann mich daran erinnern eine Textdatei gesehen zu haben. Es könnte auf der inzwischen nicht mehr vorhandenen Seite gewesen sein.
Mittels Testbilder und JC64dis hatte ich versucht den Aufbau selbst zu bestimmen.
Nachfolgend eine Tabelle für MUSC oder MUSCU, die für meine Zwecke ausreichend ist/war.
Es sind Lücken im Format vorhanden, die Leer sind; evtl. waren sie für Erweiterungen oder unterschiedliche Versionen gedacht.

Quote from Bolzgramm

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.

Vielen Dank auch, dass Ihr ein solches Projekt in Angriff nehmt. Ich freue mich immer über neue Programme und Spiele und bin schon sehr gespannt auf dieses Adventure.

Quote from Tobias

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.

Meinerseits sind das ja alles auch nur Ideen/Wunschvorstellungen/Tagträume, d.h. die vorhandenen Dateien und die Arbeit/Arbeitsweise Bolzgramm würden ohnehin unberührt/unverändert bleiben.
Ich wollte nur zusätzliche Sichtweisen/Meinungen bzw. Antworten auf die Frage, wo die Präferenzen liegen würden, falls man die Oberfläche doch anders (= "frei") aufbauen könnte.

(((
Weil "Monkey Island" doch sehr umfangreich ist, hatte ich aus neugier jedoch auch konkrete Fragen bzgl. des Umfangs des erstellten Adventures:
- Wieviele Objekte im D42 -System mussten verwendet werden, um die Story unterzubringen?
- Wurden Allgemeintexte und -Bedingungen genutzt (und wenn ja, in welchem Zusammenhang/für welche Funktion)?
- Wieviele Diskettenseiten werden benötigt?
)))

-----
Nachfolgend ein Testprogramm, welches teilweise zeigt, wie eine mögliche MUSC-Oberfläche aussehen könnte und wie die D42-Funktionen in dieser Wunschvorstellung angeordnet wären.
(Was auch nicht ganz stimmt, weil man noch Platz für die Liste der Raumobjekte unten schaffen müsste. Die einzige Möglichkeit, die ich sehe ist, wenn man die Befehle in 2 Spalten statt 3 anordnet. Den Befehl/die Funktion "Umschau" könnte man einfach in die Bildschirmmitte setzen. Was denkt ihr darüber? (Übrigens habe ich den Maustreiber "DuoDriver" von Marco Baye genutzt, d.h. das Fadenkreuz kann durch Maus und Joystick bewegt werden.))



mi-scummui-001.prg

Quote from 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:

EHires: trans. Text ohne Clashes möglich, falls die Farbe korrekt gewählt wurden, bspw. Ink = schwarz.

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

AFLI (Godot mit unmodifiz. Bild):

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

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

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.

Quote from Tobias

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.)))

Quote from Tobias

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.)

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.