Render-Engine für Proportionalfonts im Bitmap Mode

Zitat von Retrofan

Stile gehen ja auch mit "unserer" 8x8-Beschränkung beim Zeichensatz. Und ich finde unterschiedliche Schriftgrößen gar nicht so wichtig – im Verhältnis zu den Nachteilen bei der C64-Performance. Man könnte z.B. problemlos einen Brief oder eine Anleitung mit üblichen Auszeichnungen, wie fett, kursiv oder unterstrichen schreiben – dafür bräuchte es keine großen Schriften. Und ich glaube nicht, dass wirklich heute noch jemand versuchen würde, den C64 für DTP einzusetzen – und wenn doch, dann müsste ein entsprechendes Programm um die fehlenden Text-Routinen erweitert werden. Dafür bekommen alle anderen Programme (oder ein OS), die mit Schriftgrößen bis 8 px Höhe auskommen, jetzt einen schnellen Bitmap-Renderer an die Hand.

Prinzipiell - und ja, jetzt träume ich - kann man das so ähnlich wie bei geoPublish machen. Dort wird mit geoWrite der Text verfasst und mit geoPublish gesetzt. Aber ich bin ganz bei dir: Die Performance der Routinen von 5ace ist so toll, dass ich da auch gerne auf große Schriften verzichte.

Zitat von Retrofan

Der Cursor muss ja gar nicht unbedingt 8 Pixel nach rechts wandern, sondern nur bis zur nächsten Blockgrenze – im Durchschnitt sind das nur 4 Pixel. Ich denke, das wäre optisch zu verschmerzen.

Ja und nein. Optisch ja. Aber du musst in diesem Fall die Blockgrenze berechnen. Wenn du aber 8 Pixel weiterhüpfst, bist du auf jeden Fall safe und musst nichts zusätzlich berechnen. Aber 5ace kann das sicherlich besser beurteilen.

Zitat von 5ace

Weitere Idee dazu:
Man könnte mit der zeilenweisen Fontänderung auch Bilder darstellen!
Die Fonts (=gestückelten Bilder) müssten dazu entweder in der Textdatei eingebettet (= eigener Header notwendig) oder könnten von Diskette nachgeladen werden.
Man könnte monospaced-Fonts einführen, welche ohne den 128-Byte Header auskommen und mit schnelleren Routinen ausgegeben werden könnten.
(Oder direkt ein Bildformat definieren, welches bspw. im ersten Byte die Kennung, danach die Maße und ob Farbe vorhanden ist oder nicht, beinhaltet.)

Das wird ja immer geiler! Bilder wären echt cool.

Über den reversen Zeichensatzbereich hab ich auch mal kleine monochrome Grafiken zum Nachladen eingebunden. Extra dafür einen bmp2char Konverter auf PC geschrieben.

So kann man Grafiken bequem irgendwo in den Text pflanzen. Die Farben hab ich manuell im Code nachgepatched. Aber einfarbig wär's ja auch schon hübsch und ausreichend.

5ace Wenn man deine Proportionalfont-Engine dann noch per SYS aus BASIC heraus verwenden kann, könnte man ganz einfach schöne Sachen anstellen. Proportionalfont sieht halt edel aus. Wann hast du's fertig?

Meine Hoffnung ist auch das dabei irgendwann ein Framework herauskommt um möglichst vielen Programmierern die Möglichkeit zu geben das zu nutzen.

Damit kann dann wirklich gezeigt werden das der c64 mehr als Geos kann.

Da wäre soviel möglich. Von Anwendung bis Game.

Ich bastle ja an einem Konzept für eine Wirtschaftssimulation, und da wäre das auch toll zu haben.

Schon weil der Bildschirmaufbau dann nicht so Zeit kritisch ist.

Zitat von Snoopy

Ich schließe mich dem Lob an! Respekt! Wirklich sehr, sehr flott! Hut ab!

Vielen, vielen Dank!

Zitat von Retrofan

