Render-Engine für Proportionalfonts im Bitmap Mode

aaah, geschrieben, aber nicht geposted:

Jep, nützliche Routinen der Proportionalfontrenderengine lägen ab $C000 (49152) gut für die Verwendung in BASIC V2. Der Standard Bitmap Farbspeicher ist das Screen-RAM ab $0400 (1024) und Hires-Bitmap liegt ab $2000 (8192).

Mit einer kleinen Auswahl könnte man bereits hübsche Sachen in Basic anstellen. Viel bräuchte man nicht, du hast es ja schon geschrieben 5ace :

- Hires-Screen ein/aus, löschen, Farben setzen (ok, das ist allgemeiner Kram, aber wäre natürllich nice, wenn man das gleich mit dabei hätte)

- Text ausgeben, z.B. in der Form SYS addr,farbe,x,y,"text" wäre komfortabel

- Textzeileneingabe, aber das könnte man ggf. per GET A$ und der Textausgabe lösen, d.h. drüberprinten.

und andere coole Features hast du auch bereits genannt.

Ja, damit käme man schon mal sehr weit.

Retrofan mir geht es hier auch erstmal darum, wie man die Proportionalschriften einsetzen kann.

Vorallem, damit am Schuss nicht nur tolle Routinen stehen, sondern das sie auch dahin kommen, praktisch nutzbar sind.

Viele tolle Sachen sind schon verschwunden weil man sie nicht wirklich nutzen konnte.

Lynx  Zyrian
Anbei die Routinen für eure Basic Projekte.

Die Funktionen sind:

Damit Ihr eure Projekte angehen könnt und dennoch jemand weiter die Routinen erweitert oder verbessern kann, habe ich mir überlegt, dass man die Einsprungspunkte ab $C000 als Tabelle von Words vorhalten könnte/sollte.

Das "Test" Basic-Programm zeigt, wie man die Funktionen nutzen kann

-------------------
Disclaimer:
- Die Routinen lassen sich optimieren. Ich wollte folgendes erreichen:
-- Zeropage Adressen werden nicht genutzt
-- Bis auf die Tabellen, sind die Funktionen in sich geschlossen, d.h. man könnte sie jeweils einzeln optimieren oder extrahieren/verwenden bzw. könnte man andererseits gemeinsam genutzte Unterfunktionen schreiben, um den Code zu verkürzen.
-- Wenige Funktionen, die viele Use-Cases abdecken, d.h. mit den Funktionen lässt sich bspw. auch der Bildschirm löschen und ein Bild ließe sich mit oder auch ohne Farben kopieren etc...

- Konkrete Optimierungsmöglichkeiten:
-- shift ausrollen
-- putString, putString2: cache für letztes Zeichen
-- putString2: Color nicht bei jedem Zeichen ausgegeben, sondern nur falls tatsächlich notwendig
-- Mir kam noch eine Idee: Man könnte bei den save und restore Befehlen den gesamten Speicher einblenden.

- Die Parameter "w" und "h" sind einschließlich, d.h. für die Werte 0 weiß ich nicht, ob alles korrekt funktionieren würde. Allgemein habe ich nicht wirklich alles ausgiebig getestet.

Anbei auch der Quelltext. Für Kritik, Fragen oder zusätzliche Featurewünsche stehe ich euch zur Verfügung.

basicprop.d64

test.bas.txt

basicProp.asm

Auf den ersten Blick: Fantastisch, erste Sahne 5ace !

Super, das sieht ja schon mal gut aus.

Ich bastle die Tage mal,was und posten das Ergebnis.

Bin schon sehr gespannt.

Ich habe schon mal einen kleinen Test gemacht und es klappt super und ist schnell.

Leider habe ich heute nicht mehr Zeit. Die Untermenüs kommen dann die Tage.

Gesteuert wird mit rechts. links und q für ende.

Schreibt gern wenn ihr schon Anregungen hättet.

Ich habe noch 2 Fragen:

