Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Krieg der Klötze [ erstes grafisches Testspiel ]

Werbeanzeige

patrick246

Treue Seele

Beiträge: 328

Wohnort: nahe Heilbronn/BW

Beruf: TG Profil Informatik-Schüler

  • Private Nachricht senden

11

24.07.2013, 01:55

Wenn du später mal etwas auf eine Textur rendern willst, dann ist diese Lösung nicht so toll. Wenn du stattdessen deine Spielerklasse von sf::Drawable erben lässt und die abstrakte Methode draw(sf::RenderTarget&, sf::RenderStates) implementierst, dann kannst du einfach window.draw(player); schreiben und der Spieler wird gezeichnet.

NachoMan

Community-Fossil

Beiträge: 3 885

Wohnort: Berlin

Beruf: (Nachhilfe)Lehrer (Mathematik, C++, Java, C#)

  • Private Nachricht senden

12

24.07.2013, 05:10

Wie soll er die Implementieren? Dafür muss er von Drawable erben und das ist keine gute Idee. Schreib deine funktion einfach in draw(sf::RenderTarget &target) um und verwende target wie window.
"Der erste Trunk aus dem Becher der Erkenntnis macht einem zum Atheist, doch auf dem Grund des Bechers wartet Gott." - Werner Heisenberg
Biete Privatunterricht in Berlin und Online.
Kommt jemand mit Nach oMan?

Maxomann

Frischling

Beiträge: 8

  • Private Nachricht senden

13

24.07.2013, 05:38

Zitat von »NachoMan«

Wie soll er die Implementieren? Dafür muss er von Drawable erben und das ist keine gute Idee. Schreib deine funktion einfach in draw(sf::RenderTarget &target) um und verwende target wie window.

Von drawable zu erben is sehrwohl eine gute Idee.

Siehe hier ungefähr in der Mitte.

NachoMan

Community-Fossil

Beiträge: 3 885

Wohnort: Berlin

Beruf: (Nachhilfe)Lehrer (Mathematik, C++, Java, C#)

  • Private Nachricht senden

14

24.07.2013, 06:01

Der Spieler ist nicht Drawable, er enthält nur etwas, was Drawable ist.
In diesem Fall ist die Vererbung aber absolut nicht notwendig und vereinfacht das Vorhaben in keinster Weise und da man Vererbung sowieso vermeiden sollte...
Meine Empfehlung an dich: http://openbook.galileocomputing.de/oop/ ;)
"Der erste Trunk aus dem Becher der Erkenntnis macht einem zum Atheist, doch auf dem Grund des Bechers wartet Gott." - Werner Heisenberg
Biete Privatunterricht in Berlin und Online.
Kommt jemand mit Nach oMan?

David Scherfgen

Administrator

Beiträge: 10 382

Wohnort: Hildesheim

Beruf: Wissenschaftlicher Mitarbeiter

  • Private Nachricht senden

15

24.07.2013, 07:33

Zitat von »NachoMan«

und da man Vererbung sowieso vermeiden sollte...

Das solltest du vielleicht ein wenig erläutern.
Warum sollte man Vererbung generell vermeiden?
Sie ist doch eines der Schlüsselkonzepte objektorientierter Programmierung.
David Scherfgens Website | Konzentrationstest Polizei

bwbg

Treue Seele

Beiträge: 107

  • Private Nachricht senden

16

24.07.2013, 07:47

In dem Fall ist m. M. beides zulässig. Sowohl die Frage, ob "Spieler" zeichenbar ist (is a sf:: Drawable) oder etwas zeichenbares hat (has a sf:: Drawable) lässt sich in diesem Minimalbeispiel mit "ja" beantworten.

Wobei sich das Mantra "prefer composition over inheritance" in den letzten Jahren durchgesetzt haben soll.

Grüße ... bwbg

Edit: Smileys sollten einen eigenen tag bekommen.

Zitat

Ich bin nicht der Messias.
Ich sage, du bist es, Herr. Und ich muss es wissen, denn ich bin schon einigen gefolgt.

https://bitbucket.org/bwbg

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

17

24.07.2013, 08:26

Er kann dennoch sowohl etwas zeichenbares haben (Komposition) als auch das Interface drawable implementieren. Ich sehe da absolut keinen Widerspruch, ganz im Gegenteil.
Das ist mit Sicherheit sogar besser als:
1) Eine draw-Methode anzubieten, ohne selbst ein Drawable zu sein - denn wenn es gezeichnet werden kann über eine Methode, ist es doch wohl eindeutig drawable.
oder
2) Eine Get-Methode für die Drawable-Komponenten nach außen anzubieten, damit diese gezeichnet werden können, denn das würde Implementierungsdetails nach außen offenlegen, was völlig unnötig ist.