Wenn ich dich richtig verstanden habe, möchtest du das progressive Rendering beim Scrolling einsetzen, damit keine leeren Zeilen entstehen, wenn der Text-Renderer nicht mit dem Scrollen mithalten kann? Was mich neben der Nicht-lesbarkeit (hier nicht relevant) während des progressiven Aufbaus auch etwas stört, ist der veränderte "Grauwert". In der Typografie beschreibt der Grauwert die durchschnittliche Helligkeit eines Textblocks. Wenn ein Renderprozess etwas länger dauert, dann wird oft mit Platzhaltern gearbeitet. Das passierte früher oft beim DTP, als die Rechner dafür noch "zu" langsam waren. Aber auch heute findet man solche Tricks in Smartphone-Apps beim Bildschirmaufbau/Scrolling. Ich habe hier mal versucht, Zeilen mit Platzhaltern anzudeuten, die im Grauwert in etwa den echten Textzeilen entsprechen (die jeweils unterste Linie entspricht der Grundlinie der Schrift und die obere der 3 Linien liegt auf x-Höhe (also der Kleinbuchstaben-Höhe):

((( In den letzten zwei Absätzen aus Deinem Link zum Grauwert steht, dass der Wert einen subjektiven Sinneseindruck beschreibt und, dass es Erfahrungswerte gibt, wie man die Wahrnehmung verbessern kann.
Und genau das ist der Punkt, der auch in den ganzen Testprogrammen hier das Resultat war: Der Aufbau und die Darstellung dürfen einfach keinen störender Eindruck hinterlassen. )))

Zum progr. Rendering:
Du hast es korrekt beschrieben - es würde auch in die Kategorie "Platzhalter" oder "Überbrückungseffekt" fallen.
(Leere Zeilen würden bei uns jedoch tatsächlich nicht ausgegeben werden (...). Mit dem nächsten Testprogramm wird die Problematik mit dem Scrolling besser nachvollziehbar sein. Ich denke/hoffe, dass das progr. Rendering u.a. Abwandlungen nicht notwendig sein werden (...))

Zitat von Retrofan

Vielleicht wäre sowas eine Alternative? Oder wäre damit Performance-technisch nichts gewonnen bzw. nur verschlimmbessert? Ich fände es auch nicht tragisch, wenn die Linienlänge nicht identisch mit der echten Zeilenlänge wäre, nur Leerzeilen sollte am Besten auch leer bleiben.

Das von Dir vorgeschlagene Muster wird perf-techn. keinen Vorteil bringen, weil es statisch ist. Beim progr. Rendering findet eine Übertragung von Daten an die richtigen Stellen statt.
Vielleicht wäre eine Alternative die betroffenen 8x8 Kacheln VG+HG temporär einzufärben (bspw. mittelgrau), bis die Daten kopiert sind. Der Nachteil wäre wahrscheinlich, dass man ein kurzes Aufblitzen sehen/bemerken würde, sobald die Zielfarbe dann eingesetzt werden würde.
Das sind jetzt beides nur Vermutungen, die man austesten müsste, weil man den vorhin erwähnten ausschlaggebenden (subj.) Sinneseindruck bewerten/berücksichtigen müsste/sollte.

Zitat von Retrofan

Wenn man Farbe für den Text verwendet, muss man ja das Farb-RAM mitscrollen. Wie sehr wirkt sich das auf die Performance aus?

Bei der "Scrolltest mit Farben" Demo tust du das aber schon, oder? Ansonsten: Farbe immer gerne.

Unterstrich für Links wäre halt typisch und gelernt (wenn auch nur mäßig hübsch). Ich kann mir aber auch andere Hervorhebungen vorstellen, z.B. fett (dann würde das in Richtung Buttons gehen).

In der benannten Demo wird das Farb-RAM über eine Konstante gesetzt und nicht kopiert!
Hier müssten wir also auch einen Test machen.
Geschwindigkeitstechnisch wird das wahrscheinlich noch annehmbar sein; es sind sicherlich noch einige andere Änderungen/Variationen/Optimierungen am Algorithmus/Vorgehen machbar (...)

Zitat von Retrofan

In deiner Darstellung sind die "Steuercodes" ausgeschrieben (und unterschiedlich lang). Könnte man es nicht alternativ so machen, dass man ein Einleitungs-"Zeichen" hat und danach eine feste Anzahl von Steuercodes, z.B. immer 2, danach geht dann der Text weiter. In so einem 16-Bit-Wert kannst du doch eine Menge (natürlich nicht menschlich lesbarer) Informationen ablegen. Für ein Einleitungs-Zeichen kannst du z.B. eines der ersten 16 des ISO-Zeichensatzes nehmen – ich kann das dann im Charset dafür freihalten (und in entsprechend codierten Texten wird so ein Zeichen auch nicht benutzt werden).

Das ist eine Idee, über die man nochmal nachdenken könnte.
Mir gehen zwar die ersten Einwände durch den Kopf; ich werde jedoch nochmal in Ruhe darüber nachdenken.
(((Bemerkung: Bei mir sollte ein in Klammern eingeschlossener Steuercode bspw. "[Start]", "[Ende]", "[Zeichensatz]" genau ein Byte sein. Und "[Start]" und "[Ende]" sollten zwei der unteren nicht verwendeten 32 Zeichen sein.)))

Noch ein kurzer Einschub dazu: Ich habe mir die Tage den anderen Thread zum Browser nochmal einwenig durchgelesen und habe dabei einige Posts von Hexworx gefunden, die mir gar nicht aufgefallen waren. Im Grunde war er vor ca. 5 Jahren an genau der selben bzw. einer ähnlichen Stelle und hatte zwei At-Zeichen als Einleitung für einen Steuercode/Symbol verwendet gefolgt von einem Zeichen.
(...)

Zitat von Retrofan

Und schon haben wir ein Hypertext-Dokument, welches es ja schon vor dem Web gab, z.B. mit Apples HyperCard.

Habe mir HyperCard angeschaut. Kannte ich noch nicht.
"Hypertext" ist der richtige Begriff.
Das würde eine Menge Spass machen, wenn man sich dazu noch vorstellt, dass es vielleicht möglich wäre, mehrere (kleine) Dateien im Speicher zu halten/cachen...

Zitat von Retrofan

Ein Web-Proxy für den C64 ...

(Nein, ich will nicht alle meine Wünsche bei DIR abladen)

(((Ein PHP-Skript zu schreiben, welches html nur filtert/vereinfacht ist nicht schwer.)))
Im Thread zum Browser gab es zwei pot. relevante Posts, die hierzu passen würden:
- Einmal der lynx-dump bei dem der letzte Teil mit der Linkliste fehlte. Der war sogar von Dir, falls ich mich recht entsinne. Es wäre interessant einen neuen vollst. dump zu erstellen, um zu sehen, wie die Links dort in der Liste vermerkt sind.
- In einem anderen Post hatte jemand manuell per Copy & Paste den Textinhalt einer Webseite extrahiert. Die Darstellung war in etwa auch die, die man in dem Reader erwarten könnte.

Der Fokus sollte m.M.n. weniger auf einen Proxy, sondern eher auf der C64 Seite liegen.
Der C64 muss in der Lage sein können, eine .html (und somit auch eine von frogfind) oder markdown Datei selbst zu filtern und in die interne "pure" Textform konvertieren zu können.
Bspw. deshalb, weil man eine Datei von Disk laden können soll. Die Konvertierung selbst dürfte dabei so lange, wie nötig andauern und könnte/sollte sogar über ein eigenständig separates Prg. erfolgen.
Das "Pure"-Textformat sollte also als primäres "Datenformat" des Readers gesehen werden.

Dadurch gäbe es dann auch keine Abhängigkeit zu einem Proxy, d.h. der ist zweitrangig.

Zitat von Retrofan

Das Bewegen durch die Zeile läuft noch zu schnell, dadurch überspringt man Zeichen.

Ich denke, 256 Pixel würden reichen (zumindest wenn es ein Eingabe-Feld bleibt und nicht Teil eines Fullscreen-Editors wird – dann müsste man schon bis zu einem vollständigen Zeilenende kommen können).

Einen Überschreiben-Modus bräuchte ich persönlich nicht. Bei Proportionalschrift sähe das ohnehin etwas seltsam aus, weil die ersetzenden Zeichen ja nicht immer die Breite der vorherigen haben und dann die ganze Zeile in der Länge springt.

Markierungen/Invertierungen hingegen wären natürlich ein Träumchen (beim Editieren).

Ja, die Fonteffekte würde ich auch interessant finden. Ich weiß jedoch schon jetzt, dass die Ausgabe invertierter Zeichen langsam ist... (Nat. könnte man mit einem inversen Font tricksen, aber das würde ich hier nicht wollen.)

Zitat von Retrofan

Dafür bekommen alle anderen Programme (oder ein OS), die mit Schriftgrößen bis 8 px Höhe auskommen, jetzt einen schnellen Bitmap-Renderer an die Hand.

Bei der Geschw. des Bitmap-Renderers hast Du recht.
Wichtig ist nochmal bzgl. der Scrollroutine zu betonen, dass sie von den leeren Stellen lebt, d.h. im worst-case wäre sie langsamer als das reguläre Bitmap-Scrolling. Hier gibt es wie bereits erwähnt/gezeigt auch Auswege (zur Not mit dem double-Buffering ). Man könnte sogar eine Formel aufstellen, ab wievielen Zeichen ungefähr die Routine im Vgl. zu der regulären schneller/langsamer ist.

Zitat von Retrofan

Der Cursor muss ja gar nicht unbedingt 8 Pixel nach rechts wandern, sondern nur bis zur nächsten Blockgrenze – im Durchschnitt sind das nur 4 Pixel. Ich denke, das wäre optisch zu verschmerzen.

Zitat von Spockie

Ja und nein. Optisch ja. Aber du musst in diesem Fall die Blockgrenze berechnen. Wenn du aber 8 Pixel weiterhüpfst, bist du auf jeden Fall safe und musst nichts zusätzlich berechnen. Aber 5ace kann das sicherlich besser beurteilen.

Beide Aussagen sind korrekt. Ich hatte noch die Symetrie im Auge, d.h. wenn vorne 4 Pixel möglich sind aber hinten nicht, dann ...

Zitat von YPS

Das wäre die perfekte Engine für den WiC64-Chat. So passt viel mehr Text auf den Bildschirm

Das WiC als Modem, um die .http-Abfragen durchzuführen, ist sehr interessant für die Verwendung im Reader.
Ich hatte mir die Dokumente mal angelesen, ist aber eine Zeit lang her. Soweit ich mich erinnern kann, kann der Kernel ausgeblendet bleiben.
(Ich müsste nochmal nachschauen; ich hatte mir gemerkt, dass die Doku gut war und auch fertiger Quelltext/Beispielsourcecode irgendwo herumgeistert + ich hatte gelesen, dass eine Emulation möglich ist, d.h. eig. alles optimal.)
Der WiC64-Chat sagt mir leider nichts.

Zitat von Retrofan

Eine mögliche Realisierung von so etwas wurde u.a. auch immer mal deswegen in Frage gestellt, weil dem C64-Bitmap-Mode eine zu geringe Performance unterstellt wird. Viele erinnern sich an GEOS und dessen Render-Geschwindigkeit (vom GUI und auch von Text) und meinen, das wäre das Maximum dessen, was der C64 schaffen könne. Dieser Thread ist u.a. in der Hoffnung entstanden, Gegenbeweise zu liefern.

Richtig und Du hast auch einen riesigen Beitrag dazu geleistet, schon alleine deswegen, weil Du die passenden Fonts zur Verfügung gestellt hast.
Wie bereits oben geschrieben, kann die Geschwindigkeit unter der der regulären Bitmap fallen. Ich denke sogar, dass Deine BlindTest Datei dazu führen wird, "neue Chancen" zu entdecken
Im Allgemeinen waren jedoch die ganzen Argumente gegen den Bitmap-Modus unbegründet.

Die nächste Version des Readers wird das auch nochmal bekräftigen.

(...)

Zitat von Lynx

Das wird ja immer geiler! Bilder wären echt cool.

Über den reversen Zeichensatzbereich hab ich auch mal kleine monochrome Grafiken zum Nachladen eingebunden. Extra dafür einen bmp2char Konverter auf PC geschrieben.

So kann man Grafiken bequem irgendwo in den Text pflanzen. Die Farben hab ich manuell im Code nachgepatched. Aber einfarbig wär's ja auch schon hübsch und ausreichend.

5ace Wenn man deine Proportionalfont-Engine dann noch per SYS aus BASIC heraus verwenden kann, könnte man ganz einfach schöne Sachen anstellen. Proportionalfont sieht halt edel aus. Wann hast du's fertig?

((( Der Screenshot sieht spannend aus. Evtl. hättest Du auch Sprites für die Grafik von Ripley verwenden können? )))
Bei dem Bildformat, welches für die Bibliotheks-Routinen vorgesehen ist, folgen die Colorram Daten den Bitmap-Daten.

Mit der Einbindung in Basic kenne ich mich nicht aus, aber ich bin mir sicher, dass dazu genügend Ressourcen existiert.
Vielleicht findet sich auch jemand, der daraus eine Basic-Erweiterung macht.
(...)

----

Die Frage mit dem "Wann hast du's fertig" ist schon die richtige!
Von der Zeitplanung her denke ich, dass der Reader jetzt in den nächsten Tagen (max. 1-2 Wochen) in der einfachsten Version fertiggestellt sein wird.
Danach wird es eine weitere Version geben, welche sich nur darin unterscheiden wird, dass sie mehr als 256 Zeilen unterstützt.
Und dann geht es wieder zurück zur (Weiter-)entwicklung der Bibliothek.
Die Bibliothek ist wichtig, damit wir in Richtung einheitliche GUI/OS kommen und soll auch dazu dienen, dass sich mehr Personen beteiligen können.
Der Reader ist nur wichtig, um den anfänglichen Gegenstimmen Parolie zu bieten.

(...)

Zitat von 5ace

((( Der Screenshot sieht spannend aus. Evtl. hättest Du auch Sprites für die Grafik von Ripley verwenden können? )))
Bei dem Bildformat, welches für die Bibliotheks-Routinen vorgesehen ist, folgen die Colorram Daten den Bitmap-Daten.

Mit der Einbindung in Basic kenne ich mich nicht aus, aber ich bin mir sicher, dass dazu genügend Ressourcen existiert.
Vielleicht findet sich auch jemand, der daraus eine Basic-Erweiterung macht.

Sprites, +Sprites oder Overlay-Sprites geht natürlich alles, aber da Sprites noch für Mauszeiger und andere Objekte herhalten könnten und Hires Sprites sich nicht in 8x8 einfärben lassen, hab ich's beim Charset belassen. Das Ripley Pic hat die Größe 88x64, die reversen Chars decken 128x64 Pixel flexibel in variabler Höhe und Breite ab (man könnte auch noch die verbleibenden PETSCII dazunehmen), 8 Sprites sind nur 96x42 Pixel.

Eine Basic-Erweiterung im Sinne von Befehlen wär gar nicht mal nötig, würde reichen, wenn man die Ausgabe-Routinen anspringen könnte, also Position, Farbe und Text vorgeben und per SYS ausgeben lassen. Assembler kapier ich zumindest rudimentär, dann schaun wir mal, was hinten raus so alles für Basic rausspringt. Defintiv geil, weiter so!

Zitat von Retrofan

Der gelb hinterlegte Bereich der Auswahl wird natürlich über eine geänderte Hintergrundfarbe erreicht. Die "Feinheiten" am Anfang und Ende der Auswahl (hier hellgrün, normal natürlich in der gleichen Farbe wie die restliche Auswahl) können über zwei temporäre Hintergrund-Sprites realisiert werden. Dann muss man keine Pixel invertieren oder mit unterschiedlichen Fonts arbeiten. Und da man während des Markierens keine Schreibmarke benötigt, wird kurzfristig nur ein weiteres Sprite hinzugezogen.

Was mir dabei auch gefällt: Die Konsistenz – auch sonst habe ich bei meinen Entwürfen nie die Darstellung invertiert, wenn etwas ausgewählt wird – weil das halt aufwendiger ist, als einfach die Hintergrundfarbe zu wechseln. Und so wäre es dann auch hier.

Das ist eine sehr gute Idee, zumal man ja weiterhin die Hervorhebung bei Auswahlboxen oder Listen ohne Sprites umsetzen kann, weil diese eig. immer in den Chargrenzen stattfindet. Optisch sieht es auch besser aus, als die üblichen Umsetzungen mit Sprites, welche zwei Ecken/Haken anzeigen.
(Hinzu kommt noch, dass für die meisten Anwendungsfälle ohnehin nur eine Selektion zu einer Zeit angezeigt werden muss.)

----
Ich wollte noch auf einige Beiträge antworten:

Zitat von Spockie

Prinzipiell - und ja, jetzt träume ich - kann man das so ähnlich wie bei geoPublish machen. Dort wird mit geoWrite der Text verfasst und mit geoPublish gesetzt.

Einige Tests zu variablen Zeichengrößen Render-Engine für Proportionalfonts im Bitmap Mode , falls noch nicht gesehen. Zum Träumen: Sicherlich wäre eine "modernere" Anwendung mit flexibler Fontgröße und direkter Editierfunktion möglich.
---

Zitat von YPS

Das wäre die perfekte Engine für den WiC64-Chat. So passt viel mehr Text auf den Bildschirm

Zitat von Zyrian

Ich bastle ja an einem Konzept für eine Wirtschaftssimulation, und da wäre das auch toll zu haben.

Schon weil der Bildschirmaufbau dann nicht so Zeit kritisch ist.

Zitat von Lynx

Eine Basic-Erweiterung im Sinne von Befehlen wär gar nicht mal nötig, würde reichen, wenn man die Ausgabe-Routinen anspringen könnte, also Position, Farbe und Text vorgeben und per SYS ausgeben lassen. Assembler kapier ich zumindest rudimentär, dann schaun wir mal, was hinten raus so alles für Basic rausspringt.

Vielleicht könnte ich auch kurzfristig eine Auswahl an Routinen zusammenstellen, gerade für die von euch genannten Fälle, d.h. zum Anspringen aus Basic heraus. Dazu müsste ich wissen, welche Funktionen benötigt werden. Momentan würde es sich nur um Grafikbefehle handeln:
- Hiresmodus ein-/ausschalten
- Grafikcursor positionieren (x, y)

- Zeichenfarbe auswählen (farbe)

- Bildschirmbereich füllen (b,h, zeichen)- Zeichensatz auswählen (addr)

- Zeichenkette ausgeben (addr)
- Grafik ausgeben (b,h, addr)
- Bildschirmbereich nach oben scrollen (Hier könnte ich testen, ob sich ein beliebiger Bereich scrollen ließe)
Ich müsste noch wissen, wo die Bitmap und das Screenram für Basic am besten hin sollten.
Ich denke, dass sich für die Routinen der Platz ab $c000 anbieten würde.
Noch als Hinweis: Es würde sich um spez. Routinen handeln. Die vorgesehene "richtige" Bibliothek des Threads hier, hätte damit nichts zu tun

Zitat von Zyrian

Meine Hoffnung ist auch das dabei irgendwann ein Framework herauskommt um möglichst vielen Programmierern die Möglichkeit zu geben das zu nutzen.

Damit kann dann wirklich gezeigt werden das der c64 mehr als Geos kann.

Da wäre soviel möglich. Von Anwendung bis Game.

Ich bin der festen Überzeugung, dass das passieren wird. (Es hängt aber auch viel von der Resonanz der Community ab.)
(...)

ich bin noch immer in der Konzeption. Für mich ist es also egal in welchem Speicherbereich liegt.

Von der Optik her dachte ich an ein Menüsystem wie in Hanse, Vermeer oder Yuppies Revenge. ( Ja, ich bin Ralf Glau Fan)

Mit deinen Routinen könnte das GUI aber deutlich moderner ausfallen.

Was ich so vor hatte war:

- Fenster zeichnen und darin:

Text ausgeben (vielleicht formatiert)

Einfache Eingaben: String/Zahl, J/N(Das wäre gut mit dem Markieren zu lösen)

Grafik ausgeben

- Ein Menü, das bei Proportional, ähnlich wie bei Windows, oben am Bildschirmrand machbar wäre

Nicht das du glaubst, ich erwarte das alles von dir. Das ist nur das was in meinem Kopf rumspukt.

Und wie gesagt noch plane ich.

Wenn du möchtest kann ich ja die Tage mal in Photoshop was basteln, wovon ich täume.

Falls dir das helfen würde, dann müsste ich nur noch wissen welchen Font ich in welcher Größe für das Beispiel nehmen sollte.

Und nochmal, TOLLE ARBEIT

Zitat von Zyrian

Einfache Eingaben: String/Zahl, J/N(Das wäre gut mit dem Markieren zu lösen)

Grafik ausgeben

- Ein Menü, das bei Proportional, ähnlich wie bei Windows, oben am Bildschirmrand machbar wäre

Momentan haben wir noch keine Eingabefelder oder Menüs.
Ich denke dennoch, dass Du diese selbst in Basic nachbilden könntest.
Falls Du keine genauen Werte benötigst und es mit dem Spielablauf vereinbar wäre, könntest Du bspw. eine Zahleneingabe über Buttons lösen (+/- 100, +/- 1000 o.ä.).
Ich könnte Dir noch einen Funktion mitgeben, die einen Bildschirmausschnitt retten und wiederherstellen kann, so dass Du die Möglichkeit hättest, selbst ein Menü umzusetzen.
Den Mauszeiger und die Mausabfrage, die sich in den Interrupt hängt, könnte ich Dir nat. auch vorbereiten.
Zum Font: Die Routinen unterstützten derzeit max. 8x8 Pixel-Fonts.

Du kannst gerne Deine Spielidee/Vision vorstellen.
Da Du ja eh noch in der Planungsphase bist, könnte es sogar sein, dass die "richtige" Bibliothek bis zu Deiner Umsetzungsphase bereit ist und Du sie dann direkt nutzen kannst.
Mal schauen evtl. hat Lynx genauere Ideen/Vorgaben bzgl. des Speicherbereichs.

; -------------------
Retrofan

Ich wollte einwenig mit möglichen Fonteffekten spielen.
Fazit:
- Du hattest recht bzgl. des unleserlichen Fettdrucks.
- Der Kursivdruck mit einem Pixel Versatz sieht jedoch soweit in Ordnung aus. Ich hatte sogar eine rel. einfache Lösung zum dritten Byte, weil dieses ja max. nur mit einem Pixel gefüllt wird...
- Das Problem ist jetzt Fonteffekte zu mischen, da der Ansatz die Zeichen zu zeichnen wieder ein kompett anderer wäre, d.h. es ist eine Frage der Aufteilung der Funktionen...

fonteffect001.prg

Die Invertierung war nur Spielerei, d.h. hier werden die Bitmuster invertiert und der String wird immer in seiner Gesamtheit aktualisiert...
Ein Klick setzt den Beginn und ein weiterer Klick setzt das Ende der Markierung. In einer GUI wäre die Handhabung nat. eine andere/sinnvollere.
(...)

Ich bastel morgen einen Screen.

Ich würde auch gern schon mal mit den deine Routienen experimentieren.

Wenn das okay ist. Ich bin aber nicht nicht sicher ob ich BASIC oder Assembler nehme. Basic fällt mir leichter, aber Assembler schneller und man hat mehr Platz

Ich habe es endlich geschafft ein Demo-Bild von meinen Vorstellungen zu machen.

Ist jetzt nicht toll geworden, aber es ist ja auch nur ein schneller Entwurf.

Im Menü und dem Requester kannst du auch sehen, was ich damit meinte, als ich sagte, das man dafür das Markieren aus deiner Demo nehmen könnte).

