Forum64

Hi Turrican...

ich würde das Kollisionsregister als erstes auslesen, und in eine separate Speicheradresse kopieren, und alle weiteren Zugriffe im aktuellen Frame auf die Kopie legen. Nach dem erstellen der Kopie (war glaube besser), sollte das Register gelöscht werden. Beim nächsten Framedurchlauf sollte die Kopie mit einem neuem Wert aus den Kollisionsregistern gefüttert werden. Das gilt für beide Register.

Bei den Sprite-Sprite Kollisionsregister hast du aber eventuell ein Problem. Es sagt dir zwar, das ein Sprite mit einem anderen kollidiert, aber es sagt dir nicht mit welchem. Bei zwei Sprites mag das noch gehen, aber bei drei geht das nicht. Fast jedes bessere Spiel macht das ganze über einen Vergleich der Sprite-Koordinaten.

tecMO: Bist du der Plush tecMO? Warst du nicht mal auf einer der Plushpartys von MeisterV.O. & Ironman?

Ich hab mir das Register mal genauer angeschaut:

Erstmal hab ich eine Website Konsultiert, die den VIC recht genau beschreibt: (http://www.minet.uni-jena.de/~andreasg/c64/c64_vic_html.htm).

Dort steht:

- $d01e Sprite-Sprite-Collision
if sprites collided, here you see which sprites that were;
the corresponding bits gets high(1);
after reading you have to clear the bits because they don't clear themself;

- $d01f Sprite-Background-Collision
if sprites collide with a backgroundsign the corresponding bits get high;
also like in $d01e you've to clear bit's after reading the;


Nun hab ich ein kleines Testprogramm geschrieben.
Das ergebnis ist, das nach dem auslesen des Registers, es schon gelöscht wird. Warum man es selbst nochmal tun soll, weiß ich nicht. Mein Testprogram nutzte 3 Sprites, und die Testumgebung war der Vice Emulator. In der Schnelle hab ich es nicht auf einem echten 64'er getestet. Gab es vielleicht mal einen VIC II der etwas anders bei den Kollisionsregistern reagierte, oder warum sollte man diesen selbst löschen? Insofern stimme ich Dr. Creep zu.

>Es können nie 3 Sprites geichzeitig kollidieren,
>zuerst treffen immer 2 aufeinander, da ein Programm
>sequenziell abgearbeitet wird.
>Man muß natürlich auf's Timing bei der Abfrage achten
>(i.d.R. wird man das per Interrupt steuern).
Der Theorie nach stimmt es, bringt aber einige Probleme mit sich. Es hängt auch etwas von der Codestruktur ab.

1. Bewege ich einen Sprite, und schaue gleich ob er kollidiert, dann mag das gehen.
2. Bewege ich erst alle Sprites, und prüfe danach alle Kollisionen, wirds nicht mehr klappen. Welcher Sprite nun mit welchem? *beiß in Tastatur* Das Programm wird auch sequenziell abgearbeitet, aber es klappt nicht.

Auch erste Methode kann hinterlistig sein.
Gehen wir mal davon aus, wir haben ein Hauptprogramm das sequenziell abgearbeitet wird. Unser Programm befindet sich gerade auf der Rasterzeile #$70. Dort bewegt es Sprite 1 auf Y Position #$c0. Es prüft, ob eine Kollision mit Sprite 2 stattgefunden hat, welches auch bei #$c0 liegt. Das Programm ist jetzt vielleicht in Rasterzeile #$72, durch den Rechenzeitverbrauch, angelangt. Falls man nun prüft, ob eine Kollision stattgefunden hat, bekommt man ein "NEIN" zurück und man verschiebt Sprite 1. Doch warum ist das so? Der VIC setzt die Bits des Kollisionsregisters immer erst dann, wenn er dieses Sprite gerade zeichnet. Das geschieht also erst ab Rasterzeile #$c0. Erst jetzt wird die Kollision ins Register geschrieben. Beim nächsten Framedurchlauf würden wir dann den Wert erhalten, aber zu spät, da wir die Sprites schon ineinander verschoben haben. Wenn man das ganze nun noch mit Sprite 2 & 3 macht, ist der wahnsinn völlig komplett. So passiert es auch bei sequenzieller Abarbeitung, das 3 Sprites gleichzeitig kollidieren können, ohne das das Hauptprogramm es über die Kollisionsregister gleich mitbekommt.

Richtig kompliziert wirds dann, wenn man Spritemultiplexer nutzt. Ich fürchte, das alles was man versucht komplizierter wird, als durch den Vergleich von Koordinaten. Es ist auch besser eine Kollision vorher zu wissen (vor der Speicherung in die eigentlich X & Y Koordinate) und danach die Bewegung des Sprites zu koordinieren. Sicher hängt es auch stark davon ab, was man machen möchte.

Im Grunde wollte ich nur damit sagen, das du nach einer Verschiebung den Kollisionswert nicht sofort bekommst, sondern verzögert. Die Verzögerung ist um so größer, je weiter die Rasterzeilen-Position des Kollisionscodes von der Rasterzeilen-Position des Sprites entfernt ist. Das ist eben das Hauptproblem, welches man beim Vergleich mit Koordinaten nicht hat.

Wenn ich Unrecht habe, lass ich mich gerne belehren. Man lernt nie aus!

Gruss,
BGU / PTV

Hi DR.Creep

Das Problem ist mit dem merken des letzten bewegten Sprites auch nicht getan, fürchte ich. Es bringt immer noch extrem viele Probleme mit sich. Du schließt bei deiner Methode generell immer eine Kollision der anderen Sprites aus. Was ist aber, wenn diese Bonussymbole sind, die sich überlappen dürfen?

Ausserdem hast du immer noch das Problem, das du auf das Ergebniss der Kollision warten musst, da diese erst gesetzt wird, wenn der Sprite gezeichnet wird.

Deine Methode würde funktionieren, wenn man immer nur einen Sprite pro Frame bewegt. Es funktioniert aber nicht bei mehreren im selben Frame. Angenommen du merkst dir den zu bewegenen Sprite, bewegst ihn dann und er überlappt einen anderen Sprite. Du reagierst im Maincode aber nicht auf die Kollision, sondern über den VIC SPR-Collinterrupt. Dieser Korrigiert aber den Sprite noch nicht, da der Rasterstrahl den zu zeichnenden Sprite noch nicht erreicht hat! Dein Maincode macht also einfach weiter, und merkt sich erneut den letzten bewegten Sprite, und somit ist die wichtige Information von der letzten Kollision verloren.

Falls du die Struktur anders meintest, würde ich gerne wissen wie. Ich hab keine Methodik gefunden bei der es akkurat klappt.

Nichts für Ungut.

Am meisten würde mich ein Demo interessieren, bei dem alle 8 Sprites unkontrolliert umherfliegen, und bei Berührung sich voneinander abstossen, ohne das sie sich verkeilen. Das halte ich für relativ unmöglich. Ich wüßte nicht, wie man das ordentlich ohne Koordinaten Kollision machen sollte, da man bei solchen Anforderungen immer EINEN Kollisionszustand aller Sprites pro Frame aufbaut, mit dem man dann das Abprallverhalten der Sprites steuert.

Auch scheint mir es unmöglich, das bei der Kollision enstehende Wackeln der Sprites zu beseitigen, da sie bei einer Kollision schon dargestellt und dann zurückgeschoben werden.

Quoted

Aber ab jetzt greift die programmierte Interrupt-Service-Routine und man kann auf die Kollision reagieren ohne das irgendein weiteres Sprite auch nur um einen Bildpunkt weiter bewegt wird

Wieso, der Code der alle Sprites verschiebt, ist doch schon lange durch, und hat in dem Frame alle Sprites verrückt. Der Kollisions IRQ kommt erst viel zu spät.

Angenommen der Maincode verschiebt ALLE Sprites im Rasterbereich von $10 bis $20. Die erste Spritecollision entsteht aber erst bei $100. Viel zu spät um zu reagieren, denn es könnten zig Sprites übereinander liegen. Da nütz es auch nicht, wenn der IRQ den Maincode unterbricht, der vielleicht gerade bei einem möglichen Scroller sein könnte.

Irgendwie hadere ich da an deinem Konzept, oder ich verstehe ein wichtiges Detail nicht ganz.

Quoted

was verstehst Du unter unkontrollierter Bewegung?

Unkontrolliert war das falsche Wort. Unkontrollierte Bewegungen gibt es immer dann, wenn sich irgendwo ein Bug eingeschlichen hat Ich hätte eher das wort "wild" nehmen sollen. Das passt besser.

Quoted

so ist man sicher, dass jedes Sprite pro Bildaufbau maximal um 1 Pixel bewegt wird.

Ist das nicht eine zu grosse Einschränkung? Was ist, wenn Sprites (BSP: in Shootern) sich auf Sinuskurven bewegen, die ja nicht immer Pixelweise sind.

Quoted

Ok, wenn man von so schnellen Spritebewegungen ausgeht

Oh, ich glaube du hast mich missverstanden. Das Hauptprogramm läuft im "Idealfall" auch synchron zum Bildschirmaufbau. Daher kann es sein, das eine Spritemovement Routine relativ Konstant bei Rasterstrahlposition $10 bis $20 ausgeführt wird, die alle Sprites, je nach ihrer Geschwindigkeit verschiebt. Durch den Rechenzeitverbrauch, wird die ROutine erst in nachfolgenden Rasterzeilen beendet. Die Verschiebung aller Sprites, könnte so ab Rasterzeile $20 beendet sein, ohne das bisher Kollisionen aufgetreten waren.