Sprites und Timing... ein paar Fragen!

tjaaa.... das mit den sprites über stabilen rasterklamotten ist eins der frickeligsten sachen auf dem c64

bei demos ist das oft so das die sprites sich in Y garnicht wirklich bewegen, sondern per d017 stretching oder sprite-crunching über den bereich gestretcht werden, und um den bewegungseffekt zu simulieren dann zeilenweise spritepointer umgeschaltet werden.

eine andre möglichkeit wäre 8 verschiedene interrupt routinen zu stricken, die dann jeweils so ausgetimed sind das sie mit 1 ... 8 sprites an der stelle richtig sind. oder halt eine einzelne routine die per selbstmodifikation entsprechend angepasst wird.

wie gesagt, frickelig

Das Einfachste wär natürlich, zwischen den unterschiedllichen Scrollbereichen Minimum eine Line freizulassen, in der Du in Ruhe umschalten kannst. Aber wir sind ja keine Mädchen!

Ansonsten würde ich, die Idee von Sauhund aufgreifend, wie folgt vorgehen:

Du löst den Rasterirq bereits 2-3 Zeilen vor der Line aus, in der $D016 gesetzt werden muss. Die Zeit zwischen dem Rasterirq und dem eigentlichen Umschaltzeitpunkt überbrückst du mit einer einfachen Warteschleife auf dex beq wait Basis. Mittels unterschiedlicher Werte im X-Register kannst Du nun das Timimg variieren. Der Wert X ist also unsere Variable, mit der wir auf unterschiedliche Timingkonstellationen bzw. -erfordernisse reagieren.

Jetzt musst Du "nur" noch vor Aufruf der IRQ-Routine jeweils alle Y Koordinaten der Sprites prüfen und checken, ob diese in die Umschaltline hineinreichen. Für jedes Sprite, dass diese Bedingung (Überlappen mit der Umschaltrasterline) erfüllt, erhöhst Du einen jeweils vor der Prüfung auf 0 gesetzten Pointer um 1. Dieser nimmt jetzt also je nach Anzahl der Sprites, die überlappen, Werte von 0 bis 8 an. Diesen Pointer nutzt Du nun als Zeiger auf eine Tabelle, in der 8 verschiedene Werte stehen, die Du als Timer im Interrupt ins X-Register lädst.

(Heist natürlich, dass Du vorher zunächst von Hand für 0-7 Sprites, die Überlappen, den entsprechenden Timingwert fürs X-Register ermitteln musst. Hier ist ausprobieren angesagt.)

Ich hoffe, das war verständlich soweit... Wenn nicht frag gerne nach. So denke ich aber , könnte es funktionieren.

Gruß, André

Hmm. Laut Pasi Ojalas "Missing Cycles" Artikel in C=Hacking 3 könnte die Sache noch wesentlich komplizierter sein. Demnach "verbraucht" VIC 3 Cycles pro Sprite, alle hintereinander weg. Die CPU muss nur (so Pi mal Daumen) für jeweils 2 davon gestoppt werden, aber der CPU wird der Bus schon 3 Cycles bevor VIC was lesen muss der Bus abgedreht, wodurch dann je nach Spritekonstellation zusätzlich was verloren geht, weil die Zeit nicht reicht um den Bus zwischen 2 Spritelesungen wieder freizugeben (oder so ähnlich jedenfalls).

Falls das stimmt würd ichs einfach flackern lassen und noch n Scrolltext dazu machen, wo ich mich beim Betrachter für die Unannehmlichkeiten entschuldige

Zur Not schnappste dir halt n Byte und setzt für jedes Sprite das im Weg ist n Bit, um damit den passenden Verzögerungswert aus ner Tabelle mit allen 256 möglichen Kombinationen zu holen, wenn du Zschigis Idee umsetzen willst.

Ansonsten sorg halt dafür, dass immer irgendwie alle Sprites den kritischen Bereich überdecken, wie Sauhund vorgeschlagen hat. Dann bleibt zwar nicht viel Zeit, aber die ist wenigstens konstant. Vielleicht hast du ja Glück und es reicht schon ein einfacher Multiplexer dafür.