Zyrian
Ich antworte Dir mal kurz.
Erstmal gut, dass Du ein Mockup erstellt hast, weil man so konkret über eine Umsetzung/Hilfestellung nachdenken kann.
Was sich aus meiner Sicht ohne größere Schwierigkeiten umsetzen ließe bzw. was Du, anhand des Mockups bewertet, benötigst, ist folgendes:
- Bitmap einschalten, Screen löschen (, + evtl. Einfärben von Kacheln?)
- 8x8 Proportionalschriftausgabe mit beliebiger x und y Position
- Horizontale und vertikale Linien mit beliebiger x und y Position und Breite/Höhe
-- Daraus evtl. eine Rectangle-Funktion mit beliebigen Koordinaten
- Ausgabe/Kopieren von Grafikdaten für das Bild oben rechts.
Soweit alles Ok, d.h. diese Funktionen könnte ich Dir bereitstellen.

Was einwenig problematisch ist bzw. aus meiner Sicht wäre, sind:
- die Farben, weil sie nicht im Raster liegen, d.h. die Hervorhebung des Menüpunktes "Lager" bzw. von "Ja" könte man mit je einem Sprite umsetzen.
- die rote Schrift bei dem Gewinn, weil man hier auch mit einem Sprite arbeiten müsste/könnte.
- die IK+ Grafik verstößt auf den ersten Blick auch gegen die C64 Restriktionen. Das Bild ist 98x54 Pixel groß und nutzt 13 Farben, d.h. man müsste die Größe wahrscheinlich einwenig verkleinern, so dass (bspw.) 4 Sprites für die zusätzlichen Farben verwendet würden.