1. wie komme ich an groß/klein Schrift?

2. kann ich die breite eines Strings berechnen?

Zyrian

zu 1.) Es handelt sich um einen ASCII-Font, d.h. die Kleinbuchstaben liegen 32 Zeichen hinter den Großbuchstaben. (Bsp. A=65, a=97)
zu 2.) Könnte man auch manuell, da die Breiten im Font selbst sind, d.h. ab Position CHARSET+$80 sind in den Nibbles die Breiten der Zeichen gespeichert.
- Ich sollte eine Funktion nachreichen. Ich müsste mir nur noch anschauen, wie man den Wert am besten an Basic zurückgibt, d.h. entweder per Speicherstelle oder USR Funktion. Dir geht es wahrscheinlich um die Pixelbreite eines Strings, d.h. man müsste noch das Font-Spacing von 1px berücksichtigen. (((Falls Du es Dir zutraust, könntest Du eine solche Funktion auch versuchen selbst in ASM zu schreiben. Das ist nicht so kompliziert und Du findest die Bausteine auch im Quelltext. Unter "putString" ab dem Kommentar "; get char width" bis hinter "; font-spacing". )))

Ich habe noch einen Verbesserungsvorschlag für Dein Basic-Programm ab Zeilennr. 6000:
Die Hervorhebung der Menüpunkte könntest Du über das Farbram (Funktion F5 statt F3) erledigen, weil das dann schneller wäre.
---------------------------

Und jetzt zum ultimativen Beweis, dass der Bitmap-Modus auf dem C64 für Anwendungen ausreichend schnell sein kann:

Es handelt sich dabei um die "Träumerei Nr.0", d.h. dem Reader ohne Framework, ohne Formatierungen, jedoch mit "Hyperlinks" zu anderen Dateien.
Für ein richtiges "Programm" würden noch Tastaturabfragen, zusätzliche Features (bspw. Floppyspeeder) und die Ausmerzung einiger Fehler fehlen, d.h. es dient nur dazu zu zeigen, dass der Bitmapmodus, entgegen vielen Aussagen, für Anwendungen brauchbar ist. Ich habe mir überlegt, dass ein Real-World Example "The VGA Trainer Program By DENTHOR of ASPHYXIA (updated by Snowman)" nett wäre, wobei ich nur die ersten 6 Tutorials auf Diskette gespeichert habe, weil ich sie nicht voll machen wollte.


readerv0.d64
"contents.txt" für das Beispiel im Reader öffnen!

-------
Macken/Bemerkungen:

- Beim Laden-Dialog habe ich gespart, d.h. hier kann man nicht scrollen, sondern nur die ersten 10 angezeigten Dateien wählen.
(Idee war: Beim Programm handelt es ich ja eh nur um einen "Proof-of-Concept" mit dem Schwerpunkt auf die Geschwindigkeit der Bitmap/das Scrolling.)

- Der Reader hat eine Beschränkung auf max. 256 Zeilen und es wird ein neuer Hinweis angezeigt, wenn die Datei zu lang war bzw. ein Fehler aufgetreten ist.

- Beim Schließen von Dialogen wird immer an die erste Zeile gesprungen.

- Es existiert ein Bug, d.h. Abstürze sind möglich, wenn mit dem breiten Font Buchstaben mit 8 Pixel an bestimmten Positionen ausgegeben werden, d.h. ein Dateiname mit bspw. einem großen "W" könnte zu Problemen führen.

