Wann wird das Sprite-Sprite-Kollisions-Register gesetzt

Es gibt 11 Antworten in diesem Thema, welches 2.197 mal aufgerufen wurde. Der letzte Beitrag (25. Oktober 2017 um 18:46) ist von Wiesel.

  • Die Frage steht ja eigentlich oben - warum mir das wichtig ist:

    In Kombination mit dem Sprite-Multiplexing frage ich mich von welchem Abbild ich die Information bekomme?
    Kann ich das Register vor und nach dem Umsetzten des Sprites innerhalb eines Bildschirmaufbaus abfragen und bekomme immer das tatsächliche Ergebnis ?
    Oder bekomme ich immer das Ergebnis bezüglich des Zustands zu einem bestimmten Zeitpunkt (z.B. immer so wie die Sprites beim RasterRücklauf sind) ?
    Oder wird es immer genau dann ermittelt, wenn ich das Register lese (was mir vom Timing her aber eher komisch vorkommt)?

  • Der VIC setzt die Bits in den Kollisionsregistern immer genau dann, wenn die Kollision auch stattfindet, also wenn quasi zwei oder mehr Pixel gleichzeitig gezeichnet werden müssten. Gelöscht wird das Register beim Lesen.

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • Das Kollisions-Bit wird genau in dem Moment gesetzt, wo die Kollision auf dem Bildschirm dargestellt wird.

    KI-Verwendung in diesem Posting: Rechtschreibkontrolle des Browsers.
    Abweichungen aufgrund des technischen Fortschritts oder individueller Vorlieben vorbehalten.

  • Oh, mann.
    Und da das Register nicht von selber gelöscht wird, habe ich dann die Kombination von allen Positionen beim multiplexen mit drauf.
    Hm...dann ist das Register für die Checks in komplizierten Fällen nicht zu gebrauchen.

    OK.
    Danke für die Antworten.
    Eventuell sollte man die Info im Commodore Wiki ergänzen - ist durchaus wichtig.

  • Du kannst bei Sprite/Sprite-Kollisionen auch Interrupte auslösen lassen, Bit 2 des IRR.
    Hab ich nie benutzt, könnte je nach Zusammenspiel mit RasterIRQ und anderen IRQs auch ein bisschen geistige Fitness brauchen.

  • Wenn das Register automatisch gelöscht würde, könnte man es nie auslesen...

    KI-Verwendung in diesem Posting: Rechtschreibkontrolle des Browsers.
    Abweichungen aufgrund des technischen Fortschritts oder individueller Vorlieben vorbehalten.

  • Wenn das Register automatisch gelöscht würde, könnte man es nie auslesen...

    Naja, so ist das ja nicht.
    Schau mal, das reale Verhalten ist schon verwirrend: Kollidieren zwei Sprites einmal, so ist das entsprechende Bit gesetzt - und zwar immer, auch wenn die Sprites dann wieder auseinander gehen.
    Das hatte mich anfangs schon sehr verwirrt. Viele andere Register zeigen nämlich immer den aktuellen zustand. Um hier den aktuellen Zustand zu bekommen muss ich als das Register auslesen (dabei wird es gelöcht) und dann (wie ich jetzt gelernt habe) so lange warten bis die Sprites erneut gezeichnet wurden.

    Die VIC-Entwickler hätte funktional auch ein Register zur verfügung stellen können, dass immer den aktuellen Zustand anzeigt und dafür beim Auslesen nicht gelöscht wird (die Frage ist natürlich ob das Laufzeittechnisch machbar gewesen wäre).

    Aber hätte könnte ist ja nun egal. Ich weiß ja jetzt was ich wissen muss:
    Für meinen aktuellen UseCase ist das Registe nix und ich schreib mir da besser eine Abstandsberechnung und ermittle meine Kollisionen so.

  • Die Zeitspanne, in der die beisen Sprites kollidieren, ist irgendwo zwischen 0.125 Mikrosekunde (einzelnes Pixel kollidiert) und 3 Mikrosekunden (alle 24 Pixel pro Zeile, nicht gestreckt) lang. In der Zeit schafft der Prozessor noch nichtmal einen einzelnen Ladebefehl, geschweige denn eien Testschleife um auf ein Ereignis zu warten.

    Stell' Dir die Kollision ruhig wie eine Beule am Auto vor: Die geht ja auch nicht weg, sobald der Unfallgegner abrückt.

    KI-Verwendung in diesem Posting: Rechtschreibkontrolle des Browsers.
    Abweichungen aufgrund des technischen Fortschritts oder individueller Vorlieben vorbehalten.

  • Und da das Register nicht von selber gelöscht wird, habe ich dann die Kombination von allen Positionen beim multiplexen mit drauf.

    Aber grade beim Multiplexen hat man doch eh schon an der passenden Stelle innerhalb des Frames Code, der die Register umschaltet. Wenn man da dann auch die Kollisionen abfragt anstatt am Ende eines Frames, sollte das doch gut funktionieren?

    ────────────────────────────────────────────────────────────
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    ────────────────────────────────────────────────────────────

  • beim Multiplexen hat man doch eh schon an der passenden Stelle innerhalb des Frames Code, der die Register umschaltet. Wenn man da dann auch die Kollisionen abfragt anstatt am Ende eines Frames, sollte das doch gut funktionieren?

    Nur in einfachen Fällen. Das Problem ist, dass man die Kollisionsregister erst dann sinnvoll auslesen kann, wenn die Sprites wirklich fertig gezeichnet wurden - also 21 Rasterzeilen unter der Y-Position (bzw. 42 Rasterzeilen bei Y-Vergrößerung). Die neuen Y-Positionen für die nächste Darstellung kann der Multiplexer aber bereits setzen, sobald das Zeichnen des Sprites angefangen hat, also 20 Rasterzeilen früher - und aufgrund des entspannteren Timings wird das wohl oft so gemacht.

    Bei einem Spiel mit Splitscreen und dicker horizontaler Trennlinie könnte man also wirklich erst alle acht Sprites oben darstellen, dann in der Mitte die Kollisionsregister lesen, und dann unten das Ganze wiederholen.
    Aber wenn sich die Sprites unabhängig voneinander auf dem ganzen Bildschirm bewegen können, ist es sehr schwierig, die richtigen Zeitpunkte für das Lesen der Register zu finden.

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • Nur in einfachen Fällen.

    Oha, wie immer liegt die Tücke im Detail ^^

    ────────────────────────────────────────────────────────────
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    ────────────────────────────────────────────────────────────

  • Die VIC-Entwickler hätte funktional auch ein Register zur verfügung stellen können, dass immer den aktuellen Zustand anzeigt und dafür beim Auslesen nicht gelöscht wird

    Nein, denn die CPU würde dann "meistens" die Information lesen "keine Kollision", denn der Rasterstrahl ist die meiste Zeit woanders. Die Speicherung der Information ist also durchaus sinnvoll für den sinnvollen Einsatz des Registers.

    ich schreib mir da besser eine Abstandsberechnung und ermittle meine Kollisionen so.

    ...oder Du schreibst neben dem Sprite-Multiplexer auch einen Kollisionsdaten-Multiplexer.

    Die neuen Y-Positionen für die nächste Darstellung kann der Multiplexer aber bereits setzen, sobald das Zeichnen des Sprites angefangen hat, also 20 Rasterzeilen früher - und aufgrund des entspannteren Timings wird das wohl oft so gemacht.

    Ebenso entspannt müsste es sein, die Kollisionsdaten vor dem Setzen der *nächsten* acht Y-Positionen in ein Array zu schreiben. Zugegeben, es wird komplex und hat Grenzen, aber da die Information "welche Sprites sind aktiv" im Multiplexer vorhanden ist, ist auch der Kollisions-Multiplexer in genau dem Code anzusiedeln.

    Jens

    Bitte melde dich an, um diesen Link zu sehen. - Das offizielle iComp Supportforum ist online.