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!

Werbeanzeige

Dreat

Frischling

  • »Dreat« ist der Autor dieses Themas

Beiträge: 86

Wohnort: Heilbronn

  • Private Nachricht senden

1

05.06.2013, 20:47

Multithreading oder nicht?

Hallöchen,

ich arbeite gerade an einem Tower Defence ähnlichen Spiel, bei dem ich jetzt auf ein etwas größeres Problem gestoßen bin.
Vorweg erstmal ich weiß nicht wie erfahrenere Programmierer das gelöst hätten, aber ich hab die Türme und die Gegner in einen Vector der jeweiligen Klasse gespeichert.
Jeden durchlauf geh ich dann den gesamten Vector durch und Update und Rendere alle Tower und Gegner. Wie sich jetzt rausgestellt hat dauert die Berechnung für die
Gegnerbewegung ziemlich lange und sobald Türme auf dem Feld sind dauert es noch länger. Die Gegner laufen immer zum nächstgelegenen Turm außer der Spieler ist näher als jeder Turm.

Ohne Türme kann ich ca. 10 Gegner spawnen dann bin ich bei ca. 10 FPS.
Ohne Gegner kann ich 4 Türme bauen und bin ebenso bei 10 FPS.

Jetzt zur Frage was kann/soll ich dagegen tun. Ich hab gelesen das ich mit Threads die Bewegung parallel zum Mainthread berechnen lassen kann, oder sollte ich die komplette AI über einen Thread laufen lassen.
Gäbe es sonst noch andere Möglichkeiten?

Schonmal vielen Dank für eure Bemühungen.

rnlf

Frischling

Beiträge: 85

Beruf: Softwareingenieur Raumfahrt

  • Private Nachricht senden

2

05.06.2013, 20:53

Klingt für mich eher so, als hättest du ein ganz anderes Problem und das wirst du nicht durch Parallelisierung lösen können.
Wie berechnest du den nächsten Turm für jeden Spieler?

3

05.06.2013, 21:01

Ich würde die davon abraten.

Ich würde vielleicht erstmal schaun ob sich etwas in der update() oder draw() Methode Vermeiden läst z.B. Berechnungen die nicht nötig sind bei Gegnern die noch nicht gespawnt sind oder Teile die nicht wirklich gezeichet werden müssen Weil sie nicht zu sehen sind.

Kann mir Vorstellen der Wegfinde Allgorithmus brauch viel Rechenzeit. Vielleicht gibts da ja ne möglichkeit pro Frame nur eine bestimmt Entfernung den weg zu Berechnen und so die Rechenzeit zu minimieren.
Wer aufhört besser werden zu wollen hört auf gut zu sein!

aktuelles Projekt:Rickety Racquet

Dreat

Frischling

  • »Dreat« ist der Autor dieses Themas

Beiträge: 86

Wohnort: Heilbronn

  • Private Nachricht senden

4

05.06.2013, 21:05

C-/C++-Quelltext

1
2
3
4
5
6
7
8
9
distance = sqrt( pow( (it->getObjStats().getPosition().x-aiSpr.getPosition().x ), 2.0 ) + pow( ( it->getObjStats().getPosition().y-aiSpr.getPosition().y ), 2.0 ) );

            if( distance < shortestDistance ){
        
                shortestDistance = distance;
                moveX = it->getObjStats().getPosition().x;
                moveY = it->getObjStats().getPosition().y;
        
            }


ich geh jeden Turm durch und schaue wie weit er weg ist, dann Prüf ich ob er bisher der kürzeste ist wenn ja dann Speicher ich die X und Y Position des Turms in moveX und moveY

C-/C++-Quelltext

1
2
3
4
        fAngle = (float)atan2( moveY - aiSpr.getPosition().y, moveX - aiSpr.getPosition().x)*(180/3.14f)+90.0f;

    y = -cos(aiSpr.getRotation()*(3.14f/180.f))*fSpeed;
    x = sin(aiSpr.getRotation()*(3.14f/180.f))*fSpeed;