- Die Hyperlinks werden innerhalb von doppelten Anführungszeichen erwartet. Beim Klicken wird erst in der zuletzt geladenenen Directory im Speicher danach geschaut, ob die auf Diskette vorhanden ist, d.h. man kann ohne Konsequenzen wild im Dokument klicken. (In der ersten Zeile der Tutorial-Dateien habe ich beispielhaft eine Art Navigation eingefügt, um ins Inhaltsverzeichnis bzw. die nächste/vorherige Seite zu gelangen.

- Das Scrolling über die Scrollbar ist möglich!
-- Den "Fahrstuhl" habe ich aus Gründen der Einfachheit sehr primitiv umgesetzt, d.h. das visuelle Feedback habe ich nur Kachelweise mit Farben umgesetzt und er verschwindet beim Benutzen der Pfeile.
-- Beim Scrollen über die Scrollbar nach oben, wird der Bildschirm von unten nach oben aufgebaut, was von mir so beabsichtigt war. Hierzu könnte ich viel schreiben + vieles zum Thema hatte ich beim "progressiven Scrolling" geschrieben/angeschnitten. (...)
-- Für das Scrolling wird diesmal ein anderer Ansatz als im letzten Reader verwendet. Über die Zeilenlänge wird der zu kopierende Bereich festgelegt, d.h. dieser Ansatz ist für linksbündige Texte "besser". Trotzdem ließe sich noch mehr durch eine Abwandlung oder die Verwendung zusätzlicher Tabellen rausholen, d.h. man könnte eine noch bessere "Demo" schreiben.

-- Das Scrolling erscheint auch deshalb "relativ schnell", weil das Rendering unterbrochen werden kann und an einer anderen Stelle erneut gestartet werden kann.

- Es gibt ein Easteregg in Form eines Lade-Spinners, d.h. die Funktionen werden angesprungen, jedoch direkt wieder mit rts beendet. Ich bin irgendwie in diese Spielerei abgedriftet. Nach dem Laden lässt sich der Spinner vor dem Starten des Readers mit folgenden Pokes ein/ausschalten. ("rts" wird durch "nop" an den drei Speicherstellen ersetzt. Ich hätte die Sprünge komplet entfernen können, dann wäre das Laden wahrscheinlich minimal schneller, falls überhaupt bemerkbar.)

-------

Das kann schon was.

Da bist du meiner Meinung nach, bei der Performance, schon weiter als Geos.

Ich habe vorhin noch etwas rumprobiert und bin auf ein Problem gestoßen.

Wenn ich einen Bereich sichere und wieder herstelle passt das nicht richtig, und ist immer zu klein.

In welchen Maßeinheiten erwartet die Funktion für x y w h ?

Zitat von Zyrian

Ich habe vorhin noch etwas rumprobiert und bin auf ein Problem gestoßen.

Wenn ich einen Bereich sichere und wieder herstelle passt das nicht richtig, und ist immer zu klein.

In welchen Maßeinheiten erwartet die Funktion für x y w h ?

Entschuldige, es war tatsächlich noch ein Fehler vorhanden; in .save und .restore konnte ich etwas korrigieren.
basicprop.prg

basicProp.asm

Die strLen-Berechnung kommt demnächst.

Vielen Dank

Aber du brauchst dich doch nicht Entschuldigen. Genau deshalb machen wir das doch, um Fehler zu finden und das Gute noch besser zu machen.

Ich teste es morgen mal.

Mit der Korrektur klappt es.

Ich probiere noch rum und weiß noch nicht wie ich das Navigieren in den Menüs machen soll, aber das kommt dann noch.

Ich hänge die aktuelle Basic Datei mal trotzdem an.

Kannst du mal schauen, warum man bei save und restore in der breite +1 nehmen muss, damit es passt.

Lustig, dass ich gerade schreiben wollte.
Die strLen Funktion ist jetzt auch dabei. (habe ich nicht getestet).

In der Liste hinter CHARSET als

Ich habe mich gegen die USR-Funktion entschieden, weil im C64-Wiki einige brauchbare Tricks für Basic (schneller Div 10, Mul 10) angegeben sind.

Die Korrektur bzgl. Erhöhung der Breiten um eins habe ich gerade eben einfach mit einem "inx" an den Stellen "; w = X" bei der Parameterübernahme aus Basic erledigt.

Zu Deinem Programm:
Beim Einlesen in C64Studio wurden zwei Fehlermeldung wegen zu langer Zeilen angezeigt. (Einmal Zeile 45 und einmal 141.)
Ich habe sie gekürzt bzw. aufgeteilt und konnte es dann ausführen.
(Ich sehe, es werden derzeit nur die ersten 3 Einträge des Menüs angezeigt...)

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

Zitat von Retrofan

Aus dem schmalen Font habe ich einen monospaced Font für 80-Zeichen-Darstellung entwickelt. Ich denke, der holt so ziemlich das Maximum an Lesbarkeit heraus bei 3 Pixeln Breite (4 in Ausnahmefällen).

Ein paar Zeichen (Æ, æ, Œ und œ) lassen sich beim besten Willen nicht mit so wenigen Pixeln in der Breite darstellen – dort liegen jetzt Platzhalter.

Ich habe den Font noch nicht ausprobiert. Aber ich schätze Deine Arbeit sehr.

(((
Einwenig OT:
Zu einer 80 Zeichen Monospace Darstellung habe ich folgenden "Traum":

1.) Den Rahmen links und rechts öffnen und Sprites nutzen, wie im SDBrowse, jedoch monochrome, d.h. die Auflösung wäre damit 400 Pixel breit.
2.) Den 5x8 Font EverexME nutzen, weil ich mir dabei denke, dass man einen IBM-PC am nähesten kommen könnte.
3.) Und jetzt diese Routine entweder
a.) in Basic einbinden, d.h. ein Soft-80 Programm daraus machen
b.) mein pmcli-Programm damit ausschmücken oder
c.) wirklich zusätzlich eine 8086 CPU emulieren (Wer kennt sich mit einer Portierung aus C? siehe hier) und somit quasi einen alten IBM-XT PC
Nagut, einwenig herumspinnen darf man ja
)))