Edit: Wenn du [ic]...[/ic] verwendet hättest für sf::D wäre das mit den Smilies nicht passiert ;)
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

NachoMan

Community-Fossil

Beiträge: 3 885

Wohnort: Berlin

Beruf: (Nachhilfe)Lehrer (Mathematik, C++, Java, C#)

  • Private Nachricht senden

18

24.07.2013, 09:52

Das kann ja schon sein, allerdings sehe ich keinen praktischen Vorteil darin in dem Fall zu erben. Man muss nur mehr in der Klasse ändern, wenn die SFML sich ändert oder man die Bibliothek wechselt.
"Der erste Trunk aus dem Becher der Erkenntnis macht einem zum Atheist, doch auf dem Grund des Bechers wartet Gott." - Werner Heisenberg
Biete Privatunterricht in Berlin und Online.
Kommt jemand mit Nach oMan?

BK Simon

Treue Seele

  • »BK Simon« ist der Autor dieses Themas

Beiträge: 151

Beruf: Student

  • Private Nachricht senden

19

24.07.2013, 09:56

Dann werde ich das mit dem Erben von Drawable mal ausprobieren hoert sich fuer mich eigentlich ganz praktisch an.

Ich habe gestern Abend nun noch weiter am Quellcode gearbeitet und bin nun soweit, dass ich jetzt die Spieler und Schuss Klasse fertig habe.
Schaut jetzt so aus, dass ich in der Spieler Klasse eine Liste von der Schuss Klasse erzeuge und diese dann immer fuelle, wenn ich die Render Funktion von Spieler aufrufe.

Als naechstes muss ich dann noch eine Ziel bzw. Gegner Klasse machen und dann noch eine Game Klasse, in der ich dann pruefe, ob eine Kollision stattfand.

In meiner Spielerklasse habe ich etwas gemacht, was fuer mich sehr merkwuerdig ausschaut und ich denke nicht, dass dies der richtige Weg sein wird.
Die Wurde_Geschossen () Funktion sieht in etwa so aus:

C-/C++-Quelltext

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

if ( sf::Keyboard::isKeyPressed ( sf::Keyboard::Space ) && Schussaktiv == false)
        {
            Schussaktiv = true;

            Schuss_Temp = new sf::RectangleShape ( sf::Vector2f ( 4, 15 ) );

            Schuss_Temp->setPosition( Spieler.getPosition ().x + 25, 550 ); 
            Schuss_Temp->setFillColor ( sf::Color::Red );

            Schussliste.push_back ( Schuss_Temp );
        }
        if ( event.type == sf::Event::KeyReleased )
        {
            if ( event.key.code == sf::Keyboard::Space )
            {
                Schussaktiv = false;
            }
        }


Jetzt brauche ich dort ja "event" und ich habe es nun so gemacht, dass ich einfach per Referenz das "event" aus der Main Methode beim Konstruktoraufruf uebergebe und in einer meiner private Variablen von der Klasse Spieler speichere. Ich kann mir aber nicht vorstellen, dass dies die feine englische Art ist und wuerde gerne wissen, wie man dies anders machen koennte.


Gruss
Simon

poorsider

Treue Seele

Beiträge: 109

  • Private Nachricht senden

20

24.07.2013, 12:08

Also ich übergebe eigentlich das RenderWindow IMMER im Konstruktor als Referenz, da man das RenderWindow ja nicht nur zum Zeichnen braucht, sondern z.B auch für die Mausposition im Fenster.

Werbeanzeige

Ähnliche Themen