ich berechne dann die Rotation und dann Rechne ich eben die nächste X und Y Position des Gegners aus.

patrick246

Treue Seele

Beiträge: 328

Wohnort: nahe Heilbronn/BW

Beruf: TG Profil Informatik-Schüler

  • Private Nachricht senden

5

05.06.2013, 21:19

Bei ² ist pow eigentlich unnötig. Speicher dir einfach die x und y-Werte in Variablen und mach dann einfach sqrt(x*x + y*y)

Schrompf

Alter Hase

Beiträge: 1 470

Wohnort: Dresden

Beruf: Softwareentwickler

  • Private Nachricht senden

6

05.06.2013, 21:49

Das macht aber auch keinen großen Unterschied. Ein PC-Prozessor kann pro Kern und pro Sekunde mal locker einige Hundert Millionen sqrt() und pow() berechnen. Da muss irgendwas anderes ein Problem sein... ich meine, selbst wenn Du pro Turm jedes Frame die Grafik neulädst, dürfte das nicht so langsam werden. Auf sowas in der Art würde ich aber tippen.
Häuptling von Dreamworlds. Baut aktuell an nichts konkretem, weil das Vollzeitangestelltenverhältnis ihn fest im Griff hat. Baut daneben nur noch sehr selten an der Open Asset Import Library mit.

Dreat

Frischling

  • »Dreat« ist der Autor dieses Themas

Beiträge: 86

Wohnort: Heilbronn

  • Private Nachricht senden

7

05.06.2013, 22:02

Also ich hab alles durchgeschaut ich lade jede Textur nur einmal

Pro Klasseninstanz eben, die Turm Texturen lad ich sogar nur einmal pro Button an der Seite ich übergeb die Texture vom Button nämlich an die init Funktion der Türme da sie sowieso die selbe Texture haben.

C-/C++-Quelltext

1
2
3
4
void objekt::init( sf::Texture &tex ){

    objektTex = tex;
    objektSpr.setTexture( tex );


Und auch diese Funktion hab ich überprüft sie wird pro Button nur einmal aufgerufen also jetzt grade 3 mal da 3 Button existieren

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

8

05.06.2013, 22:07

objektTex ist was für ein Typ? Ein "sf::Texture" oder ein "sf::Texture&"? Solche Zuweisung enden sonst schnell mal in einem Copy-Konstruktor und der braucht bei sf::Texture SEHR lange. Ich würde an Deiner Stelle dringend einen GL-Sniffer benutzen, z.B. gDebugger. Damit kannst Du ganz fix nachprüfen, ob wirklich jede Textur nur einmal auftaucht. So eine Textur ist versehentlich ganz schnell mal kopiert, was sich mit gDebugger wunderbar sehen lässt, weil die dann eben mehrfach gelistet wird. Hatte ich/wir schon, sehr böse Sache.
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]

Dreat

Frischling

  • »Dreat« ist der Autor dieses Themas

Beiträge: 86

Wohnort: Heilbronn

  • Private Nachricht senden

9

05.06.2013, 22:14

Die Funktion ist verkürzt da wird noch ein anderer Parameter übergeben die ID des Towers mit der ich die verschiedenen Tower unterscheide.

objektTex ist ein sf::Texture

Oke dann werd ich mich morgen wohl mit GL-Sniffern beschäftigen dankeschön.

xardias

Community-Fossil

Beiträge: 2 731

Wohnort: Santa Clara, CA

Beruf: Software Engineer

  • Private Nachricht senden

10

06.06.2013, 00:47

Ein Profiler sollte dir auch etwas mehr infos geben koennen. Wenn du keinen parat hast kannst du notfalls mit manuellen zeitmessungen herausfinden wo die meiste zeit verloren geht.

Werbeanzeige