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!

Vererbung von Klassen

  • 1
  • 2

Werbeanzeige

physX

Treue Seele

  • »physX« ist der Autor dieses Themas

Beiträge: 119

Wohnort: Dresden

  • Private Nachricht senden

11

08.07.2009, 09:54

Zitat von »"Nexus"«

@ physX: Du kannst deine eigene Klasse auch ihre Position speichern lassen. Wenn dir das momentan zu mühsam vorkommt, kannst du es auch vorerst lassen, aber behalt die Möglichkeit doch im Hinterkopf. ;)


Das mach ich. Ich möchte jetzt erstmal das aktuelle Projekt sorgfältig abschliessen. Danach werd ich mich dann deinem Ansatz näher widmen. Dein Ansatz gefaellt mir sehr gut und ich werde es auch im folgenden Projekt umsetzen. Mir fehlt es momentan noch etwas an Programmiererfahrung, die ich mir erstmal mit solchen kleineren Ansätzen aneignen will. Momentan würde mich die neue Umsetzung wieder viel Zeit kosten, die für das aktuelle Projekt sicher nicht angemessen wäre.
Mit meiner momentanen Umsetzung und kleinen Änderungen kann ich ja immer noch Logik von Grafik trennen, mit dem momentanen Manko der sf::Sprite-Klasse. Das müsste sich aber dann auch nachträglich noch ohne grossen Einfluss auf die Childs durch eine eigene Sprite-Klasse ändern lassen. Da muss ich mir aber erstmal die Source zur sf::Sprite anschauen und verstehen ;) . Eventuell reicht es ja auch einfach die Sachen, die ich nicht benötige in meiner Spriteklasse einfach rauszuwerfen. ok, vielleicht ändere ich das ja doch noch demnaechst schon... ^^
Danke nochmal für deine Hilfe.
Gruss

K-Bal

Alter Hase

Beiträge: 703

Wohnort: Aachen

Beruf: Student (Elektrotechnik, Technische Informatik)

  • Private Nachricht senden

12

08.07.2009, 10:26

Okay es ist sicher ne Philosophie-Frage. Ich finde es jedenfalls praktisch ein Sprite pro Objekt zu haben. Alles andere würde ich erstmal als Premature Optimization auf Seite legen. ;)
www.myspace.com/readytorock
www.facebook.com/PENCILCASE.MUSIC

Nexus

Alter Hase

Beiträge: 713

  • Private Nachricht senden

13

08.07.2009, 14:18

Zitat von »"physX"«

Mit meiner momentanen Umsetzung und kleinen Änderungen kann ich ja immer noch Logik von Grafik trennen, mit dem momentanen Manko der sf::Sprite-Klasse. Das müsste sich aber dann auch nachträglich noch ohne grossen Einfluss auf die Childs durch eine eigene Sprite-Klasse ändern lassen. Da muss ich mir aber erstmal die Source zur sf::Sprite anschauen und verstehen ;) . Eventuell reicht es ja auch einfach die Sachen, die ich nicht benötige in meiner Spriteklasse einfach rauszuwerfen. ok, vielleicht ändere ich das ja doch noch demnaechst schon... ^^
Das verstehe ich jetzt nicht. Wieso eine eigene Spriteklasse? Dafür gibt es sf::Sprite, die ist mit grösster Wahrscheinlichkeit sowieso besser implementiert. Ausserdem hast du dann wieder die erwähnte Abhängigkeit.

Zitat von »"K-Bal"«

Okay es ist sicher ne Philosophie-Frage. Ich finde es jedenfalls praktisch ein Sprite pro Objekt zu haben. Alles andere würde ich erstmal als Premature Optimization auf Seite legen. ;)
Wirkliche Argumente von deiner Seite habe ich bisher leider nicht viele gehört. Es ist natürlich einfacher, etwas als Premature Optimization herabzutun (selbst wenn Optimierung nicht die primäre Absicht dahinter ist). ;)

physX

Treue Seele

  • »physX« ist der Autor dieses Themas

Beiträge: 119

Wohnort: Dresden

  • Private Nachricht senden

14

08.07.2009, 14:56

Zitat


