SDL 2D Shooter + Gegner/Sternobjekte?

DaGeRe

Hallo!

Nein, xs und ys sind nicht die Anzeigekoordinaten, das sind die Spielerkoordinaten. Die sollen dann für Koollisionsabfragen gebraucht werden(z.Zt. bedeutungslos).

Doch, die haben ne y Koordinate, die ist nur private:

class gegner
{
      public:
             int x;
             char buffer[15];
             gegner();
             ~gegner();
             void berech(int xs, int ys);
      private:
              int y;//<----
              SDL_Surface *bild;};

Na, ich mache delete auf den gegner, speicher freigeben ist aber net nötig, weil ich ja das globale gegbild verwende(irgendwann änder ich das - aber erstmal muss es mal so laufen, und da weder Transparenzfarben noch Gegner funzen..)

leech

DaGeRe schrieb:

Na, ich mache delete auf den gegner, speicher freigeben ist aber net nötig, weil ich ja das globale gegbild verwende(irgendwann änder ich das - aber erstmal muss es mal so laufen, und da weder Transparenzfarben noch Gegner funzen..)

ähmm.. diesen speicher musst du natürlich auch freigeben... es ist egal, ob es global ist oder nicht...

P.S.: Warum ist die X-Koordinate public, aber die Y-Koordinate private?

DaGeRe

Wie, freigeben? Ich dachte, der wird am schluss mit SDL_Quit sowieso freigegeben.

Weil die x Koordinate mit xbeschg(Globale Beschleunigung in X-Richtung^^) verglichen werden muss und so. Derzeitig hat das keinen Grund - bloß für spätere abfragen von der Hauptschleife.

Angenommen, ich verändere den Gegnerkonstruktor so:

gegner::gegner()
{
                //bild=gegbild;
                x=500;
                SDL_FillRect(bildschirm, NULL, SDL_MapRGB(bildschirm->format,0,0,0));
                printf(buffer,"X: %d", x);
                anz_txt(10,10,buffer);
                SDL_Flip(bildschirm);
                SDL_Delay(1000);
                //y=rand()%bildschirm->h;
                }

dann werden so komische Vierecke angezeigt, aber nicht X: 500.

wolfgke

Nein mit SDL_Quit wird nur der von SDL allokierte Speicher (insbesondere Screen-Surface etc.) freigegeben.

Um deine eigenen Objekte musst du schön selbst kümmern.

DaGeRe

Hm...ja schon....aber ich mein, das hat doch nichts damit zu tun, weshalb es abstürzt und die Transparente Farbe nicht klappt?

Ich kann das schon noch am schluss rein machen...aber es wird wahrscheinlich den absturz nicht verhindern.

also zum thema speicher freigeben aka "reservieren" und speicher verwerfen oder löschen /sperren /kicken /eraz0rn oder was auch immer

int *b=new int; //speicher für b wird reserviert
*b=1;     //b ist jetzt 1 !
cout<<b; //computer wird hier 1 ausgeben
delete b; //speicher wird gelöscht (verweise werden verworfen)
cout<<b; //halt!stop! hier wird das programm abstürzen, denn
        //du versuchst b auszugeben, obwohl keine verweise auf b mehr vorhanden 
         //sind, das heisst, der pc weiss nicht wo er b finden kann und gibt 
         //entweder nen error aus oder es passiert etwas undefiniertes(z.b gibt
        //er eine willkürliche zahl aus)

b=new int;
b=1;
cout<<b; //ja, dass hat geklappt! neuer speicher ist angeschafft und du kannst
        //auf b zugreifen

DaGeRe

Ok. Danke erstmal, ich glaube, das habe ich jetzt verstanden.

Es ist demzufolge anzunehmen, das die Objekte falsch initiallisiert/wieder gelöscht wurden.
Ich habe weiterhin herausgefunden, das das Problem eigentlich bei den Koordinaten ist.

Das ist die Klasse:

class gegner
{
      public:
             int x;
             gegner();
             ~gegner();
             void berech(int xs, int ys);
      private:
              int y;};

gegner::gegner()
{
                x=500;
                y=rand()%bildschirm->h;
                }

void gegner::berech(int xs, int ys)
{
     anz_bmp(1,1,gegbild);
     //x=x;//xbeschg;
     }

gegner::~gegner()
{
                 //x=0;
                 //y=0;
                 }

Wenn ich beim Desturktor x=0 oder y=0 setze kommt es zum absturz. Bei dem void berech funktioniert es nur, wenn ich Zahlen eingebe, benutze ich x oder y kommt es zum Absturz.

Vor der Hauptschleife ist nun:

gegner *gegi[20];
for (i=1;i<19;i+=1)
    {
        gegi[i]=new gegner();}

zur Intiallisierung der Variablen(hier kommt es zu keinen Problemen).

Jedoch bei:

for (i=1;i<19;i+=1)
           {
               gegi[i]->berech(sp->x, sp->y);
               //if (gegi[i]->x< (-50)){
                                     delete gegi[i];
                                     gegi[i]=new gegner();
                                     //}
               }

kommt es wieder zu Problemen, wenn ich das if dingens nicht kommentiert habe.
Ach ja, am Rande: deshalb ist x global: das man das Objekt zerstören und neu erstellen kann, wenn es am Bildschirmrand verschwunden ist.

Leider verstehe ich eins noch nicht: wieso ist x/y falsch initiallisiert? Es ist doch genau so wie bei sterne int x und int y vorhanden.

David_pb

Hi!

@TravisG:
Das stimmt nich so ganz, es muss heisen:

*b = 1;

@DaGeRe:
Warum verwendest du nicht einfach Vektoren? Du würdest dir massig Arbeit sparen und (an dieser Stelle) um das erlernen des Debuggens herumkommen, da du das ja anscheinend sowiso nicht für notwendig hältst...

grüße

DaGeRe

Na, wie debugge ich denn?

Ich benutze Dev C++, falls das wichtig ist.

/EDIT: ES KLAAAAAAAPT! Ich hab mir gedacht, x und y werden nicht aktuallisiert, der Fehler ist im Konstruktor oder so(von daher hätte nen Debugger nicht soo viel geholfen) - also nehm ich in die Klasse mal einfach xg und yg als Koordinaten(für xgegner und ygegner). Und jetzt KLAPPT es. Ich weiß zwar nicht wieso es mit x und y nicht geklappt hat, aber es geht :-). Wenn mir jemand noch sagen könnte, wieso x bzw. y nicht geklappt hat, wäre ich restlos glücklich.

David_pb

DaGeRe schrieb:

der Fehler ist im Konstruktor oder so(von daher hätte nen Debugger nicht soo viel geholfen)

Wieso hilft dir da kein Debugger weiter? Ich hege die Befürchtung das du nichtmal weist was genau das ist!

grüße

DaGeRe

Richtig befürchtet...
Im ICQ hat mir jemand gesagt, damit kriege ich die Programmzeile raus, wo es abstürzt. Und so weit war ich ja schon

Ist jetzt aber auch egal...
Kann mir jemand eventuell nach sagen, wieso die Farbe 0,0,30 nicht transparent angezeigt wird?