(...)

Ja, bisher sind es nur die drei ersten Menüs. Ich habe erst noch die Save Restore Funktionen testen wollen. Ausserdem habe ich schon öfter die Ideen für ein dynamisches Menü verworfen. Die Subroutinen sollen später ja auch einfach von jedem übernommen werden können. Ich muss das vielleicht noch mal ganz anders angehen. Kennst du eigentlich eine Asm Routine für line, die würde ich gern noch mit einhängen, für Rahmen und so.

Zitat von Retrofan

Ich hatte sowas ähnliches auch schonmal (grafisch) umgesetzt – mit möglichst geringem Speicherverbrauch* im Hinterkopf. Es werden nur zwei unterschiedliche "Chars" benötigt (zu einem 2x2-Tile zusammengesetzt) – der Rest wird wieder per Änderung von Vorder- und Hintergrundfarbe realisiert, also mit Color-Cycling. Ich finde, dafür, dass das (bis auf die Farbe) eine statische Grafik ist, sieht es eigentlich ganz dynamisch und cool aus.

Stimmt, das sieht wirklich gut (=effektvoll) aus.

Zitat von Retrofan

Konntest du auch gar nicht, weil ich das Binary nicht angehängt hatte.

Haha.

Zitat von Retrofan

Noch etwas: Für mich wäre es eine ganz dolle Erleichterung beim Testen meiner Fonts, wenn du den Text-Viewer dahingehend modifizierend könntest, dass das Font-Binary (wie ich es liefere) für den Text (nicht unbedingt das fürs UI) separat auf dem Medium liegt und vom Hauptprogramm beim Start geladen wird. Dann könnte ich einfach neue Versionen ergänzen/ersetzen und mir dann im Viewer in Kombination mit den Texten ansehen.

