Hello, Guest the thread was called2.6k times and contains 58 replays

last post from Acorn at the

Hires Grafik scrollen möglich ?

  • 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 (denn die erste Spalte = 0 was Sinn macht wenn die Buchstaben aneinander kleben)

    das sind dann 320/6 = 53.3 Character pro Zeile.

    Willst du 64 Zeichen . müsste man den Char ja auf 5x8 verringern (also einmal nach links schieben) und dann haben die Zeichen nebeneinander ja keinerlei Zwischenraum oder ?

    Kleben dann?

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

  • Test beendet. Interessant. Man bekommt merklich viel auf den Schirm. Für einen Ebook Reader ists leider immer noch zu wenig aber was solls.

    Reu beschleunigt das ca. 20%. Das Pixeln der 6x8 oder 5x8 Character nimmt die meiste Zeit weg.


    Habe die Dateien angehängt

    english und deutsch sind ohne REU


    Reu_driver braucht eine mindest 128KB REU. (habe es am Vice getestet mit 512K)

    Das Hiresscrollen macht die Reu, das löschen der letzten Zeile geht mit Reu im Vice nicht. Habe dazu 1 Byte 0 in Bank 1 gespeichert und beim

    rückholen der Reu gesagt sie soll ihren internen Zeiger nicht erhöhen. Bleibt also theoretisch immer auf dem 0 Byte hängen , während sie 320 mal die 0 in den

    C64 Speicher schreibt. Wie gesagt im Vice geht 1 Byte übertragen anscheinend nicht. Habe den Teil wieder herausgenommen.


    Einen Glitch gibts beim "h" keine Ahnung warum. Im Charset sehe ich den nicht am Schirm schon.



    In der Deutschen ASCII Version habe ich leider keine Umlaute im Character gefunden. Jetzt stehen dort eben die CBM Grafik Codes. Kann man nachbessern.


    Aufbau:


    $0801 Code

    $0b62 320x Multiiplikator Tabellen

    $0c60 Breitentabelle (beinhaltet die Breite jedes Characters in pixel - weil proportional)

    $1000-$1fff Characterrom

    $2000 ASCII Demotext bis $c800 möglich


    $c800 Videoram (COLOR)

    $e000 Hiresbuffer für Darstellung


    Charrom kann auch unter $d000 sein wenn man es umschreibt und gewinnt 4k mehr Speicher

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

  • kann dir gerne den Quellcode geben

    Das softscrollreg ist nicht das problem. Das Pixeln der Character nimmt Zeit.

    Immerhin muss ich einen haufen ROL ROR AND ORA sachen machen pro Zeichen


    Ob ich das jetzt in der Reu "render" oder nicht, die CPU muss das ja rechnen da die REU ja keine Bitoperationen im Gegensatz zum Amiga kann.


    Cursors:

    Ich müsste dazu einen neuen Videoram mit 64 x 25 Zeichen bauen

    Im moment gibts nur den PRINT Akku Befehl der ein ASCII an die aktuelle stelle zeichnet.

    ist der interne cursor (xvlow vxhigh / vy) auf Zeile 25 (nach Enter oder nach Ende von 316 Pixel) scrollt die Hires automatisch hoch.


    Wordbruch müsste die Print Routine machen keine Idee wie man das umsetzt, da müsste man das nächste Wort suchen, abzählen und abfragen ob es <316 pixel ist ....



    Danke für den Hinweis mit dem I punkt. Ja der Zeichensatz war um 1 Byte am falschen Platz.

    Durch einfügen enes 0 Bytes habe ich den Charset korrekt im Speicher und das H und I funktioniert.

    Irgendwas mit der !bin direktive im Source scheint nicht zu stimmen. Ist mir bei anderen Projekten so nicht aufgefallen.


    Den Text kann man in der Reu version lesen weil ja am ende immer auf die Leertaste gewartet wird.

    Mein Programm fragt diesmal die REU Existenz nicht ab. Man sieht nur kein Scrollen ohne REU.


    Anhang: +1 Byte mehr - charset fix, Reu füllt Zeile 24 mit 320 x 0 byte aus (schnelles löschen der Zeile)


    Ich bin im Moment zeitlich beim Soundplayer V2.0 der mich beschäftigt - möchte Digi Samples zum SID parallel ausgeben. Ganz mühsam.

    Komme auch am Wochende nicht zum programmieren.

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

  • kommt mir leicht schneller als basic interpreter vor ?

    vorallem wenn du die Tastenabfrage rausnimmst...

    Schnell genug finde ich.


    Es geht wie gesagt wenn man optimiert noch 12-15% raus

    Statt berechnungen tabellen nehmen, einige Schleifen ausrollen da geht immer noch was. Braucht man halt mehr Zeit...

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

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