Bugreport: bei "kleinen" charsets wird die Ecke oben links nach dem Scrollen korumpiert/gelöscht (bei Zork 3 unter dem E von "Endless" in der Statuszeile).
Zork auf dem C64 mit 53 Spalten
-
Bit Shifter -
9. Februar 2018 um 17:16 -
Erledigt
Es gibt 155 Antworten in diesem Thema, welches 38.174 mal aufgerufen wurde. Der letzte Beitrag (
-
-
Bugreport: bei "kleinen" charsets wird die Ecke oben links nach dem Scrollen korumpiert/gelöscht (bei Zork 3 unter dem E von "Endless" in der Statuszeile).
Ja, ich sehe es - wird gefixt.
-
Es ist ja auch nicht so wirklich fair, wenn wir das heute rückblickend in der Kenntnis der Geschichte kritisieren. ... Zeitgenössisch betrachtet sieht vieles anders aus, hinterher biste immer klüger...
Genau dieses sich Hineindenken in eine bestimmte historische Konstellation mit gleichzeitiger Ausblendung der nachfolgenden Ereignisse ist sehr schwer und führt oft zu hitzigen Diskussionen bei Retrothemen.Bit Shifter: Sorry, wenn wir hier auch etwas ausschweifen. Das soll deine Leistung nicht im mindesten schmälern.
PS: Der oben erwähnte Artikel zu den Infocomics befindet sich in Happy Computer, Ausgabe 7/88, Seite 30 ff.
-
Bugreport: bei "kleinen" charsets wird die Ecke oben links nach dem Scrollen korumpiert/gelöscht (bei Zork 3 unter dem E von "Endless" in der Statuszeile).
Anbei die korrigierte Version ...
-
Könnte man nicht immer die jeweils Aktuellste Fassung in den Startpost Packen? Sonst wirds irgendwann unübersichtlich.
-
Könnte man nicht immer die jeweils Aktuellste Fassung in den Startpost Packen? Sonst wirds irgendwann unübersichtlich.
Würde ich gern machen. Wie kann man den Anhang im ersten Post updaten ?
-
Auf bearbeiten gehen und dann auf "Erweiterte bearbeitung" (Mitte unten)
-
Würde ich gern machen. Wie kann man den Anhang im ersten Post updaten ?
Das kann nur ein Moderator machen, man selber kann seine Einträge nur eine Stunde lang editieren.
-
- Offizieller Beitrag
zork3.d64 aus posting 124 ist nun im ersten Posting.....
Alternativ könnte Bitshifter auch einen link zur neusten Version in seine Bitte melde dich an, um diesen Link zu sehen. schreiben...
sl FXXS
-
- Offizieller Beitrag
Bei Standard ASCII sind doch die ersten 32 Plätze für Steuerzeichen belegt. Die sind also im Font leer. Meine Idee aus dem Browser-Thread war, genau in die "freien" Zeichen die Breiten (als Pixelstreifen, 8 Breiten je Char) abzulegen.
Ist es aber leider doch nicht. Die Breiten liegen bei deinem Font vor jedem einzelnen Zeichen (statt in den freien 32), wodurch Standard-Editoren außen vor sind. Jetzt darf man jeden Font, den man hat, entweder per Hand in deine ASCII-Datei übertragen oder sich selbst einen Konverter basteln. ALeX hat letzteres für mich getan.
Bitte schickt mir Eure selbst erstellten Fonts, damit ich sie auf späteren Images mit drauf packen kann.
Gerne, hier:
-
Ist es aber leider doch nicht. Die Breiten liegen bei deinem Font vor jedem einzelnen Zeichen (statt in den freien 32), wodurch Standard-Editoren außen vor sind. Jetzt darf man jeden Font, den man hat, entweder per Hand in deine ASCII-Datei übertragen oder sich selbst einen Konverter basteln. ALeX hat letzteres für mich getan.
Gerne, hier:
Meine Aussage zur Anordnung der Zeichenbreiten bezog sich auf die Postion im RAM des C64.
Für das Einlesen habe ich nach einer möglichst einfachen Anordnung gesucht und da erschien mir die Speicherung der Breite beim Zeichen selbst das Naheliegendste zu sein.
Ich kenne leider keine "Standard-Editoren", wie Du sie anscheinend benutzt, sondern habe die Zeichen immer mit einem Text-Editor (vim) erstellt.
Auf welche Font-Editoren nimmst Du bezug und wo kann man sie herunterladen ?Danke für Deinen Font.
Er kommt ab jetzt auch auf die Images. Welchen Namen/C64-Filenamen soll er tragen ?
-
Im Code gab es nur ein paar Aufräumarbeiten und Optimierungen.
Außerdem gibt es noch ein 6. Byte in der CONFIG (Cache/Track/Sector Anzeige: 0 = aus, 1 = ein)
Wenn die Cache/Track/Sector Anzeige aus ist, steht eine Zeile mehr für den Text zur Verfügung.
Retrofan hat den ersten Userfont beigesteuert, er heißt FONTB (Bold Font) auf dem angehängten Disk-Image:
Hier ein Screenshot von Retrofans Font:Bitte melde dich an, um diesen Anhang zu sehen.
-
Retrofan hat den ersten Userfont beigesteuert, er heißt FONTB (Bold Font) auf dem angehängten Disk-Image:
Erstklassig lesbar - geile Engine!
-
- Offizieller Beitrag
Meine Aussage zur Anordnung der Zeichenbreiten bezog sich auf die Postion im RAM des C64.
Für das Einlesen habe ich nach einer möglichst einfachen Anordnung gesucht und da erschien mir die Speicherung der Breite beim Zeichen selbst das Naheliegendste zu sein.Ich hatte ja darauf hingewiesen, dass es mir bei der Anordnung vor allem darauf ankommt, dass man übliche Char-Editoren/Konverter verwenden kann und es gibt natürlich keinen Editor, der von 9 Byte je Char ausgeht (1. Byte definiert bei dir die Breite). Ich hatte im 8Bit-Browser-Thread mein Prinzip als Standard-Prinzip für die Speicherung für Proportional-Zeichensätze auf dem C64 vorgeschlagen (nicht nur für Zeichensätze dieses Z-Interpreters – warum für jedes Programm was neues erfinden?), wenn sie von der Codierung her ASCII oder einem ISO-Encoding (z.B. ISO 8859-15) entsprechen. Da sind die ersten 32 Plätze unbelegt (und da unkomprimiert gespeichert wird, kostet es null Speicher, dort die Breitentabellen abzulegen). Einfach im ersten Char die ersten 8 Breiten, im zweiten Char die nächsten 8 Breiten etc. Hier habe ich mal für die ersten 16 Zeichen die Breiten binär in die ersten beiden unbelegten Chars gelegt (und rot eingefärbt).
Bitte melde dich an, um diesen Anhang zu sehen.
Wie das im RAM abgelegt wird, interessiert hingegen niemanden – das kann jeder Programmierer machen, wie er will. Der Kompatibilität wegen würde ich auf der Diskette sogar immer 2 KB je Zeichensatz (Standardgröße) "verschwenden". Die Einleseroutine kann ja nach der Hälfte den Import beenden.
Ich kenne leider keine "Standard-Editoren", wie Du sie anscheinend benutzt, sondern habe die Zeichen immer mit einem Text-Editor (vim) erstellt.
Ich verwende auch keine Standard-Editoren, sondern ein Standard-Grafikprogramm (auf MacOS) und lege dort immer eine Datei mit Ausmaßen 256 x 64 Pixel an. Dort blende ich mir ein 8x8 Raster ein und zeichne direkt in die Bitmap. Konvertierungen in übliche Formate (C64-Standardzeichensatz) übernimmt dann dankenswerterweise meist Gruppenmitglied ALeX. Aber auch hier kann man (wie man oben sehen kann) mit meinem Verfahren die Breiten in den ersten, meist freien, 32 Zeichen mittels Bitmuster ablegen.
Das Problem ist halt, dass die Wenigsten jetzt erst anfangen, Zeichensätze zu pixeln. Ich habe z.B. schon dutzende von Charsets gezeichnet und habe natürlich wenig Lust, mir meinen Zeichensatz auf den Bildschirm zu legen und dann in einem Text-Editor die Zeichen nochmal mit X und . "abzupausen". Deshalb schlug ich vor, die Zeichenbreiten so anzulegen, dass man sie mit existierenden Font-Tools bearbeiten kann.
Eine Auswahl an C64-Fonteditoren (8x8 Hires):
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.Er kommt ab jetzt auch auf die Images. Welchen Namen/C64-Filenamen soll er tragen ?
Danke. Ich wusste nicht welche Namens-Konventionen du vorgesehen hast. Du kannst bei dem von mir vergebenen Namen vorne das "zfont-" abschneiden und den Rest verwenden.
Erstklassig lesbar
Danke. Der Font ist extra für kleine oder etwas unscharfe Röhren (sind sie das nicht alle?) gemacht. Durch seine 2 Pixel starken Stämme lässt er sich auch bei leichten Unschärfen (ähnlich wie der C64 Systemzeichensatz) immer noch sehr gut entziffern. Und im Gegensatz zum Systemzeichensatz bekommt man ca. 50% mehr Text auf den Screen (rund 60 statt 40 Zeichen pro Zeile).
-
Mein Vorschlag für die Fonts wäre:
1.) Ein Font besteht mindestens aus 64 Zeichen (ASCII 32-96) also 64*8=512 bytes.
2.) Optional können bis zu 64 bytes mit Zeichenbreiten dahinter angehängt werden.
3.) Der Interpreter bestimmt beim Einlesen der anhand der Daten die Zeichenbreiten zunächst selbst. Sind keine expliziten Breiten angegeben, wird für Space eine Standard-Breite gewählt (z.B. pauschal 3 Pixel).
4.) Sind explizite Breiten angegeben, überschreiben diese die ermittelten Breiten. Wird eine Breite mit 0 angegeben, so gilt weiterhin die ermittelte Breite.
So braucht es kein Format, das nicht mit einem Standard 8x8 Font-Editor erstellt werden könnte. Im einfachsten Fall muss sich der Fonthersteller überhaupt nicht um die Breiten kümmern. Trotzdem könnten die ermittelten Breiten selektiv überschrieben werden, sofern das überhaupt nötig ist. Im einfachsten Fall wäre das nur ein byte mehr, um die Breite von Space festzulegen.
Der Kompatibilität wegen würde ich auf der Diskette sogar immer 2 KB je Zeichensatz (Standardgröße) "verschwenden". Die Einleseroutine kann ja nach der Hälfte den Import beenden.
Das würde bei diesem Ansatz allerdings nicht mehr möglich sein.
-
Man könnte theoretisch vielleicht auch den Font aus Zeugma verwenden (nennt sich "Schumacher Clean 6x8"). Allerdings ist der zwar frei verfügbar, aber man betritt dann das Territorium der zwingend beizufügenden Lizenzangaben (ähnlich GPL & Co.), ich weiss nicht ob man das wirklich will...
Bitte melde dich an, um diesen Anhang zu sehen.
-
Alles anzeigen
Mein Vorschlag für die Fonts wäre:
1.) Ein Font besteht mindestens aus 64 Zeichen (ASCII 32-96) also 64*8=512 bytes.
2.) Optional können bis zu 64 bytes mit Zeichenbreiten dahinter angehängt werden.
3.) Der Interpreter bestimmt beim Einlesen der anhand der Daten die Zeichenbreiten zunächst selbst. Sind keine expliziten Breiten angegeben, wird für Space eine Standard-Breite gewählt (z.B. pauschal 3 Pixel).
4.) Sind explizite Breiten angegeben, überschreiben diese die ermittelten Breiten. Wird eine Breite mit 0 angegeben, so gilt weiterhin die ermittelte Breite.
So braucht es kein Format, das nicht mit einem Standard 8x8 Font-Editor erstellt werden könnte. Im einfachsten Fall muss sich der Fonthersteller überhaupt nicht um die Breiten kümmern. Trotzdem könnten die ermittelten Breiten selektiv überschrieben werden, sofern das überhaupt nötig ist. Im einfachsten Fall wäre das nur ein byte mehr, um die Breite von Space festzulegen.
Das würde bei diesem Ansatz allerdings nicht mehr möglich sein.
Meine Lösung sieht so ähnlich aus, wie die von Henning vorgeschlagene.
Ich möchte allerdings nicht den Interpreter die Zeichenbreiten berechnen lassen, um den Code dort möglichst kompakt zu halten.
Stattdessen habe ich ein Tool in C geschrieben, welches das "Retrofan" Format in das Interpreter-Format konvertiert.
Hierbei ist es nicht notwendig (aber möglich) Zeichenbreiten vorzugeben.
Sind die Werte für Zeichenbreiten 0, so werden sie vom Konverter automatisch ermittelt.Dieses Programm ist simpel und kann von jedem für beliebige Eingangsformate abgeändert werden.
Wer dies nicht selbst tun möchte, kann mir auch seinen Font-File schicken, und ich liefere ein passendes Konverterprogramm dazu.Das Programm wird compiliert mit:
cc -o zfont zfont.cund aufgerufen mit:
zfont retrofanfile interpreterfileHier nun der Programmcode als Anhang und zum Ansehen (das Forum verbietet die Extension ".c", also "zfont.txt" nach dem Download in "zfont.c" umbenennen)
Die merkwürdigen Farbkombinationen des Syntax-Highlighting stammen nicht von mir sondern der Foren-Software
C: zfont.c
Alles anzeigen// Convert Retrofan font file to Z-font file #include <stdlib.h> #include <string.h> #include <stdio.h> FILE *fpi,*fpo; unsigned char CharWidth[32 *8]; unsigned char CharShape[96][8]; unsigned char CharZFont[96][9]; int ComputeWidth(int c) { int row,width,bit; unsigned char Mask; Mask = CharShape[c][0]; for (row = 1 ; row < 8 ; ++row) Mask |= CharShape[c][row]; for (width = 8, bit=1 ; width > 0 ; --width, bit <<= 1) { if (Mask & bit) break; } return width; } int main(int argc, char *argv[]) { int c; if (argc != 3) { printf("\nUsage: zfont <fontfile> <z-fontfile>\n"); exit(1); } // read input file in retrofan format if (!(fpi = fopen(argv[1],"rb"))) { printf("\n*** Error: Could not open <%s>\n",argv[1]); exit(1); } fread(CharWidth,1,8*32,fpi); fread(CharShape,1,8*96,fpi); fclose(fpi); for (c = 0 ; c < 96 ; ++c) { memcpy(&CharZFont[c][1],&CharShape[c][0],8); if (CharWidth[c]) CharZFont[c][0] = CharWidth[c]; else CharZFont[c][0] = ComputeWidth(c); } // All digits must have same width: use digit '0' for (c = '1'-0x20 ; c <= '9'-0x20 ; ++c) CharZFont[c][0] = CharZFont[0x10][0]; // Make blank half the width of "W" + 1 if not specified if (!CharZFont[0][0]) CharZFont[0][0] = (CharZFont['W'-0x20][0] >> 1) + 1; // write output file in Z Font format if (!(fpo = fopen(argv[2],"wb"))) { printf("\n*** Error: Could not open <%s>\n",argv[2]); exit(1); } fwrite(CharZFont,1,9*96,fpo); fclose(fpo); printf("\nREADY.\n"); exit(0); } -
Hier ein Screenshot in den "Farben" die Infocom in der grauen Phase bevorzugte ...
Bitte melde dich an, um diesen Anhang zu sehen. -
- Offizieller Beitrag
So braucht es kein Format, das nicht mit einem Standard 8x8 Font-Editor erstellt werden könnte. Im einfachsten Fall muss sich der Fonthersteller überhaupt nicht um die Breiten kümmern. Trotzdem könnten die ermittelten Breiten selektiv überschrieben werden, sofern das überhaupt nötig ist. Im einfachsten Fall wäre das nur ein byte mehr, um die Breite von Space festzulegen.
Das klingt auch nicht schlecht, allerdings wäre so ein Format nicht mehr "kompatibel", wenn der Zeichensatz recht voll ist (ISO 8859-1 oder -15) und man trotzdem noch Breitentabellen anhängen muss (bei meinem ISO 8859-15-Font für den Webbrowser nötig, da einige Akzente über die reine Zeichenform hinausreichen) – und ich wollte ja nichts spezielles für den hiesigen Zweck, sonders etwas Universelles, was man ab jetzt hätte verwenden können. Eine Einleseroutine könnte natürlich auch bei vorgelagerten Breiten (in den ersten 32 Zeichen) überprüfen, ob da was liegt und wenn nicht, sich die Breiten aus den Zeichen holen.
Dein Fontformat hätte zudem eine variable Datei-Größe, oder? Ich glaube, damit käme keiner der existierenden Fonteditoren beim Einlesen klar.
Das Optionale bei den Breitenangaben ist aber eine gute Idee, die man übernehmen sollte.
Was man hier insgesamt noch besser machen könnte (und weswegen ich auch meinen schon fertigen Font nochmal für diesen Interpreter anfassen musste): Besser, man startet die Zeichenformen wirklich am linken Rand und verschenkt nicht eine Spalte für den Zeichen-Abstand – so kann man Zeichen 1 Pixel breiter bauen. Wenn man Abstand zum linken Bildschirmrand haben möchte, kann man auch mit einem Offset beim Buchstaben-Zeichnen beginnen.
Und, last but not least, würde ich den zu importierenden Font nicht durch Umbenennen bestimmen, sondern den zu ladenden Dateinamen mit in das Konfig-Progamm mit hineinnehmen.
Man könnte theoretisch vielleicht auch den Font aus Zeugma verwenden
So toll ist der auch nicht, die Versalien sind meines Erachtens zu hoch und der fette Font läuft zu sehr ineinander. Hier geht es ja auch nicht darum, überhaupt einen Font zu haben, sondern eine Auswahl beizulegen. Aber wo du "Lizenzangaben" sagst: Man sollte doch vielleicht zumindest im Dateinamen erlauben, den jeweiligen Fontdesigner am Kürzel erkennen zu können, wenn es sonst schon keine Möglichkeit der Herkunfs-Angabe gibt.
Meine Lösung sieht so ähnlich aus, wie die von Henning vorgeschlagene.
Das hattest du bei meinem Vorschlag auch gesagt.
Aber egal, die neue Lösung ist schon besser, weil man jetzt nicht mehr mit einem ASCII-Editor alles neu machen muss. Allerdings wäre meine Lösung die Chance gewesen, doch mal einen Standard für proportionale 1-Bit-Fonts auf dem C64 festzuklopfen. Jetzt haben wir nur wieder ein weiteres Format. -
Was man hier insgesamt noch besser machen könnte (und weswegen ich auch meinen schon fertigen Font nochmal für diesen Interpreter anfassen musste): Besser, man startet die Zeichenformen wirklich am linken Rand und verschenkt nicht eine Spalte für den Zeichen-Abstand – so kann man Zeichen 1 Pixel breiter bauen.
Bei dem einfachen Ansatz mit simpler Zeichenbreite würde ich da sagen: besser nicht. Damit die Idee mit der automatisch korrekten Breite funktioniert ist es am einfachsten, wenn die Spalte ganz links immer leer ist, dann muss der Code, der den Font rendert, trotzdem recht wenig tun, das eine Pixel Abstand ist immer automatisch da.
Wenn man so weit geht, dass man beim Rendern immer eine leere Spalte einfügt, könnte man ja gleich noch auf die Idee kommen, "richtiges" Kerning zu unterstützen

-