letzter Beitrag von Acorn am
interessant schmeiss mal so einen Charset rüber ich will das nicht selbst pixeln. Sollte aber pro Char in einem 8x8 Feld sein sonst habe
ich eine Nightmare ROL ROR Aktion zu machen ...
Hier ist ein Proportionalfont im 8x8-Raster als C64-Charset-Binary. Wenn dir PNG o.ä. lieber ist, kann ich das auch liefern.
Die Zeichen sind aber wenn ich mir die ansehe 6 bit gross
Das ist ein Proportional-Font mit unterschiedlich breiten Zeichen (wie bei GEOS). Im Schnitt kommt man damit auf ca. 60 Zeichen/Zeile. Schmalere Zeichensätze mit festen Breiten habe ich auch, müsste ich aber wahrscheinlich erst in einen Chargen reinpacken und generieren.
Einen Glitch gibts beim "h" keine Ahnung warum. Im Charset sehe ich den nicht am Schirm schon.
Das könnte der I-Punkt sein, der bei allen I's fehlt.
Vielleicht die falschen 8 Bytes aus dem Zeichensatz abgegriffen?
Wenn Du noch mehr Zeichen auf dem Schirm haben möchtest, dann gehen auch 7 Pixel Höhe sehr gut.
Erst einmal danke für die Demo. Ich finde, das sieht schon sehr erfolgversprechend aus.
Das Pixeln der 6x8 oder 5x8 Character nimmt die meiste Zeit weg.
Wenn man keinen Editor baut, sondern einen Viewer/Browser, der schon weiß, was als nächstes kommt, könnte man doch evtl. auch in der REU ein paar Zeilen vor-rendern, oder? Dann müsste man beim Scrollen nur die Speicherverschiebungen machen – und das Rendern macht man teils in den Pausen, in denen der User liest.
Reu beschleunigt das ca. 20%.
Gefühlt sind das sogar mehr als 20% Beschleunigung. Ich finde, das geht schon recht fix – mitlesen kann man da kaum.
Einen Glitch gibts beim "h" keine Ahnung warum. Im Charset sehe ich den nicht am Schirm schon.
Wie meine Vorredner schon anmerkten: Im "h" scheint der i-Punkt des darauf folgenden "i"s zu liegen.
In der Deutschen ASCII Version habe ich leider keine Umlaute im Character gefunden.
Ich hatte das Charset in der C64-Standard-Belegung gebaut, natürlich ohne Umlaute. DIN-Belegung, wie beim C128, könnte ich aber auch liefern*.
Was noch cool wäre, wäre die Möglichkeit, per Cursortasten hoch und runter zu scrollen.
Und könnte man das theoretisch auch noch optional mit dem Softscrolling-Register kombinieren, um die Zeilen sogar pixelweise zu verschieben – wie bei deiner Xevious-Grafik? Oder drückt das sehr auf die Performance?
Und zu guter Letzt: Vielleicht könnte man den Text noch von einigen harten Umbrüchen befreien, damit weniger halbleere Zeilen zu sehen sind?
*) Edit: Neuer DIN-Font (C128-Belegung) angehängt (kann für englisch und deutsch verwendet werden).
Das softscrollreg ist nicht das problem. Das Pixeln der Character nimmt Zeit.
Ich meinte auch eher, dass Softscrolling beindruckend aussehen könnte, falls es nicht viel "kostet". Der Effekt könnte evtl. cool sein (und die Lesbarkeit während des Scrollens verbessern), weil man das bei harten Anwendungen im Text-Mode nicht kennt. Mir ist schon klar, dass die Haupt-Rechenzeit für das Text-Rendering draufgeht.
Ob ich das jetzt in der Reu "render" oder nicht, die CPU muss das ja rechnen
Schon klar. Ich hatte die Idee formuliert, ob man nicht ein wenig Offscreen-Rendern könnte, um Rechenzeit zu nutzen, wenn sie ansonsten nicht benötigt wird. Ich weiß aber nicht, ob das realistisch ist.
Cursors
Hier will ich klarstellen, dass ich mit "Cursortasten" wirklich nur die Tasten meinte, kein Cursor auf dem Screen. Also Hoch- und Runterscrollen (mit Cursortaste hoch/runter), statt (mit Space) "nur" in eine Richtung. Aber dann müsstest du (beim Hochscrollen) auch in der obersten Zeile rendern – das ist wahrscheinlich nicht trivial zu lösen, nehme ich an. Von daher: Vergiss den Wunsch.
Wordbruch müsste die Print Routine machen keine Idee wie man das umsetzt
Für die Demo finde ich das gar nicht so zentral, Hauptsache viel Text auf dem Screen. Daher mein geäußerter Wunsch, noch ein paar unnötig Zeilenumbrüche zu entfernen. Wenn am Zeilenende die Wörter abgeschnitten werden, fände ich das hingegen verschmerzbar. Es geht ja darum, einen Eindruck davon zu bekommen, was so geht im Bitmap-Land, wenn eine REU mithilft.
Ich bin im Moment zeitlich beim Soundplayer V2.0 der mich beschäftigt
Danke schonmal für das, was du hier gezeigt hast. Ich finde, dass die REU schon einiges bringt, was das Bitmap-Scrollen angeht, egal ob für "Text" oder Multicolor-Grafik. Gefühlt kommt einem das kaum langsamer vor als wenn man ein BASIC-Listing im Text-Mode durchscrollen lässt (faktisch wird da natürlich trotzdem ein Unterschied sein).
Statt berechnungen tabellen nehmen, einige Schleifen ausrollen da geht immer noch was.
Bei solchen Optimierungen wäre ich vorsichtig. Gerade wenn man eine Anwendung programmiert, benötigt man möglichst viel Speicher für das Dokument oder weitere Funktionen – das ist halt anders als bei einer Demo. Von daher muss man leider auf manche Optimierungen verzichten. (Wobei man ja dank der REU ja wiederum flexibler ist, was den Speicher angeht).
Apropos Speicher: Ich hatte ja den proportionalen Zeichensatz als Chargde (C128-DIN) geliefert. Das ist natürlich Speicherplatz-Verschwendung, weil man eigentlich weder den getrennten-Großbuchstaben-Zeichensatz noch die invertierten Zeichen benötigt (invertieren kann man bei Bitmaps notfalls on-the-fly). Wenn man den Zeichensatz so sortiert, wie bei ISO8859-15 (angelehnt an die Amiga-Belegung aber moderner), hat man in den 256 Zeichen sogar noch Platz für die Breiten-Tabelle (in den ersten 32 Chars) und muss die nicht getrennt ablegen.
Ich habe noch eine Frage: Wäre das Verfahren, mit dem jetzt gescrollt wird, auch geeignet, wenn man z.B. oben 2 Char-Zeilen (also 16 Pixel vertikal) freihalten wollte für eine Status-Anzeige, man also nur die unteren 23 Zeilen scrollen will?
klar dann muss ich auch nicht die ganzen 8K verschieben sondern nur 7360 bytes.
Den Videoram verschiebe ich sowieso nicht da alles grün ist...
Ja stimmt ist mir auch aufgefallen das der Charrom auch nur 2K braucht. Und ja die Invertierten braucht man nicht ausser die Umlaute.
Die liegen bei ASCII alle im Invertierten Bereich "/" war ü "v" war ä glaube ich.
Aber man kann ja eine Tabelle machen die die Ascii Bytes auf Commodore code wandelt.
Für Softscroll (welches ich schon probiert habe) braucht man auf einen Schlag nochmal 8K Hires und verliert noch 1K vram extra... (für Farbe)
Zeichensatz kann bleiben wo er will ($1800)
dann muss man wieder wie bei meinem Demo häppchenweise 1K im Hintergrund einkopieren denn die REU braucht für die gesamten 8K mehr als ich Zeit für das Bild habe.. (über 12 ms) und dann springt es wieder ... hässlich...
also softscroller wieder rausgenommen.
Wegen Cursorsteuerung dachte ich mir ich packe alles was oben rausläuft wieder in die REU zurück und fülle die halt auf...
Dann könnte man auch in gegenrichtugn scrollen bis die Reu leer ist 
Du weißt ja das ich das nur als Terminal Programm habe, also ohne VRAM (im sinne von Zeichenbuffer) und mit den verschiedenen Zeilenlängen ists ein alptraum da einen Editor zu machen.
Die Zelda REU-Demo, den Link hatte ich bereits oben gepostet. Dort findet man die REU-Demo und auch die SCPU-Anpassung.
Bei nur Text würde ich nicht auf den Bitmap-Mode setzen, dafür wäre das ganze dann auch ohne REU schnell genug. Die Rechenzeit für das Scrolling sinkt sogar deutlich, wenn man viel Speicher verwendet. Aber selbst bei weniger Speicherverbrauch sollte noch ganze noch schnell genug bleiben. Bis auf ein zwei Nachteile im Zeichensatz-Mode, sind die Vorteile mehr als ausreichend.
Habe es endlich geschafft eine Bitmap-Render Routine zu schreiben. Am Anfange hatte ich kein Plan, wie man sowas am besten umsetzen kann. Leider neige dann dazu, erstmal andere Sachen zu coden oder eine lange Pause einzulegen. Ohne Termindruck, wird bei mir keine Software fertig.
