Wann wird das Sprite-Sprite-Kollisions-Register gesetzt

  • Wann wird das Sprite-Sprite-Kollisions-Register gesetzt

    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)?
    CIA and Co have reached the C64 - see the proof in the Hack Attack Trailer
  • 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.
    CIA and Co have reached the C64 - see the proof in the Hack Attack Trailer
  • mc71 schrieb:

    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.
    CIA and Co have reached the C64 - see the proof in the Hack Attack Trailer
  • 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.
  • Zaadii schrieb:

    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?
    ────────────────────────────────────────────────────────────
    Time of Silence - Time of Silence 2 Development Blog
    ────────────────────────────────────────────────────────────
  • Claus schrieb:

    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 ACME cross assembler
  • Mac Bacon schrieb:

    Nur in einfachen Fällen.
    Oha, wie immer liegt die Tücke im Detail ^^
    ────────────────────────────────────────────────────────────
    Time of Silence - Time of Silence 2 Development Blog
    ────────────────────────────────────────────────────────────
  • Zaadii schrieb:

    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.

    Zaadii schrieb:

    ich schreib mir da besser eine Abstandsberechnung und ermittle meine Kollisionen so.
    ...oder Du schreibst neben dem Sprite-Multiplexer auch einen Kollisionsdaten-Multiplexer.

    Mac Bacon schrieb:

    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
    icomp.de/shop-icomp - Online einkaufen und offline bei Rewe, Penny, DM und Weiteren im Laden bezahlen.