Hallo Besucher, der Thread wurde 1,3k mal aufgerufen und enthält 2 Antworten

letzter Beitrag von sauhund am

sprite-kollisionen

  • Hallo erstmal, bin neu hier und hab gleich eine komplizierte Frage. Es geht um Sprite Kollisionen. Ich will einen Screen mit Hindernissen für mein Sprite, d. h. das es z.B. Mauern gibt, die das Sprite natürlich nicht überwinden soll. Die Kollisionsregister sind natürlich Schrott, denn dann ist es ja schon passiert und damit zu spät. Mir ist in Basic eine elegantere Möglichkeit eingefallen, nämlich eine zusätzliche Variable Z einzuführen, die , wenn das sprite z.B. bei x 24 und y 50 steht, 1024 enthält. Bewege ich das Sprite nun um 8 Schritte nach rechts, enthält x=32 und Z wird um 1 erhöht, also 1025. Die Variable Z wird also alle 8 Sprite-Schritte um eins erhöht und ermöglicht damit eine Verbindung von Sprite-Position zur Bildschirmposition. Man kann also einfach Abfragen: If Peek (z+1)<>32then zurück zur Abfrage.32 ist Space, also Leeraum. Hallo, liest das überhaupt noch jemand? FRAGE: Wie kann ich das in Maschinensprache machen. Die indirekte-Y-Indizierung scheint mir da angebracht, aber hat vielleciht einer ein Beispiel? Ausserdem sollte das ganze natürlich im Interrupt hängen. Mein Problem dabei ist, die ganzen Überläufe und Unterläufe zu handeln, denn nach 255 ist in MS natürlich Schluss. Natürlich könnte ich mir jetzt auch selbst das Hirn zermartern, aber vielleicht hat ja der eine oder andere schon so eine Routine parat!?!?

  • Hi,
    die Rechenroutinen könnten so aussehen (wenn Z in den Speicherstellen $02 und $03 gespeichert ist):



    Die Abfrage kann dann, wie geplant, mit der indirekten Y Indizierung geschehen:
    ldy #$00
    lda ($02),y
    cmp #32
    bne ...


    Einfacher wäre es aber wenn du per Interrupt wartest bis der Rasterstrahl den unteren Border erreicht hat, dann die Bewegung erstmal probehalber ausführst, die Kollisionsregister prüfst und die Bewegung dann gegebenenfalls wieder rückgängig machst.

  • ääääh


    ja ne, also die kollisionsregister sind kompletter müll. streich die aus deinem gedächtnis, für immer! :) die taugen ja nur für gaaaaaaanz simple sachen, und schon eine nette hintergrundgrafik machen die komplett unbrauchbar.


    in der regel macht man das so das man die sprite koordinate(n) durch 8 teilt (3 mal LSR) und dann mit hilfe von tabelle(n) die bildschirmadresse ausrechnet... irgendwie so:


    lda $d001
    lsr
    lsr
    lsr
    tax
    lda zeilehi,x
    sta $03
    lda zeilelo,x
    sta $02


    lda $d000
    lsr
    lsr
    lsr
    tay
    lda ($02),y


    natürlich muss man noch kompensieren das ja sprite-koordinate 0/0 nicht auch der screenkoordinate 0/0 entspricht, aber das prinzip sollte klar sein....


    auf die art kriegst du das zeichen das mit der linken oberen ecke des sprites kollidiert. anhand dessen kannst du dann ganz easy ja alle andren (zwei runter, zwei nach rechts usw) abfragen.


    mmja, das ganze ist natürlich ungenau...ABER es reicht für die allermeissten anwendungen vollkommen aus. ich würde mal vermuten das es nur ganz wenige games auf dem c64 gibt die es genauer machen, wenn überhaupt :)


    wenn es wirklich so sein muss, dann ermittelst du erst wie oben die screenadressen, und danach anhand von bitmasken alles weitere....das ist allerdings nicht ganz trivial, langsam, und wie gesagt in den meissten fällen unnötig :)