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

letzter Beitrag von DMHas am

Nufli File Specs?

    Bin wieder da. :-)


    Und hab natürlich gleich Fragen an Roland. Du schriebst in Post 49 zum Thema Farbquellen im FLI-Bug-Bereich:

    Ja, diese sechs Tabellen geben die Farben für die sechs Sprites im AFLI-Bereich an. Welche der Tabellen muss ich checken, damit ich an die Farben für Sprite 0 (Hires, Kennzeichen $7x hast du geschrieben) und für Sprite 7 (Multi, Kennzeichen $5x, $6x und $ex) herankomme? Oder heißt Post 54/55, dass $2400 für Hires da ist, die anderen für Multi? Welche davon?


    Ansonsten: Im Moment sieht der FLI-Bug-Streifen noch ziemlich merkwürdig aus (viel Pixelei). Muss noch sehen, was da falsch sein könnte (wenn überhaupt, ist ohne die Farben ja nicht wirklich klar).

    Es gibt nur diese 6 Tabellen. Es gibt ja auch im Code nur Zeit um 6 Speicherstellen pro 2 Rasterlines zu verändern.
    Und so sind diese 6 Tabellen alias Speicherstellen zunächst einmal für die Sprites 1-6 vorgesehen.


    Wenn sich nun aber die Spritefarbe in aufeinander folgenden 2er Lines sich nicht ändert, braucht man die Farbe ja auch nicht erneut setzten.
    Und genau dann kann man diese Zeit nutzen um eine andere Speicherstelle zu verändern. Eben genau eine Farbe der FLI-Bug Sprites.


    Genau das wird über das Highnibble in der 6 Farbtabellen definiert.
    Ist das Highnibble = 7 (also z.B: $71), wird die Spritefarbe weiß in das Sprite 0 ($D027) gesetzt. Egal in welcher der 6 Tabellen das steht.


    Beispiel:


    Tabelle $2800:


    01, 02, 03, 78, 04, 79, 53, 6a, 05


    Dann würden die Spritefarben folgendemaßen aussehen (immer doppelt, da ja 2er Zeilen)
    (?? bedeutet: unbekann, kommt darauf an, wie es zu beginn des screens definiert ist - steht wo anders :) muss ich nachschauen)


    Sprite 3: 01, 01, 02, 02, 03, 03, 03, 03, 04, 04, 04, 04, 04, 04, 04, 04, 05 05
    Sprite 0: ??, ??, ??, ??, ??, ??, 08, 08, 08, 08, 09, 09, 09 .....
    Multicolor 1 (D025): ??, ??, ??, ??, ??, ??, ??, ??, ??, ??, ??, ??, 03, 03, 03, 03....
    Multicolor 2 (D026): ??, ??, ??, ??, ??, ??, ??, ??, ??, ??, ??, ??, ??, ??, 0a, 0a....


    wobei ich nun davon ausgegangen bin, dass in den anderen Farbtabellen nur 0er Highnibbles verwendet wurden.
    Dort kann man natürlich auch die FLI Bug Spritefarben in der selben Art ändern.


    edit:
    Die Initialfarben vom Screenanfang für die FLI Bug Sprite kommen hier her:
    .C:31ba AD F0 3F LDA $3FF0
    .C:31bd 8D 26 D0 STA $D026
    .C:31c0 AD F1 3F LDA $3FF1
    .C:31c3 8D 25 D0 STA $D025
    .C:31c6 AD F7 3F LDA $3FF7
    .C:31c9 8D 27 D0 STA $D027
    .C:31cc AD F6 3F LDA $3FF6
    .C:31cf 8D 2E D0 STA $D02E

    Zitat von Roland

    Wenn sich nun aber die Spritefarbe in aufeinander folgenden 2er Lines sich nicht ändert, braucht man die Farbe ja auch nicht erneut setzten.
    Und genau dann kann man diese Zeit nutzen um eine andere Speicherstelle zu verändern. Eben genau eine Farbe der FLI-Bug Sprites.


    Genau das wird über das Highnibble in der 6 Farbtabellen definiert.
    Ist das Highnibble = 7 (also z.B: $71), wird die Spritefarbe weiß in das Sprite 0 ($D027) gesetzt. Egal in welcher der 6 Tabellen das steht.

    Genau sowas Schrilles hatte ich schon befürchtet... ;-)


    Na gut, dann muss ich da auch noch durch! Das Pixelgewusel (das ich erwähnt hatte) ist inzwischen behoben. War natürlich ein dummer Fehler: Das NuFLI steht in GoDot (bzw. in der REU) ja ganz woanders, da sollte man schon dran denken, wenn man die Positionstabelle eingibt...
    :platsch:
    Und schließlich muss ich immer noch überlegen, wie ich die AFLI-Vordergrundpixel auch wieder nach vorne rendere, denn in GoDot ist jeder der 64000 Pixel gleichwertig, da gibt's keinen Vorder- oder Hintergrund. Mal sehen, vielleicht rendere ich aus dem AFLI zuerst die Hintergrundpixel, dann die Sprites und zum Schluss die Vordergrundpixel, muss mir dafür einen "Schalter" ausdenken. Hoffentlich reicht der Platz, wird langsam eng... (ich hab nur dreieinhalb Tausend Bytes pro Modul). :-)


    Arndt


    PS: Ach so, die Initialfarben (letzter Teil in deinem Post) hatte ich schon gefunden, reicht natürlich nicht. Das Testbild hat damit noch einen senkrechten schwarzen Balken im oberen Bildteil, Spritebytes 2 und 3 pro Rasterzeile bleiben schwarz (müssten weiß sein). Mache morgen mal wieder ein Bild vom Zwischenstand.

    Hier wie versprochen der letzte Stand (mit dem schwarzen Balken):


    Den Balken sieht man, wenn man draufklickt.


    Kann sein, dass da noch ein Fehler meinerseits dahintersteckt. Aber erstmal implementiere ich die Farbwechsel, dann weiß man mehr... ;-)


    Arndt


    PS: Der Spritelayer ist immer noch vorne, auch im FLI-Bug-Streifen.

    Die Priorität ist beachtet, zuerst Multi, darüber Hires (zuletzt die AFLI-Pixel, die sind aber jetzt noch ganz hinten).


    Das NuFLI ist hier angehängt. Ist aus buexes Galerie.


    Arndt


    Art_073.zip

    Zitat von GoDot

    Die Priorität ist beachtet, zuerst Multi, darüber Hires (zuletzt die AFLI-Pixel, die sind aber jetzt noch ganz hinten).

    Hut ab! Ich glaube, dass das Bild schon fast perfekt aussehen wird, wenn Du die AFLI-Vordergrund-Pixel nach ganz vorne holst. Der Rest sind dann bestimmt nur noch ein paar Kleinigkeiten.

    Zitat von ssdsa

    Ich glaube, dass das Bild schon fast perfekt aussehen wird, wenn Du die AFLI-Vordergrund-Pixel nach ganz vorne holst. Der Rest sind dann bestimmt nur noch ein paar Kleinigkeiten.

    Sieht aber nicht danach aus. Ja, im AFLI-Teil passt es, aber im FLI-Bug stimmen die Pixel nicht. Ich nehme mal ein anderes Testbild, wo sich viel dort tut. Momentan stimmt nur die allererste Rasterzeile komplett. die nächsten drei Rasterzeilen stimmen im ersten Spritebyte, und ab dann wird's eher beliebig. Kann man schön sehen, wenn man den NuFLI-Editor daneben stellt. Ich suche jetzt erstmal nach einem Fehler in meinem Code, einen hab ich schon rausgefunden (nach dem Multi-Sprite wurden die Adressen nicht ordentlich für das Hires-Sprite re-initialisiert). Mal sehen... Sch*** Fehlersuche.


    Arndt

    Werden die Farben wieder auf die Vorgabe (im Speedcode-Interrupt) zurückgestellt? In deinem Beispiel hier nicht.


    Arndt

    Neuer Stand. Hab erst das Hauptbild bearbeitet und den FLI-Bug ruhen lassen. Jetzt liegen die AFLI-Pixel vorne, es sollte eigentlich alles richtig sein im Hauptbild.



    Aber! Es sind Farbfehler drin. Am deutlichsten der gelbe Strich über dem Auge links und der weiße Strich an der Nasenspitze. Links unten kurz vor Bildende sind drei graue Pixel statt nur einem an dem gelben Schimmer dort. Rechts am Rand zum weißen Bereich sind auch ein paar Pixel mehr als sollen.


    Kann es sein, dass ich die Sprites um ein Pixel senkrecht verschieben muss? Überall sonst stimmt's!


    Arndt

    Ja, war eine gute Idee:


    :bia


    Sieht fehlerfrei aus. (Ist es aber nicht: Der kleine schwarze Strich links unterhalb des Auges links müsste gelb sein (ist aber schwarz). In anderen Bildern kommen ebenfalls solche winzigen "Ausfälle" vor, manchmal deutlicher. Grund ist mir (noch) nicht klar.)


    Jetzt zurück zum FLI-Bug. Was ist da so *völlig* falsch? <grübel>


    Arndt


    ( :tanz: ...ist guter Dinge! :tanz: )

    Neuer Stand, neues Beispielbild:


    Ein NuFLI mit überdecktem FLI-Bug


    GoDots Version davon, der FLI-Bug stimmt jetzt


    Hier das NuFLI-File: art052.zip


    Was war Fehler? Ich hab die Kontrolle über den Rasterzeilenzähler nicht im Griff gehabt... :gahh::honk::haue::nuss::facepalm: Oh Mann!
    Aber der Lader ist noch nicht fertig. Seht ihr den Strich zwischen den beiden unteren Blumen? Der setzt sich über die ganze Breite fort (rechts ist sogar ein grün-weißer Block) und darunter in den hellblauen Blättern sind Farbstreifen, die da nicht hingehören. Ich muss also nach was suchen, was die Sprites betrifft, aber nur manchmal eintritt. Ich hatte erstmal die Farbumschaltungen für die FLI-Bug-Sprites im Verdacht, aber *eigentlich* ist der Code da sicher... Andere NuFLIs haben noch mehr solcher Fehler in der GoDot-Anzeige. Jetzt ist wieder Bug-Tracking angesagt, mir raucht der Schädel schon... :smoke:


    Arndt


    Ergänzung: Das ganze Sprite 6 macht Probleme...

    Zitat von d020

    Die Farben sehen im GoDot auch anders aus. Weniger kräftig.
    Ist das Absicht?

    Oh, das obere ist ein Screenshot und hat die GoDot-Palette. Das untere hab ich in GoDot (als GIF) mit der Deekay-Palette abgespeichert. Das sollte nicht verwirren. Mach ich dann beim nächsten Mal anders.


    Ansonsten suche ich...


    Arndt

    Zu den Sprites. Ja, die Farbe wird dort immer in den geraden Zeilen verändert. (2,4,6,....) wärend die FLI Farben in den ungeraden Zeilen veränderten werden (1,3,5,...)
    Bei dem blauen Blumenbild scheint im unteren dritten ein paar Zeilen falsch zu sein. Sieht man besonders in den blauen Kugeln auf der rechten Seite.


    und es scheint, als ob auf der rechten Seite Teile der Sprites fehlen. Denn da sind alle Kugeln "leer". Nur dunkelblauer Rand, und innen hohl/schwarz.
    D.h. der erste Char des ganz rechten Sprites ist noch da, aber Char 2 und 3 fehlen.

    Zitat von Roland

    es scheint, als ob auf der rechten Seite Teile der Sprites fehlen. Denn da sind alle Kugeln "leer". Nur dunkelblauer Rand, und innen hohl/schwarz.
    D.h. der erste Char des ganz rechten Sprites ist noch da, aber Char 2 und 3 fehlen.

    Ah, danke für diesen Hinweis! Das war wichtig: der erste Char war korrekt, die nächsten beiden nicht mehr. Dadurch bin ich auf den Fehler gekommen und hab ihn entfernt.


    Wo ich aber überhaupt nicht weiterkomme, ist bei diesen Streifen, die eigentlich (für mich) völlig unmotiviert eintreten. Sie rühren von der Einfärbung des Hires-Sprite-Layers unter dem AFLI her. Das Problem ist, dass GoDot die Farben an jeder Stelle genauso wiedergibt, wie es die NuFLI-Daten vorgeben. Hier ein Beispiel, wo man das deutlich sieht:



    Links ein Screenshot von einem NuFLI, rechts das GoDot-Bild davon. Es ist voll mit diesen Streifen! Hier mal ein etwas genauerer Blick auf die betroffenen Stellen (der Ausschnitt liegt oben am Rand, etwa in der Mitte, zwischen den beiden Haarsträhnen, die über das rechte (das linke auf dem Bild) Auge gehen. Dort befinden sich Sprite 3 und Sprite 4. Zuerst die Farbdaten an der Stelle (bis auf das erste Byte sind das die Spritefarben für je zwei Rasterzeilen für die Sprites 3 und 4):


    Code
    1. 2800 0a 0a e6 6e ef 0a 0a 0a 0f 0f 0f 59 64 68 0f 0f...
    2. ...
    3. 2880 08 02 09 0a 64 ee 79 69 0a 68 0a 70 56 72 0a 79...

    Es geht vor allem um die Bytes $2801 bis $2807 (Sprite 3) und $2881 bis $2887 (Sprite 4). Der Bildausschnitt:



    Links der Zoom in GoDot (mod.PixelEdit), rechts die gleiche Stelle im NuFLI-Editor (der zeigt rechts einen Char mehr). Ihr seht schon, wo es kracht: Alles Blaue, Hellblaue und Purpurne ist verkehrt, in der Mitte ist zusätzlich zu viel Braun. Der erste Char ganz links gehört noch zu Sprite 3, die drei nächsten zu Sprite 4. Und was sagen die Farben? Im Code-Schnippsel seht ihr $0a (hellrot) für die oberste Rasterzeile, noch mal $0a für die Rasterzeilen 1 und 2, $06 für die Rasterzeilen 3 und 4 (blau!!!, das e im Hi-Nibble steht nur für den FLI-Bug da, ebenso wie die 6 im nächsten Hi-Nibble), $0e (hellblau!!!) für die Zeilen 7 und 8. Den Rest könnt ihr selber fortsetzen. Die Farben sind genau die, die GoDot erkennt und anzeigt. Im NuFLI werden aber nun andere angezeigt. Meine Frage: Woher kommen die? Was muss ich beachten? Hat das was mit Vorder- und Hintergrund zu tun? Hier die gesetzten Pixel (aus die AFLI-Bitmap):



    Ist die gleiche Stelle.


    Ich stecke fest! GoDot tut eigentlich genau das, was die Daten sagen. Es stimmt aber nicht mit dem fertigen Bild überein.


    Arndt

    Ich hatte es schon in vorherigen Posts erwähnt (aber vielleicht hab ich es nicht deutlich genug erklärt).
    Z.B. in der Tabelle 2880:


    2880 08 02 09 0a 64 ee 79 69 0a 68 0a 70 56 72 0a 79



    Du darfst im AFLI Bereich nur die Bytes mit dem Highnibble 0 verwenden, und die anderen Bytes "überlesen", bzw. die vorherige Farbe beibehalten, da alle anderen Bytes für die FLIBUG Sprites sind (oder das neu setzen der Y Position im unteren Bereich)
    Das würde in deinem Beispiel folgendes bedeuten:


    2880 08 02 09 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a


    Technisch gesehen ist das ja auch leicht erklährt. Man muss die Spritefarbe ja nicht jede Zeile neu setzen, wenn sie sich nicht verändert.
    Der VIC behält die Spritefarbe ja einfach bei, wenn man nicht ins entsprechende Register schreibt.


    Die Bytes 64, ee, 79, 69, 70, 56, 72 und 79 werden für andere Sprites ($d026, $d02e, $d027 und $d025 verwendet)
    Also an der Zeile wo 64 steht, wird $04 in das Speite $d026 geschrieben (und eben nicht in das Sprite des Farbtabelle 2880)

    Zitat von Roland

    Du darfst im AFLI Bereich nur die Bytes mit dem Highnibble 0 verwenden, und die anderen Bytes "überlesen",

    Glaub es oder nicht: Heute Nacht hatte ich im Traum genau diese Erleuchtung, deinen Post Nr. 69 noch mal mit Verstand nachgelesen und jetzt weiß ich, was los ist! Oh, Mann! Wie oft musste ich mir jetzt die Birne behämmern... ;-)


    Hier ist noch das art021.zip vom letzten Beispiel. Leider muss ich jetzt weg und kann erst nachher weitermachen...


    Arndt