spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Hallo liebe Forumbesucher,

Erstmal möchte ich mich entschuldigen, dass ich ein Thema anspreche, zu dem es bereits Forenbeiträge gibt. Allerdings taucht dieses konkrete Problem meist erst auf der 2. Seite irgendwo versteckt auf und wurde nicht gelöst, weshalb ich diesen Beitrag noch einmal getrennt eröffnen möchte.
Als ich versucht habe die Kollision von Spieler und Asteroiden einzubauen bin ich in eine kleine Falle gelaufen. Ich habe die Breite des Raumschiffs versucht aus dem zugehörigen Sprite auszulesen, habe dabei aber die Breite des ganzen Bildes (alle Teile der Animation in einer langen Reihe) ausgelesen. Das erhält man mittels m_pSpritePlayer->GetRect().w, für den richtigen Wert muss man sich erst eine eigene Funktion bauen, die die Breite des Rects m_FrameRect ausliest, ich habe die Breite des Raumschiffs einfach konstant auf 64 gesetzt, nicht schön, aber funktioniert.

So weit alles schön und gut. Die große Frage, die sich mir dann aber gestellt hat war "Wie wurde das eigentlich bei den Asteroiden gemacht?", denn da sollte ja das gleiche Problem auftreten. Bei den Asteroiden passiert aber etwas ganz witziges. Die Breitenzuordnung sieht folgendermaßen aus:

GetRect wiederum ist eine einfache Funktion des Sprites

und in der Variable m_Rect sollten eigentlich die Maße des gesamten Bildes geladen werden, also in diesem Fall sollte die Breite des Kometen auf 640 (Gesamtbreite der 10 Bilder hintereinander) und nicht 64 (Breite eines Ausschnitts des Kometenbildes) gesetzt werden.
Lustigerweise passiert das auch, aber nur beim allerersten Kometen.
Das haben sowohl Debugger als auch eine kleine Testausgabe bestätigt:


Wenn man diese kleine Zeile einfügt hat man nach Beenden des Spiels in der Konsole etwas in der Art:
640640640640640640640640640640640640640640640640640640640646406464064640646406464064....
stehen. Das ist jetzt nicht sehr hübsch, aber wer genau hinschaut sieht, dass der erste Komet Breite 640 hat und der 2. (und wenn man es etwas weiter laufen lässt sieht man, dass das auch für alle weiteren gilt) hat Breite 64.
Das lässt sich auch nochmal etwas besser mit dem Debugger überprüfen.

Die große Frage ist jetzt: Wie kommt das Zustande?
1. Was unterscheidet den 1. Kometen von allen weiteren
2. Wo kommt die 64 der späteren Kometen her? Nach meiner Ansicht müsste diese Breite immer bei 640 liegen.

Ich weiß, dass diese Frage nicht zu beantworten ist ohne den kompletten Code des Spiels in Kapitel 12 zu kennen. Da ich aber wirklich keine Ahnung habe wo der Fehler liegt, kann ich auch nicht wirklich mehr Code posten um das Problem deutlicher zu erklären. Unter http://downloads.hanser.de/getDoc.asp?doc_id=21351514131-27 kann man alle Codebeispiele runterladen und im Ordner Quellcode/Visual Studio/Kapitel 12/SDL_Game findet man den Code des gesamten Projekts. Allerdings hoffe ich im Moment eher darauf, dass mir jemand die Frage beantworten kann, der sich bereits diesem Code beschäftigt hat. Sonst ist der Aufwand wahrscheinlich zu groß.

Ich habe mir schon eine ganze Weile den Kopf darüber zerbrochen, aber da dies offenbar ein bug ist, der auch in der 4. Auflage des Buches noch vorhanden ist (oder einfach ignoriert wurde?) ist das Problem vielleicht auch eher subtil. Ich hoffe einfach, dass sich hier ein paar sehr kluge Leute herumtreiben, die mir helfen können

Und nochmal um das klar zu machen: Dieses Problem entsteht wenn man den heruntergeladenen Originalcode aus dem Buch ungeändert (abgesehen von der Überprüfungsausgabe) laufen lässt, es ist also kein Fehler, den ich persönlich gemacht habe. Man sieht auch ein Symptom dieses Fehlers, wenn man mal versucht den ersten Kometen abzuschießen. Das klappt nämlich auch, wenn man ein gutes Stück weit weg ist.

Viele liebe Grüße
Anna

Vielen Dank für den guten und schnellen Hinweis dr. hallo!

Es stimmt tatsächlich, dass sich in dem Schritt

Die Breite von m_Rect von 640 auf 64 ändert.

Dann werde ich demnächst mal versuchen anhand der SDL Dokumentation zu entschlüsseln, was da passiert (wenn das jemand schon weiß und mir Arbeit ersparen will, freue ich mich natürlich ).
Akut werde ich aber denke ich erstmal eine Funktion einbauen, die FrameRect zurückgibt (brauche ich ja eh für mein Raumschiff) und das Ganze reparieren, denn es tut ja trotz Zauberei nicht genau das, was wir gern hätten.

edit: Das Nachlesen war einfacher als ich dachte. Ich schreibe meine Erkenntnisse mal hier rein, falls es wen interessiert.

http://wiki.libsdl.org/SDL_BlitSurface
Dort wird genau beschrieben was passiert. Das letzte Rectangle in der Übergabe soll das Rechteck auf dem Ziel-surface beschreiben, in das gemalt wird. Das wird jetzt etwas zu groß angegeben (sollte ja eigentlich nur 64 breit sein weil unser Bild auch so groß ist), das macht uns aber nichts, weil die Funktion eh nur x und y ausliest und somit läuft das Malen problemlos.
Spannend ist dagegen diese Zeile in der Erklärung:
"The final blit rectangle is saved in dstrect after all clipping is performed"
Also im Wesentlichen speichert er das Rechteck, in das tatsächlich gemalt wurde, in dstrect, was unserem m_Rect entspricht. Somit ist nach dem Aufruf die Breite von m_Rect natürlich wie gewollt.

Ich hoffe das habe ich jetzt richtig verstanden und erklärt. Falls ihr meine Erklärung nicht versteht, einfach den Link anklicken, da steht alles .

Sollte man das Problem irgendwo als Fehler im Buch melden? Wenn ja wo?

Das stimmt, gerade weil der Wert ja ohnehin bald überschrieben wird.
Dann beschreibt das Rechteck auch konsequent die Fläche, in die wir das Bild malen wollen. Das ist also nicht nur ein Trick sondern wirklich logisch. Gefällt mir, danke .
Jetzt habe ich fast das Bedürfnis das Ding m_TargetRect und das Rect andere m_SoureRect oder so zu nennen und die nicht-animierte Version entsprechend anzupassen...