Hello, Guest the thread was called1.8k times and contains 51 replays

last post from Retrofan 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).