Das verstehe ich jetzt nicht. Wieso eine eigene Spriteklasse? Dafür gibt es sf::Sprite, die ist mit grösster Wahrscheinlichkeit sowieso besser implementiert. Ausserdem hast du dann wieder die erwähnte Abhängigkeit.


Ja, da hab ich dich wohl falsch verstanden, ich dachte es ging dir zusätzlich auch darum, dass die Spriteklasse zu umfangreich ist, aber das war wohl nur in Bezug auf Spiellogikelemente bei meiner Klassenstruktur gemeint und nicht in Bezug auf die Spriteklasse selbst.
Gruss

Nexus

Alter Hase

Beiträge: 713

  • Private Nachricht senden

15

08.07.2009, 15:06

Es ist schon gut, dass die Spriteklasse so umfangreich ist, ab und zu braucht man ja deren Möglichkeiten. Wie du sagst, bezog ich mich eher auf die Spiellogik-Objekte, die die Sprite-Funktionalität nicht direkt brauchen.

K-Bal

Alter Hase

Beiträge: 703

Wohnort: Aachen

Beruf: Student (Elektrotechnik, Technische Informatik)

  • Private Nachricht senden

16

08.07.2009, 15:07

Zitat von »"Nexus"«


Wirkliche Argumente von deiner Seite habe ich bisher leider nicht viele gehört.


Das lieg daran, dass ich mir gerade das Neo-Layout beibringe und deswegen noch ewig zum tippen brauche ;)

Ein

C-/C++-Quelltext

 
1

App.draw(enemy);


oder

C-/C++-Quelltext

 
1

App.draw(enemy.getSprite());


finde ich übersichtlicher als ein

C-/C++-Quelltext

 
1
2
3
4
5

myEnemySprite.SetPosition(enemy.getPosition());
myEnemySprite.SetRotation(enemy.getRotation());
myEnemySprite.SetScale(enemy.getScale());

App.draw(myEnemySprite);


Wenn dann auch noch animierte Sprites ins Spiel kommen....

Gruß,
Marius
www.myspace.com/readytorock
www.facebook.com/PENCILCASE.MUSIC

Nexus

Alter Hase

Beiträge: 713

  • Private Nachricht senden

17

08.07.2009, 15:11

Das machst du einmal in einer Funktion und dann hast du es. Für mich lohnen sich die paar Zeilen mehr, wenn ich dafür die einzelnen Klassen auf das Notwendige beschränken kann und jede Klasse ihre genaue Aufgabe hat.

P.S.: Bei animierten Sprites hast du mit deiner Variante genauso zusätzlichen Schreibaufwand.

K-Bal

Alter Hase

Beiträge: 703

Wohnort: Aachen

Beruf: Student (Elektrotechnik, Technische Informatik)

  • Private Nachricht senden

18

08.07.2009, 15:27

Wie gesagt, es ist eine Philosophiefrage, für welches man sich entscheidet. Fakt ist man kommt auf beiden Wegen zum Ziel.

Mich würde einmal die Implementierung deiner Idee interessieren. Also wie du Logik und Grafik modularisierst.
www.myspace.com/readytorock
www.facebook.com/PENCILCASE.MUSIC

Nexus

Alter Hase

Beiträge: 713

  • Private Nachricht senden

19

08.07.2009, 17:55

Zitat von »"K-Bal"«

Wie gesagt, es ist eine Philosophiefrage, für welches man sich entscheidet. Fakt ist man kommt auf beiden Wegen zum Ziel.
Ja, klar. Ich hab ja nicht behauptet, mein Weg sei der einzig wahre. Ich habe früher auch von Sprites abgeleitet, inzwischen aber bessere Erfahrungen mit einer strikteren Trennung gemacht (was nichts heissen muss, ist einfach meine persönliche Erfahrung). Man sollte auch offen sein für Neuerungen. ;)

Zitat von »"K-Bal"«

Mich würde einmal die Implementierung deiner Idee interessieren. Also wie du Logik und Grafik modularisierst.
Hm, das habe ich doch oben (v.a. im ersten Post) beschrieben, oder ist das zu wenig konkret?

Werbeanzeige

  • 1
  • 2