Du könntest versuchen die y-Positionen für die Schriften (und evtl. auch die Linien) auf das Kachelraster 8x8 abzustimmen, so dass es keine Probleme mit den Farben gäbe.
Interessant wäre es auch noch weitere Screens zu sehen, weil ich mir bis hierhin vorstellen kann, dass die Bedienung auch ohne Maus und auch ohne Scrolling erfolgen könnte. (Auch Dropdown-Menüs scheinen nicht notwendig zu sein.)

Evtl. ist Dir das alles bewusst; ich wollte das nur ausführlich hinschreiben, weil bislang kein anderer eine Rückmeldung abgegeben hat.

Ist denn der Spielablauf bereits klar? (Was würde bspw. in der freien schwarzen Fläche dargestellt werden?)

Hi, danke für deine Antwort.

Ich bin mir der Restriktionen bewusst. Das Bild ist auch nur ein Entwurf.

Und ich wollte ohnehin später alles an einem Raster ausrichten, damit sowas wie Highlighting oder Grafiken keine Probleme machen.

Und auch die rote Schrift sollte dann möglich sein.

Mit den Routinen die du vorgeschlagen hast wäre ich schon sehr glücklich, in dem anderen Post hattest du noch von einer Routine zum wegkopieren und wiederholen von Bildbereichen gesprochen. Die wäre super um ein Dropdownmenü zu realisieren.