Habe ich gerade geändert.
1.)
Zu Beginn wird die Datei "CHARSET.BIN" geladen, d.h. das ist der Zeichensatz für die Textdarstellung (= der schmale Font).
Da ich ihn auch in den Dialogen verwendet habe, die Textausgabe nicht geclippt wird und ich keinen dritten prop. Font hinzufügen wollte, laufen die Texte der Meldungen teilw. aus den Fenstern aus. (... Hat eig. keine andere Auswirkungen, da ja beim schließen der Dialoge ein refresh erfolgt.)
2.)
Die nächste Idee war, auch eine Textdatei mit dem Namen "START.TXT" zu Beginn zu laden, was umgesetzt ist.
3.)
Ich dachte mir, dass es toll wäre, wenn das Programm aut. anhand des Dateinamens einen Font von einer Textdatei unterscheiden könnte, so dass auch über Hyperlinks ein Font ausgewählt werden könnte.
Die Unterscheidung funktioniert, leider hatte ich jedoch die Berechnung der Zeilenbreiten direkt in der Einleseroutine für Textdateien untergebracht, so dass man die Textdatei neu laden muss, damit die Zeilenlängen korrekt berechnet werden und es keinen Speicherüberlauf geben kann, d.h.
nach dem Laden eines Zeichensatzes wird der Speicher erst gelöscht und man muss selbst eine Datei laden.

((( Scherz: Die vierte Idee wäre dann, dass zu Beginn auch ein .sid File geladen wird, so dass man die Grundlage für ein neues Diskmag hätte )))

Zitat von Retrofan

Man könnte diese einfache Umsetzung auch schon etwas verbessern, wenn man in den Scrollbereich eine Bitmap (bzw. Zeichen) legen würde, die die Form des Balkens schon etwas vorgibt aber (aufgrund identischer Vorder- und Hintergrundfarbe) unsichtbar bleibt, bis man sie einfärbt. Und es wäre toll, wenn man den Fahrstuhl spätestens einblenden würde, sobald man mit dem Mauspfeil in den Balken kommt.

Ja, so hatte ich mir das auch gedacht. Es gibt jedoch einige Probleme, die ich nicht lösen wollte:
- Die Position wird momentan nur in eine Richtung übergeben, d.h. beim Klicken wird die Mausposition über eine Tabelle von 152 Pixeln in die Zeilennummer umgerechnet. Die Tabelle wird beim Laden einer Datei erzeugt, d.h. der Vorgang konnte auch rechenintensiv ausfallen, so dass man im Gegenzug während des Scrollings keine Divisonen oder ähnliches ausführen muss.
Soweit finde ich die Lösung auch OK, weil die Tabelle nie größer als 152 Bytes sein kann. Das Problem entsteht, wenn man die Pfeiltasten betätigt, um einige Zeilen zu scrollen.
Obwohl die Zeilennummer nach der Betätigung der Pfeile klar ist, fehlt die Übersetzung zurück zur Fahrstuhlposition, d.h. hier könnte man jetzt eine Tabelle von 256 Bytes nutzen, was ich auch in Ordnung finden würde. (Bei der Verwendung einer solchen Tabelle hätten wir auch die Möglichkeit einen Balken mit einer dynamischen Höhe schnell/cpu-schonend darzustellen.)
Ich habe an der Stelle nicht weitergemacht, weil es sich um eine spezielle Lösung für den Reader in seiner jetzigen Form handelt und weil man ja eigentlich auch irgendwann einmal bspw. mehr Zeilen haben möchte o.ä...
Das ist ein sehr wichtiges Thema, weil die Nachhaltigkeit der Programmierung fehlt.
Durch den Reader in seiner jetzigen Form kann man zeigen, dass "neuartigere/bessere Bitmap-Programme" möglich sind.
Die Zeit weiter am Reader zu schreiben, wäre m.M.n. sinnvoller in der Bibliothek (oder woanders) aufgehoben, weil dadurch potentiell mehr Personen profitieren könn(t)en und etwas länger währendes möglich wäre. (...)

Hier müsste man jetzt den nächsten Schritt gehen, damit man aus den endlosen Demos (wir sehen ja, dass "fast alles" irgendwie möglich/umsetzbar ist,) in eine etwas stabilere/nachhaltigere Entwicklung/Richtung geht.

(Die Formulierung ist evtl. etwas merkwürdig gewählt, aber ich glaube die Idee, die ich ausdrücken wollte, ist klar.)