Genau das wollte ich mir sparen deshalb den SpritePad 2.0 genommen 
Hallo Besucher, der Thread wurde 6,7k mal aufgerufen und enthält 99 Antworten
letzter Beitrag von ivettaB am
Sprite Multiplexer killt mich noch...
- ivettaB
- Erledigt
-
Ja, da musst du schon selbst ran.
Das verdoppeln ginge auch Problemlos in 6502 selbst. Etwas kniffliger ist der Inhalt der Zeilen nach der verdoppelten
-
einen Thread habe ich davon nicht gesehen, ist ja nur ein AVI File verlinkt...
Original hatte ich das hier gepostet: Maniac Mansion - technische Details?
Der Thread ist auf jeden Fall auch lesenswert.
Da wird nur ein Hardwaresprite benötigt, welches immer jeweils um 21 Zeilen nach unten gesetzt wird. Der Spritepointer wird hingegen alle 20 Zeilen umgeschaltet. Das sollte auch mit 8 Sprites möglich sein.
-
Alles anzeigenNein, ManiacMansion nutzt je 'Saeule' nur ein Sprite.
Wie gesagt, das solltest Du mal aufzeichnen
Details:
- man kann die neue y-Position jeder Zeit setzen, die kommt erst zu tragen wenn das laufende Sprite fertig ist
- Wenn man im laufenden Spritedisplay dessen Pointer aendert, wird der Inhalt vom neuen Sprite ab sofort gezeigt, ABER der 'Zeilencounter' bleibt erhalten.
Schalte ich also in (und nicht nach!) Zeile 21 um, wird in dieser Rasterzeile teilweise Zeile21 vom alten und Zeile21 vom neuen Sprite angezeigt.
Genau das erzeugt das 'flickern'. Wenn beide Zeilen den selben Inhalt haben, entfaellt das Flackern.
Also das untere Sprite kopiert in seiner Zeile 21 den Inhalt von Zeile 21 des oberen Sprites.
In der Spritereihe darunter muss man dann NOCH eine Spritezeile frueher umschalten, weil Zeile 21 ja schon verbraucht wurde.
Etc etc. Je Sprite-Reihe steht Dir also 1 Sprite-Daten-Zeile weniger zur Verfuegung.
Das entspricht einem Umschalten alle 20 Zeilen.
Beim erstem mal an Stelle 20, statt 21, dann an stelle 40 statt 42, dnn 60 statt 63....
sehe ich das richtig ? das ist das selbe wie hier:
https://codebase64.org/doku.php?id=base:sprite_interleave
Wurde oben am anfang schon beschrieben.
Klingt für mich gleich....
-
$4000 ist schluss mit VIC BANK ....
Da fängt meine normalerweise an wenn ich mal was code. Denn dort hat man die vollen 16K zur Verfügung.
Gibt es einen bestimmten Grund, dass Du Bank 0 benutzt ? -
Klingt für mich gleich....
Für mich auch.
Allerdings erscheint mir die Grafik dort gewaltig unverständlich zu sein.
Der Text zu den duplizierten Zeilen beschreibt es aber besser:
line 20 of row 0 into line 20 of row 1
line 19 of row 1 into line 19 of row 2
…
line 12 of row 8 into line 12 of row 9
=> Row meint Sprite-Block, Line meint Pixel-Zeile. Die Hardware-Sprites werden alle 21 Pixel wiederholt.
Die Grafik von Block 0 / Zeile 20 wiederholt sich in Block 1 / Zeile 20, und bei jedem weitere Spriteblock wiederholt sich eine Pixelzeile mehr.
-
...
In der Spritereihe darunter muss man dann NOCH eine Spritezeile frueher umschalten, weil Zeile 21 ja schon verbraucht wurde.
Etc etc. Je Sprite-Reihe steht Dir also 1 Sprite-Daten-Zeile weniger zur Verfuegung.
Das entspricht einem Umschalten alle 20 Zeilen.
Beim erstem mal an Stelle 20, statt 21, dann an stelle 40 statt 42, dnn 60 statt 63....
dann werden die Sprite in jeder Sprite Linie (24x20) pixel immer gestauchter je weiter ich runterkomme und habe in der 8. Spriteline
160-8 = nur mehr 159 pixel (24x10) also nur mehr 10 Pixel Höhe ?
Echt ?
-
Sprite Crunch gennant - auch eine art overlapping
Nee, das ist was anderes.
Das ist ein Trick, um den Sprite-internen Zähler zu manipulieren.
Der wird normalerweise um 3 Bytes pro Zeile weitergeschoben, um dann bei $3f=63 abzubrechen.
Mit "Sprite Crunching" wird der Pointer je nachdem, in welcher Sprite-Zeile man diesen Trick anwendet, auf ganz was anderes gesetzt als 3 Werte weiter.
Damit geht dann eine Stauchung von 21 auf 16 Zeilen, aber auch sowas verrücktes wie ein ca. 3mal so hohes Sprite, weil der Zähler z.B. von $3d auf $00 rumwrappt, und dann das Sprite weitergemalt wird.
-
Sprite Crunch gennant - auch eine art overlapping
Nein, ist was anderes. Dort wird der Zähler für die 21 Pixelzeilen durcheinandergebracht, damit das Sprite am Ende etwas kürzer als 21 Zeilen ist.
Für einen normalen Multiplexer bleibt es aber bei 21 Pixeln.
dann werden die Sprite in jeder Sprite Linie (24x20) pixel immer gestauchter je weiter ich runterkomme und habe in der 8. Spriteline
160-8 = nur mehr 159 pixel (24x10) also nur mehr 10 Pixel Höhe ?
Echt ?
Jein.
Ja, weil: Der oberste Block hat 21 Pixel Grafik, der nächste 20, dann 19, 18... bis es zur Stelle mit dem Sprung kommt.
Und nein,weil: Der Sprung ist nur 1 Pixel hoch, danach geht es "normal" weiter. Das AVI beschreibt es imho sehr gut.
-
Willst Du die Sprites auch vertikal bewegen? Gibt es da einen Algorithmus, der entscheided, welches Objekt durch welches Sprite dargestellt wird? Also Du hast mehrere Objekte, die vertikal über den Bildschirm fliegen und musst die darstellen.
-
Die Sprites müssen aneinanderkleben, und der Vorteil ist, dass man keine Probleme mehr mit Badlines hat.
In einer Nicht-Badline kann man alle 8 Spritepointer updaten.
-
Die Sprites müssen aneinanderkleben, und der Vorteil ist, dass man keine Probleme mehr mit Badlines hat.
In einer Nicht-Badline kann man alle 8 Spritepointer updaten.
heisst das: ich muss in einer "nicht Badline" die Pointer ändern und nur da ?
meinst du das ?
Wenn ja ist es bei der SpriteWall ja nicht auszuschliessen wenn ich oben am Schirm beginne - irgendwann dann doch
genau in einer Badline die Linie 20 Umschaltung machen muss damit die Teile vom MOND passen ?
-
Willst Du die Sprites auch vertikal bewegen? Gibt es da einen Algorithmus, der entscheided, welches Objekt durch welches Sprite dargestellt wird? Also Du hast mehrere Objekte, die vertikal über den Bildschirm fliegen und musst die darstellen.
Nein Daybyter heute nicht. Ich will ein Hintergrundbild aus Sprites erzeugen und unter ein Spiel legen.
Da soll sich nichts bewegen. Das tut der Vordergrund (CHARACTER SET)
Was Du meinst ist das:
https://codebase64.org/doku.ph…ble_48_sprite_multiplexer
Ich kämpfe mit Lücken in der Spritewall durch Badlines.
Der VIC braucht die ganze Rasterzeit für Grafik + Sprites und ich habe im Programm keine Zeit alle Spritepositionen und Bilder pro
21 Zeilen schnell genug zu ändern da die 6502 komplett gebremst ist.
Normale Zeile 64uS (microseconds) = 64 6502 Zyklen
bei Badline zugriff vom VIC II Chip bleiben 18-20 übrig für CPU , da ich jedesmal 1-3 6502 zyklen verliere beim BUSÜBERNAHME des VICs
und der braucht dann 3*8 =24 Zyklen um seine 8 Spritedaten (pixel) zu holen. also habe ich schon 4 Zyklen von der nächsten Zeile verbraucht.
Dabei hat mein Programm nicht mal einen Befehl ausgeführt !
Um das geht es.
-
Verschiebe Deine VIC-Bank nach $4000, dann kannste Du den gesamten Bereich für Grafik nutzen.
Um die Sprite-Pointer "bequem" umzubiegen, könntest Du auch mit zwei screen-RAMs arbeiten, dann musst Du für das Umschalten der Pointer nur $d018 anpassen:
1. screen-RAM A wird mit den Spriter-Pointern vorbereitet und mittels $d018 aktiv geschaltet
2. Du hast nun 21 Rasterlines Zeit, die Sprite-Pointer für Reihe 2 vorzubereiten in screen-RAM B
3. Wenn Sprite-Reihe 1 beendet ist, schaltest Du $d018 um auf screen-RAM B => VIC liest die neuen Sprite-Pointer
4. Du hast nun 21 Rasterlines Zeit, die Sprite-Pointer für Reihe 3 vorzubereiten in screen-RAM A
5. Wenn Sprite-Reihe 2 beendet ist, schaltest Du $d018 um auf screen-RAM A => VIC liest die neuen Sprite-Pointer
Das ganze kann auch kombiniert werden mit der "Eine Zeilen überlappen" Methode um somit glitches beim Umschalten (oder auch bei badlines) vorzubeugen, denn Du kannst somit "irgendwo" innerhalb der einen Zeile den Pointer mittels $d018 umbiegen.
