Hallo Besucher, der Thread wurde 20k mal aufgerufen und enthält 86 Antworten

letzter Beitrag von DMHas am

Nufli File Specs?

    Hucky: Hier stehen sehr viele Infos zum Nufli-Format: https://www.c64-wiki.de/wiki/NUFLI


    Dieses Bildformat wird auch für das C64-Videoformat "Nuvie" verwendet: bei diesem werden einfach so schnell viele Nufli-Bilder abgespielt, dass eine flüssig aussehende Bewegung entsteht (ein Nuvie erstellt man, indem man ein Quellvideo zunächst in seine Einzelbilder zerlegt, diese Einzelbilder mit dem Mufflon-Konverter in das Nufli-Format konvertiert und anschließend diese Nufli-Bilder mit dem Nuviemaker zu einem Nuvie-Video zusammensetzt).

    Nufli Format ist das beste C64 Bildformat überhaupt, weil es eine hohe Auflösung hat, nicht flackert und trotzdem halbwegs viele Farben im Bild unterbringen kann.


    Der Nachteil ist, dass es recht kompliziert im Speicher verteilt ist ist und nicht so leicht manipuliert werden kann ( z.B. für Spiele ) ( Sprites und Rechenzeit sind während der Bilddarstellung verbraucht )


    Ausserdem benötigt man bisher einen Converter am PC o.ä. um das Format zu erzeugen, es sei denn, man pixelt es am C64 von Hand mit dem Nufli Editor..


    Optimal geeignet ist es aber für DIA -Shows und eben für Filme ( NUVIES ) sofern man eine REU hat.


    https://www.c64-wiki.de/wiki/NUFLI

    Nächster Zwischenstand:


    Ich bin natürlich so vorgegangen, wie du gemeint hast, buexe, also mit einem Einfachbild, in dem man datentechnisch wiederfinden kann, was man gemalt hat. Zuerst einfach einen einzigen weißen Punkt an definierter Stelle, den ich dann für jeden neuen Test definiert verschoben hab. Damit hab ich rausgekriegt, wie die Farben in einem NuFLI wirklich angeordnet sind, denn das muss ich Deekay (den ich sehr verehre!) mal vorwerfen: Nach der Beschreibung (die buexe da gepostet hat) kann man ein NuFLI niemals generieren! Was da als Screenram bezeichnet wird, ist gar kein Screenram, sondern das sind einfach nur die Bereiche, in denen FLI-Daten abgelegt sind. Ein Screenram verstehe ich so, dass da zusammenhängend 1000 Bytes Videoram für die FLI-Farben vorliegen. Das sieht in der Beschreibung auch so aus, ist aber nicht so. Vielmehr sind im NuFLI die FLI-Daten a) von hinten nach vorne abgelegt, und b) nicht zusammenhängend, sondern jeweils als Doppelrasterzeile (von denen die eine leer ist, was ja aber ok ist bei FLI alle zwei Rasterzeilen). Das rauszufinden hat mich VIEL Zeit gekostet!


    Na jedenfalls hab ich so an die 20 bis 30 Tests laufen lassen, um dahinter zu steigen, und dann ein zweites Bild für den Rendertest generiert. In diesem Fall einfach ein weißes Rechteck auf blauem Grund. Sieht so aus:


    Testbild


    Dies ist bereits von GoDot gerendert, d.h. das NuFLI-Original ist weitgehend richtig in GoDot angekommen. Etwas Sorgen macht mir der helle Kasten links am Rand, der gehört da nicht hin (in den Originaldaten kein Hinweis darauf). Hier fängt der zweite Teil der Bitmap an, mit ebenfalls dem zweiten Teil der dazugehörigen Farben. Die sind hier im zweiten Teil anders angeordnet als im ersten und ich bin noch nicht sicher, ob das ab dieser Stelle alles stimmt.


    Das Testbild mit dem Mädchen sieht nun so aus:



    Auch hier ist der weiße Kasten links am Rand und im unteren Teil (ab diesem Kasten) scheinen mir mehr Clashes vorzukommen, was womöglich aber nur so scheint. Die Clashes selber machen mir erstmal keine Angst, denn nach meinem Verständnis ist dies der AFLI-Anteil des Bildes. Der wäre so komplett. Jetzt käme das Sprite-Gedöns als nächste Etappe und da denke ich, dass dadurch die ganzen Clashes wieder ausgebügelt werden. Deekay könnte was dazu sagen, ob ich bis jetzt richtig liege...


    Eines auf jeden Fall stimmt: Sowas (ein Format analysieren) macht Spaß! :-)


    Arndt

    Zitat von buexe74

    jetzt kommt der knifflige Teil .. ^^

    War schon knifflig genug! ;-)


    Aber ich hab schon wieder Schwierigkeiten: Irgendwie haben die Jungs eine geniale Methode, die Sprites zu positionieren, ohne die Positionsregister damit zu belästigen... Da ich kein Demo-Programmierer bin, muss ich da erstmal hintersteigen! Jedenfalls werden für die beiden Bitmaps im NuFli nur jeweils ein einziges Mal (soweit ich das jetzt überblicke) die Spritepositionen ausdrücklich gesetzt (für die oberste Zeile). Da aber die Sprites 1 bis 6 100mal ausgegeben werden, muss ja irgendwo zu finden sein, wohin. Ich hab bis jetzt gesehen, dass der Screen auf 24 Zeilen Höhe umgestellt wird und sich dann 100mal um jeweils 2 Pixel vertikal verstellt. Cool! Muss nur wissen wozu. Die Sprites kümmert schließlich die Position des Screens nicht weiter, die haben ihr eigenes Koordinatensytem. Echt cool, das Ganze... :-)


    Arndt

    Zitat von GoDot

    War schon knifflig genug

    Hey Arndt, wollte auch nur kurz sagen, wie cool ich es finde dass du das in GoDot bringst. Ich versuche derzeit im NUFLI-Format ein wenig zu arbeiten. Die fertigen Bilder die es so gibt sehen meist so aus, als hätte man 320x200 und könnte jeden Pixel frei setzen! Doch nein, die Restriktionen sind eisenhart und das sichtbare Resultat ist Ergebnis härtester Arbeit des Künstlers!

    Lies dir bitte den Thread auf CSDB zur Spritelayer durch sonst bist du ziemich verloren.


    http://csdb.dk/forums/?roomid=…icid=83785&showallposts=1


    Es ist wohl ein Demo-Coder-Trick, der sich Spritecrunch nennt. Wenn ich das richtig verstanden habe - Damit lässt sich wohl ein Sprite ohne herkömmliches multiplexen über ziemlich viele Rasterzeilen darstellen. Wo er die Spritedaten herholt die ja unterschiedlich sein müssen kann man ja an den Spritepointern sehen. Kann mir nicht vorstellen, dass die in jedem Screenram gleich sein sollen. Vielleicht ist das auch in jedem Bild unterschiedlich ( Wenn z.B. gar keine Sprites in dem Bild vorkommen ).
    Hier braucht man nun zum testen natürlich ein Bild , bei dem auf jeden Fall mindestens 3 Farben pro 8 mal 2 Block vorkommen zum testen.


    Ich würd vorschlagen, mal so ein Bild zu Disassemblieren. Dann den Displayer Anteil des Codes eines Nufli Bildes zu lokalisieren ( wahrscheinlich den IRQ Teil )
    Dann die "wilden" Vic register für die Sprites mal mit ihren echten Registernamen ersetzen, um die Übersichtlichkeit zu erhöhen und zu schauen, wann diese Register verändert werden. Du musst ja später ohnehin wissen, wie die FLI Routinr von je 2 Rasterzeilen aufgebaut sein muß, damit alles schön Cycle-genau dargestellt wird..


    Hier ist ein schönes Tool für sowas : Regenerator 1.7


    http://csdb.dk/release/?id=149429


    Das schwierige bei diesem Format ist glaub ich, dass in so ner FLI Displayer Routine mit Sprites aktiviert wohl nicht mehr viel Cycles übrig sein werden, und somit die Registerchanges für die Sprites ( z.B Farben ) eben nur dann vorkommen werden, wenn sie nötig sind und noch Platz haben. Deshalb wird dieser Teil der Displayer Routine für jedes Bild etwas anders aussehen. Aber die Spritepointer sollten hoffentlich immer ähnlich gesetzt sein.

    Zitat von GoDot

    Aber ich hab schon wieder Schwierigkeiten: Irgendwie haben die Jungs eine geniale Methode, die Sprites zu positionieren, ohne die Positionsregister damit zu belästigen... Da ich kein Demo-Programmierer bin, muss ich da erstmal hintersteigen! Jedenfalls werden für die beiden Bitmaps im NuFli nur jeweils ein einziges Mal (soweit ich das jetzt überblicke) die Spritepositionen ausdrücklich gesetzt (für die oberste Zeile).

    Die Sprites werden durch Sprite-Crunching und Stretching so manipuliert, dass sie 127 Zeilen hoch sind. Die Manipulation geschieht durch mehrmaliges Beschreiben von $D017 zu genau definierten Zeitpunkten. Dies ist erstmals in der Crest-Demo "Krestage 1" (von Roland) genau beschrieben und erklärt. http://csdb.dk/release/?id=2968


    Die Sprite-Y-Positionsregister werden zu Beginn der IRQ-Routine auf den "oberen" Y-Wert #$2B gesetzt und dann, sobald der VIC diese Rasterzeile erreicht hat, auf den "mittleren" Y-Wert #$AA, und dann im Laufe des Speedcodes (ab $1000) auf den "unteren" Wert #$D4 gesetzt. (Dafür sucht der NUFLI-Generator "freie" Stellen im Speedcode, an denen keine Umschaltung der Spritefarben nötig ist, und patcht diese Stellen dann so, dass die Y-Position neu gesetzt wird.)


    Diejenigen Spritedaten, die zwischen Y-Position #$2B und #$AA auf dem Bildschirm zu sehen sind, liegen wild zerwürfelt in vielen Spriteblöcken. Grund dafür ist, dass der VIC in diesen 127 Rasterzeilen beim Anzeigen der Spritedaten immer wieder durch die nur 64 Bytes großen Spriteblöcke läuft. Zur Anzeige des NUFLI Bilds ist es aber nötig, dass in jeder Rasterzeile andere Spritedaten zu sehen sein sollen. Roland hat es geschafft, dieses Ziel zu erreichen, durch das ständige Umschalten der Screenposition via $D018, das ja auch die Lage der Spritepointer mit umschaltet. Die Spritepointer in den verschiedenen Screens sind alle unterschiedlich gewählt. Es ist wirklich ein sehr großes Puzzle.

    Danke, buexe und ssdsa!


    Wenn ich das also richtig verstehe, bedeutet Sprite Crunch, dass bei einmaligem Setzen einer Sprite-Adresse und genau getimetem Umschalten der VIC-Speicherbereiche trotzdem bis zu sechs verschiedene Sprites untereinander dargestellt werden können! Wahnsinn! Ich lese mir als nächstes die Tech-Docs noch mal genauer durch und analysiere den NuFLI-Player weiter. Zum Glück (an die anderen Beiträge hier) muss ich für GoDot nur die Pixel des NuFLI-Bildes in der richtigen Farbe und an der richtigen Position identifizieren, um sie dann im 4Bit-Format im GoDot-Speicher abzulegen. Ich breche also für GoDot den ganzen Wahnsinnsvorgang herunter auf das einzelne Pixel und speichere das dann ab. Damit sind in GoDot dann sämtliche Tricks aufgelöst und auf ihr sichtbares Ergebnis reduziert. Ich seh jetzt schon mehr Licht am Horizont als noch heute Morgen. Nochmals danke!


    Und an Thunderblade: Ja, ein Saver für NuFLI ist das eigentliche Ziel hinter dem Ganzen. Wenn ich den Lader schaffe (und ich damit das Prinzip verstanden habe), dann kriege ich auch das hin. Ich bezweifele aber, dass ich viel machen kann, was Optimierung und das Abnehmen von Handarbeit beim Ergebnis des Savers angeht. Vielleicht - weil wir uns ja auf der nativen Seite der Bildkonvertierung bewegen, also auf der Real Machine - ist das aber auch gar nicht so wirklich erforderlich. Wenn man mit GoDot IFLIs nach NuFLI konvertieren kann, dann würde mir das schon ausreichen. Die Nicht-C64-Seite (mit JPGs, GIFs usw.) erledigt ja Mufflon bereits!


    Mir gefällt das immer mehr! :-)


    Arndt

    So, durch den Speedcode hab ich jetzt die Ursache für die vermehrten Clashes im unteren Drittel auch erkannt und im bestehenden NuFLI-Lader behoben. Der Grund war, dass in den untersten 4 Blockzeilen die Screenrams in einer anderen Reihenfolge abgelegt sind als sonst überall (steht auch nicht in Deekays Specs!)


    Das bedeutet, dass jetzt der AFLI-Anteil des NuFLI-Laders tatsächlich fertig ist. Das Testbild sieht nunmehr so aus:



    Links am Rand ist ein weiterer weißer Kasten dazugekommen. Die Ursache dieser Kästen ist mir noch nicht klar, aber genau dort an diesen Kästen beginnen die Screenram-Umstellungen.


    Hehe, bin sehr zufrieden! :-)


    Arndt

    Nicht zu vergessen.
    In den ersten 3 Chars gilt eine etwas andere Logik als in den Chars 4-39.
    In den ersten 3 Chars gibt es FLI ja nur in den ersten 2 Zeilen pro Cursorzeile. Zeile 3-8 hat keine FLI-Farben, sondern nur Hellgrau.
    Dafür gibt es 2 Sprite-Layer. Einen in Hires, uun den anderen in Multicolor.


    In Char 40 gibt es dagegen überhaupt keinen Sprite Layer. Dort ist nur das reine 2-Zeilen HiresFLI.


    Insgesamt ist der Screen 320x200 Pixel



    Die FLI Daten sind noch recht "einfach".
    Schlimm wird es bei den Spritedaten :)
    ABER...ich hab ja auch einen Editor gemacht.
    Und dort habe ich auch ein paar Tabellen abgelegt, die aus einer X und Y Position des Zeichencursors die entsprechende Stelle im Speicher erzeugen.
    DA müsste man (also wohl ich :) ) nochmal nachschauen.

    Zitat von Roland

    Schlimm wird es bei den Spritedaten :)

    Stimmt... :rauch:


    Zitat

    ABER...ich hab ja auch einen Editor gemacht.
    Und dort habe ich auch ein paar Tabellen abgelegt, die aus einer X und Y Position des Zeichencursors die entsprechende Stelle im Speicher erzeugen.
    DA müsste man (also wohl ich :) ) nochmal nachschauen.

    Ah ja, mach mal! Dann geht's bei mir schneller.. :kaputt:honk::strom:
    :roll:


    Arndt

    Also...
    zunächst abhängig von der Y Position das initiale Lowbyte Offset für die Spriteposition
    Y ist Zeilenbasiert. Also von 0-c7


    >C:7f00 05 08 08 0b 0b 0e 0e 11 11 14 14 17 17 1a 1a 1d
    >C:7f10 1d 20 20 23 23 26 26 29 29 2c 2c 2f 2f 32 32 35
    >C:7f20 35 38 38 3b 3b 3e 3e 01 01 04 04 07 07 0a 0a 0d
    >C:7f30 0d 10 10 13 13 16 16 19 19 1c 1c 1f 1f 22 22 25
    >C:7f40 25 28 28 2b 2b 2e 2e 31 31 34 34 37 37 3a 3a 3d
    >C:7f50 3d 00 00 03 03 06 06 09 09 0c 0c 0f 0f 12 12 15
    >C:7f60 15 18 18 1b 1b 1e 1e 21 21 24 24 27 27 2a 2a 2d
    >C:7f70 2d 30 30 33 33 36 36 39 39 3c 3c 00 00 03 03 06
    >C:7f80 06 09 09 0c 0c 0f 0f 12 12 15 15 18 18 1b 1b 1e
    >C:7f90 1e 21 21 24 24 27 27 2a 2a 2d 2d 30 30 33 33 36
    >C:7fa0 36 39 39 3c 3c 00 00 03 03 06 06 09 09 0c 0c 0f
    >C:7fb0 0f 12 12 15 15 18 18 1b 1b 1e 1e 21 21 24 24 27
    >C:7fc0 27 2a 2a 2d 2d 30 30 33 00 00 00 00 00 00 00 00


    Nun die Logik für Sprites 1-5 (Also Cursor-Screenposition 4-33 bzw. X Position 0-1d)
    Achtung, folgende X Position startet bei Nummer 0, obwohl es auf dem Screen der 4. Char ist.
    Das liegt daran, dass die ersten 3 Chars für den FLI Bug separat editiert werden.
    Außerdem wird die X Position nur in Chars verwaltet (nicht in Pixeln).
    D.h. X=0 ist die 4. Charposition. X=1 die 5. Charposition...usw.


    Also, abhängig vom X Wert wird folgendes zum lowbyte hinzugefügt und mit AND #$3F ausmaskiert (damit keine Werte über #$40 entstehen)


    >C:8ed0 00 00 01 01 02 02 00 00 01 01 02 02 00 00 01 01
    >C:8ee0 02 02 00 00 01 01 02 02 00 00 01 01 02 02 00 00
    >C:8ef0 01 01 02 02 00 00 00 00 00 00 00 00 00 00 00 00


    nun noch folgenden Wert abhängig von Y hinzu-ORA-en


    >C:8c00 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
    >C:8c10 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
    >C:8c20 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
    >C:8c30 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
    >C:8c40 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
    >C:8c50 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
    >C:8c60 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
    >C:8c70 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
    >C:8c80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    >C:8c90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    >C:8ca0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    >C:8cb0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    >C:8cc0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00


    und dann nochmal abhängig von X folgendes hinzuaddieren


    >C:8cd0 00 00 00 00 00 00 40 40 40 40 40 40 80 80 80 80
    >C:8ce0 80 80 c0 c0 c0 c0 c0 c0 00 00 00 00 00 00 40 40
    >C:8cf0 40 40 40 40 00 00 00 00 00 00 00 00 00 00 00 00


    Also für das Lowbyte:
    Lda 7f00,y
    clc
    adc 8ed0,x
    and #3f
    ora 8c00,y
    clc
    adc 8cd0,x
    sta $lowbyte


    und für das Highbyte (Achtung....Carry-Flag vom letzter Addition für das lowbyte wird beachtet)


    lda 8d00,y
    adc 8dd0,x
    sta $highbyte


    >C:8d00 5e 5e 5a 5a 56 56 52 52 4e 4e 4a 4a 46 46 42 42
    >C:8d10 5e 5e 5a 5a 56 56 52 52 4e 4e 4a 4a 46 46 42 42
    >C:8d20 5e 5e 5a 5a 56 56 52 52 4e 4e 4a 4a 46 46 42 42
    >C:8d30 5e 5e 5a 5a 56 56 52 52 4e 4e 4a 4a 46 46 42 42
    >C:8d40 5e 5e 5a 5a 56 56 52 52 4e 4e 4a 4a 46 46 42 42
    >C:8d50 5e 5e 5a 5a 56 56 52 52 4e 4e 4a 4a 46 46 42 42
    >C:8d60 5e 5e 5a 5a 56 56 52 52 4e 4e 4a 4a 46 46 42 42
    >C:8d70 5e 5e 5a 5a 56 56 52 52 4e 4e 4a 4a 46 46 42 42
    >C:8d80 21 21 25 25 29 29 2d 2d 21 21 25 25 29 29 2d 2d
    >C:8d90 21 21 25 25 29 29 2d 2d 21 21 25 25 29 29 2d 2d
    >C:8da0 21 21 25 25 29 29 2d 2d 25 25 29 29 2d 2d 21 21
    >C:8db0 25 25 29 29 2d 2d 21 21 25 25 29 29 2d 2d 21 21
    >C:8dc0 25 25 29 29 2d 2d 21 21 00 00 00 00 00 00 00 00


    >C:8dd0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
    >C:8de0 00 00 00 00 00 00 00 00 01 01 01 01 01 01 01 01 ................
    >C:8df0 01 01 01 01 00 00 00 00 00 00 00 00 00 00 00 00


    Da das 6. Sprite (Cursor-Screenposition 34-39, bzw X: 1e-23) etwas anders abgelegt ist,
    ist die Berechnung ein klein bisschen anders:


    Lowbyte:
    Lda 7f00,y
    clc
    adc 8ed0,x
    and #3f
    ora 8e00,y
    sta $lowbyte


    und das Highbyte
    lda 8f00,y
    sta $highbyte


    >C:8e00 c0 c0 80 80 40 40 00 00 c0 c0 80 80 40 40 00 00
    >C:8e10 c0 c0 80 80 40 40 00 00 c0 c0 80 80 40 40 00 00
    >C:8e20 c0 c0 80 80 40 40 00 00 c0 c0 80 80 40 40 00 00
    >C:8e30 c0 c0 80 80 40 40 00 00 c0 c0 80 80 40 40 00 00
    >C:8e40 c0 c0 80 80 40 40 00 00 c0 c0 80 80 40 40 00 00
    >C:8e50 c0 c0 80 80 40 40 00 00 c0 c0 80 80 40 40 00 00
    >C:8e60 c0 c0 80 80 40 40 00 00 c0 c0 80 80 40 40 00 00
    >C:8e70 c0 c0 80 80 40 40 00 00 c0 c0 80 80 40 40 00 00
    >C:8e80 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40
    >C:8e90 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40
    >C:8ea0 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40
    >C:8eb0 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40
    >C:8ec0 40 40 40 40 40 40 40 40 00 00 00 00 00 00 00 00



    >C:8f00 75 75 75 75 75 75 75 75 74 74 74 74 74 74 74 74
    >C:8f10 75 75 75 75 75 75 75 75 74 74 74 74 74 74 74 74
    >C:8f20 75 75 75 75 75 75 75 75 74 74 74 74 74 74 74 74
    >C:8f30 75 75 75 75 75 75 75 75 74 74 74 74 74 74 74 74
    >C:8f40 75 75 75 75 75 75 75 75 74 74 74 74 74 74 74 74
    >C:8f50 75 75 75 75 75 75 75 75 74 74 74 74 74 74 74 74
    >C:8f60 75 75 75 75 75 75 75 75 74 74 74 74 74 74 74 74
    >C:8f70 75 75 75 75 75 75 75 75 74 74 74 74 74 74 74 74
    >C:8f80 22 22 26 26 2a 2a 2e 2e 22 22 26 26 2a 2a 2e 2e
    >C:8f90 22 22 26 26 2a 2a 2e 2e 22 22 26 26 2a 2a 2e 2e
    >C:8fa0 22 22 26 26 2a 2a 2e 2e 26 26 2a 2a 2e 2e 22 22
    >C:8fb0 26 26 2a 2a 2e 2e 22 22 26 26 2a 2a 2e 2e 22 22
    >C:8fc0 26 26 2a 2a 2e 2e 22 22 00 00 00 00 00 00 00 00


    Ps: Wo ich mir die Tabellen gerade ansehe. Da fällt mir auf, dass im unteren Teil des Screens (nach dem Umschalten der VIC Bank) die Screen-RAMs bis zum Ende nicht in der selben Reihenfolge ablaufen.
    Also nicht immer Screen: 2000, 2400, 2800, 2c00, 2000, 2400, 2800, 2c00, 2000 .... sondern ab Zeile 168 gehts dann mit: 2400 (anstelle von 2000) weiter.
    Sieht man auch in der letzten Tabelle der Spritedaten. Da gehts ab 8fa8 nicht wie zuvor mit 22 22 26 26 ... weiter, sondern mit 26 26 2a 2a .... weiter.

    WUNDERBAR!!!


    Ich könnt dich knutschen, Roland! :bussi:

    Zitat von Roland

    Ps: Wo ich mir die Tabellen gerade ansehe. Da fällt mir auf, dass im unteren Teil des Screens (nach dem Umschalten der VIC Bank) die Screen-RAMs bis zum Ende nicht in der selben Reihenfolge ablaufen.

    Jepp! Das hatte ich in Post 31 schon erkannt. ;-)


    So, jetzt gleiche ich erstmal deine Tabellen mit denen ab, die ich mir hier schon zusammengeschustert habe (ich muss das Ganze ja auf eine 4Bit-Bitmap umrendern (ein Pixel=vier Bit, eine Kachel=32 Byte), die startet ab $4000) - und dann geht's los! :smoke:


    Arndt

    Zitat

    und wenn du das alles hast

    Hehe... :)


    Ich werd bestimmt noch ein paar Fragen haben. Im Moment bastele ich gerade daran, Sprites nach 4Bit zu rendern (das hab ich anderwärts schon mal gemacht, aber da war das viel aufwendiger als es hier sein muss). Außerdem muss ich alle Daten aus der REU rausprokeln, REU, weil ich sonst keinen Platz für ein 91 Blocks langes NuFLI hatte, in dem die Daten auf diese Art verteilt liegen. - Ja, ohne REU geht's nicht.


    Ich mach zuerst mal ein 4Bit-Abbild des Sprite-Layers und bringe dann erst AFLI und die Sprites zusammen. Muss auch noch überlegen, was ich am Ende zuerst rendere, das AFLI oder die Sprites, da die ja underlayed sind (wenn das AFLI bereits nach 4Bit konvertiert ist, hab ich keine Anhaltspunkte mehr, welche Pixel im Original im Vordergrund lagen, da wäre es wohl besser, erst die Sprites zu rendern). Na ja, das sind Details...


    Deine Tabellen sind schon mal Gold wert. ;-)


    Arndt