spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Die CheckCollision funktion geht eben genau davon aus, dass SizeX und SizeY nicht die rechte untere Ecke des Sprites, sondern dessen Breite und Höhe angeben. Deshalb wird sie nur mit SizeX = m_Width korrekt funktionieren.
Spiel die Funktion doch einfach mal mit den konkreten Werten im Kopf durch.

wenn du mit SizeX und SizeY allerdings die untere rechte Ecke des Sprites definieren willst, dann ist
1. SizeX = m_Position.x + m_Width korrekt
2. die CheckCollision-Funktion falsch
3. der Variablenname schlecht gewählt

Jedenfalls solltest Du dich nicht an dem Beispiel von SaRu orientieren. Die Aussage, dass die meisten Engines es so machen, wie er es in seiner Implementierung zeigt, ist falsch. Nur die schlechten machen es so. Diese BoundingBox Klasse ist ein simples Beispiel und sollte wohl besser so nicht in Deiner Engine auftauchen. Denn Du wirst jetzt sicherlich auf die Idee kommen, Deiner Sprite Klasse eben diese BoundingBox Klasse als Attribute zu verpassen.
Besser wäre definitiv, wenn Du eine Klasse CollisionManager erstellst und die eine Liste von BoundingBoxes enthält. Dann kannst Du in einer Methode über alle BoundingBoxes iterieren und Kollisionen feststellen. Diese merkst Du dir in einer einfachen Liste. Danach kannst Du ja abfragen, ob denn Dein Sprite mit anderen kollidiert ist indem Du die vorbereitete Liste abfragst.
Das ist wesentlich effizienter (siehe Speicherzugriff etc.) als bei dem Beispiel oben von SaRu.
Immer beachten, dass es am besten ist, wenn man nötige Daten in einer zusammenhängenden Struktur im Speicher hat und dann einmal in einem Rutsch darüber iteriert.
Aber anders geht es auch. Bin halt nur ein Performance Freak.

Also erst einmal ging es mir vorwiegend darum, anzumerken, dass es keinen großen Sinn macht zwei solche Klassen zu haben. Eine für Position und Größe der BoundingBox und eine Klasse, die lediglich die Kollisionsüberprüfung implementiert. Da kann man das auch gerade zusammenfassen. Ich arbeite meist entweder mit der SFML oder bei etwas größeren Projekten mit ClanLib. Ich würde beide als recht gute Engines / Frameworks einstufen und beide verfügen über eine Rect Klasse, die eine Funktion zur Verfügung stellt mit der ein Überlappen zweier Rects überprüft werden kann.

Zum Anderen bin ich mir nicht sicher ob ein CollisionManager bei einem einfachen 2D Framework Sinn macht. Wenn ich dich richtig verstanden habe, dann würden dabei - selbst wenn mich nur die Kollision eines ganz speziellen Objekts mit einem ganz speziellen anderen interessiert - erst einmal alle Objekte auf Kollisionen überprüft, dabei würden zwei Listen entstehen, die müssten dann im Nachhinein noch durchsucht werde bis man dann das Objekt gefunden hat was einen interessiert...
Ich glaube dein Ansatz ist eher der einer Physik Engine (bin mir nicht sicher, aber ich glaube Box2D macht das so), bei der davon ausgegangen werden kann, dass wirklich alle Objekte (in Box2D Instanzen von b2Body) sich entsprechend der physikalischen Gegebenheiten verhalten sollen. Da müssten dann wirklich bei jedem Frame alle auftretenden Kollisionen erkannt und behandelt werden.


Gruß
SaRu_

Also ich weiß ja nicht, was er genau mit seiner Engine vorhat. Vielleicht will er ja mal mehr als 10 Sprites behandeln. Ich wollte ihm nur einen Weg aufzeigen, wie er das direkt wesentlich effektiver machen kann und nicht später einiges umstellen muss.
Natürlich kannst Du das so machen. Nimm Deine BoundingBox Klasse und häng das als Attribut in die Sprite Klasse. Dann hast Du einen nettes OO-Schema und alles ist gut.
Es sei denn, Du möchtest das eventuell performant abarbeiten. Hierzu ist es halt nun mal extrem wichtig, dass meine Daten effektiv im Speicher ablegt. Effektiv heißt, dass man die Daten so ablegt, so das man in einem großen Rutsch idealerweise die Daten abarbeiten kann. Dadurch minimiert sich der Cache Miss extremst. In heutigen Computer stellt nämlich das einen größeren Engpass da, als viele denken.