Ich bin wie gesagt noch immer in der Konzeption, aber ich fände es interessant mein Demobild als reinen nachzubauen und zu testen wie das mit Menüs und so werden könnte.

Ich bin gerade dabei auf das C64-Studio umzusteigen und finde die möglichkeit in Basic-Quellen auf Labels im Assemblercode zu verweisen sehr interessant. Falls du mir also einige Routinen zukommen lassen könntest wäre es wirklich cool, wenn ich sie da einbinden könnte.

Gruß

Zyrian

PS: Wenn ich das Spiel wirklich irgendwann fertig werden sollte, nenne ich dich natürlich als Uhrheber der Grafikroutienen

Zitat von 5ace

- die IK+ Grafik verstößt auf den ersten Blick auch gegen die C64 Restriktionen. Das Bild ist 98x54 Pixel groß und nutzt 13 Farben, d.h. man müsste die Größe wahrscheinlich einwenig verkleinern, so dass (bspw.) 4 Sprites für die zusätzlichen Farben verwendet würden.

Ich vermute, das ist nur ein Beispiel ohne passendem Format. Es ist ja Hires und auch sehr gedithert. Wohl wegen einer anderen Palette als die des verwendeten Screenshots.
Müsste man mit der passenden Palette in der gewünschten Größe als Multicolor neu berechnen.

EDIT: Ups, zu spät.

Falls Ein (Teil-)Koala für ein Mockup gebraucht wird.

Skaliert auf 12x7 chars.

Das ".prg" einfach weglöschen. Dient nur zum anhängen des Koala-Files.