So, ihr macht mich noch ganz wuschig!!!

Hab mir jetzt mal fix ne Miniroutine gestrickt, um den Spass zu testen. Testkonstellation waren in der Bildmitte gesetzte Sprites über einer einzeln eingefärbten $d021 Line. Ausgetimet habe ich diese mittels der "dex-bne wait-Schleife", wobei ich die Werte hier jewiels vor dem Programmstart von Hand geändert habe. (Dies entspricht letztlich dem "Probierteil", von dem ich oben sprach.)

Fakt ist mit X-Werten zwischen 02 bis 0a kann man es sauber timen. Dabei kommt es für das Timing allein auf die Anzahl der überlappenden Sprites an. Es ist also völlig egal, ob Sprite 1 und 8 oder Sprite 4 und 5 drüberliegen. Entscheidend ist nur, dass es zwei an der Zahl sind. Somit sollte die Routine so funktioinieren, wie ich denke, also mit lediglich 8 unterschiedlichen Timings

Noch ein weiterer Gedanke, solltest Du mit der Verzögerungsschleife nicht genau genug timen können, kannst du es auch mit einem NOP-Unterprogramm machen. Du springst also einfach ein Unterprogramm an, das nur aus NOP´s besteht. Vor dem Anspringen schreibst Du jedoch eine $60 (=RTS) an eine bestimmte Stelle (Offset) nach der Basisadresse des Programms. Den Offsetwert holst Du Dir wieder aus der Timingtabelle (wie bei der Warteschleife). Ist der Offsetwert also z.B. 4 Schreibst du an die vierte Stelle nach der Ansprungadresse ein NOP. Im Ergebnis werden dann vor dem RTS vier NOP´s ausgeführt. Aber wie gesagt, m.E. schafft man es schon mit der Verzögerungsschleife.

Gruß, André

Zitat

Vor dem Anspringen schreibst Du jedoch eine $60 (=RTS) an eine bestimmte Stelle (Offset) nach der Basisadresse des Programms.

das kann man aber einfacher haben....

mmmh geht das so? zu faul zu testen jetzt aber die idee dahinter sollte klar sein

Sieht gut aus, sogar cycleexakt, wenn ich das BCC richtig verstehe.

Zitat

Sieht gut aus, sogar cycleexakt, wenn ich das BCC richtig verstehe.

ja genau....ist praktisch die standardlösung dafür wenn man irgendwas im timing cycle für cycle rumschieben will (braucht man für dma-delay zb)

@sauhund: Du hast natürlich Recht! Da stand ich mir selbst im Weg. Die Routine, wie ich sie verwendet hatte kommt in Enforcer II im Level 2 in starker Abwandlung für einen grafischen Effekt zur Anwendung, wo es nicht nur um ein Austimen geht, sondern ganz konkret unterschiedliche Befehlsabläufe vom Start bis zu einem gewissen (jeweils in Abhängigkeit von der Frame zu bestimmenden) Stopp abgearbietet werden müssen. Da gehts dann nur so, wie ich es gemacht habe. Aber beim Austimen wie hier, ist das freilich auf Deine Weise viel (!!) einfacher zu haben. Das hatte ich durch meine "Enforcer-Scheuklappen" völlig verpeilt!

Jetzt bin ich grad unsicher, müsste es nicht BCS sein, weil bei Rest 1 ein Cycle mehr verbraucht werden sollte? Ich bin jetzt auch schon ganz "wuschig", um es mit Zschigis Worten zu sagen

EDIT: Ach was solls, das kann man ja ausprobieren.

es ist "falschrum" weil ja je mehr verzögert werden soll eine kleinere zahl in die routine "rein" kommt (denk dir das eor#$ff am anfang mal weg) ... verwirrt mich auch jedesmal

Ja, richtig, das ist ja sozusagen der Kehrwert der verbleibenden Cycles, da sollte man dann auch "falschrum" runden müssen. Diese Cyclezählerei ist echt zum Kotzen

ach was.,..wenns die nich gäbe könntest du ja gleich aufm pc coden =P

Pah, Perfektion ist was für Perfektionisten. Solange Mr. Monk sich das Resultat nicht anschaut...