Hello, Guest the thread was called3.6k times and contains 99 replays

last post from ivettaB at the

Sprite Multiplexer killt mich noch...

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

  • jetzt bin ich soweit


    in Zeile $fa (am Ende des schirms) beginne ich mit meiner VBLANK routine

    welche aus der SpriteTab+512 (wo die Bilder stehen für $07f8-07ff)

    ausliest und in die 8 Interrupt Programme einpatched


    danach setze ich den Raster IRQ auf Zeile 53 (begin vom Schirm)

    und sage ciao mit RTI


    2)

    der nächste IRQ (ist Zeile 53):

    Da werden alle Y Werte meiner 8 Sprites auf 53 gesetzt

    und der Speedcode der die Bilder updated gesetzt


    in Codisch gesprochn:

    danach setze ich den IRQ auf die Zeile 53+21 und beende mit RTI


    wenn der RasterIRQ auf 74 ist wird wie bei Punkt 2)

    die neuen Y werte gesetzt UND die neuen Bilder


    das geht durch alle weitern Zonen bis alle 8 dargestellt sind


    danach setze ich IRQ nochmals +21,

    male eine weisse Linie und mache den Rahmen Schwarz

    setze den RasterIRQ wieder auf 53

    und ciao (rti)


    Aber die Bilder stimmen nicht richtig.

    Entweder ist der VIC überlastet oder ich hab ein Tabellenproblem,

  • übeltäter gefunden

    blödes copy paste


    code

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

  • Genau über diese Textstelle stolperte ich auch und dachte mir ist das noch english ?


    das ist dann auch das oder ?

    https://www.linusakesson.net/scene/lunatico/misc.php


    Sprite Crunch gennant - auch eine art overlapping



    MesserJocke: Ja das hat den Grund da das original Spiel Space Invaders (commodore 1982 : Avenger) genau da läuft

    und den Charset dazu noch bei $0000 hat (!)

    Kraas aber es is so

    Ich will ja meine SpriteWall dahinterkleben wenn der Code doch mal laufen würde....


    im Moment bin ich da:


    Fange jetzt mit Enthusis Overlap an und zeichne gerade am Papier die Koordinaten damit ich was wie ich das machen muss

  • ...

    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.

  • ist das so gemeint mit der Sprite säule ?

    sieht das so aus...

    und ja die Linie vom Sprite 2 (invader) (Zeile 21) sehe ich jetzt in Sprite 1 (Baloon)


    Oder muss ich den Sprite auf 121 (d001) setzen ? wenn ich das mache kleben die Sprites wirklich aneinander.

    Ich weiß nicht was jetzt hier ein Vorteil ist.

    Hab ich jetzt Cyclen eingespart oder muss mich nicht mehr um Badlines kümmern ?

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