Array-Effizientität
-
hi,
Ich hab ein Programm das Animationen lädt und sie abspielt:
while(gameopen) { Skip = 0; if(timercounter > 0) { while(timercounter>0) { ++Skip; if(Skip >= maxSkip) { timercounter = 0; Skip = 0; txtlog->WriteLine("Overflow"); } //Update sword->Ani[ATTACK]->Update(); dk->Ani[ATTACK]->Update(); //--------------- //Drawing LogTime(1,"Clear Screen"); al_clear_to_color(al_map_rgb_f(0,0,0)); LogTime(1); LogTime(2,"Draw Ani1"); al_draw_bitmap(sword->Ani[ATTACK]->Draw(),250,400,0); LogTime(2); LogTime(3,"Draw Ani2"); al_draw_bitmap(dk->Ani[ATTACK]->Draw(),300,400,0); LogTime(3); LogTime(4,"Flip screen"); al_flip_display(); LogTime(4); //---------------- } } else al_rest(.005); }
Die LogTimeaufrufe sind nur für die Geschwindigkeitsmessungen verantwortlich.
Hier die Ergebnisse:
Gesamtzeit: 13.902000
Name | Aufrufe | Zeit pro Aufruf | Gesamtzeit | %
-------------------------------------------------------------------------------------------------------
Update BStack | 2160 | 0.000001 | 0.001909 | 0.021652
Clear Screen | 1080 | 0.000002 | 0.001671 | 0.018962
Draw Ani1 | 1080 | 0.007546 | 8.150040 | 92.457345
Draw Ani2 | 1080 | 0.000162 | 0.174612 | 1.980865
Flip screen | 1080 | 0.000451 | 0.486687 | 5.521176
-------------------------------------------------------------------------------------------------------
Gesamt | 6480.000000 | 0.008161 | 8.814918 | 100Wenn ich dk und sword vertausche kommen ca. diesselben Ergebnisse raus.
Wie kann es sein, dass das erste Zeichnen so lang dauert und das 2. so lang?
Von Effizienz kann bei dem Programm keine Rede sein.Jetzt zum Array: Die Funktion Draw:
return bitmaps[actFrame+Direction*frames];
bitmaps ist ein 96 Array mit 96 Frames der Klasse/Struktur (keine Ahnung was das ist) ALLEGRO_BITMAP*.
Also ein Zeiger, dürfte also auch nicht langsam sein. Schon gar nicht nur beim 1. mal.Setze ich das vor die erste Animation ("nach LogTime(1);"):
LogTime(5,"Picture"); al_draw_bitmap(xyz,0,0,0); LogTime(5);
sieht es so aus:
Gesamtzeit: 12.512000
Name | Aufrufe | Zeit pro Aufruf | Gesamtzeit | %
-------------------------------------------------------------------------------------------------------
Update BStack | 1920 | 0.000001 | 0.001897 | 0.024680
Clear Screen | 960 | 0.000002 | 0.001491 | 0.019398
Draw Ani1 | 960 | 0.000084 | 0.080201 | 1.043557
Draw Ani2 | 960 | 0.000020 | 0.019075 | 0.248198
Flip screen | 960 | 0.000327 | 0.313667 | 4.081371
Picture | 960 | 0.007572 | 7.269011 | 94.582795
-------------------------------------------------------------------------------------------------------
Gesamt | 6720.000000 | 0.008005 | 7.685342 | 100Ich hab keine Ahnung warum das so ist.
Noch ein paar algemeine Informationen:
Die Spielebibliothek ist ALLEGRO 5
Die Funktionen erklären sich glaub ich allein außer vielleicht al_rest
al_rest wartet eine Zeit in Sekunden (fast) ohne CPU-Leistung zu "verbrauchen" [al_rest(double seconds)]
LogTime braucht fast keine Leistung, weiß ich einerseits andererseits wars vor dem Log einbau genauso langsam.Was sagt ihr denn dazu?
Ich bin dankbar für alle Antworten.
-
Dieser Thread wurde von Moderator/in volkard aus dem Forum C++ in das Forum Spiele-/Grafikprogrammierung verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
Das liegt daran, das al_draw_bitmap offensichtlich nicht oder nicht nur eine Bitmap zeichnet. Was genau passiert, kann man nicht sagen, dazu muesste man ja allen Code dahinter kennen, d.h. die Bibliothek, die Grafikschnittstelle, welche die Bibliothek aufruft, den Treiber, welcher von der Grafikschnittstelle aufgerufen wird etc. Vermutlich wartet der erste Draw nach einen Flip darauf, das vorherige Bilder verschwunden ist und man den Speicher wieder beschreiben darf. Was lernen wir daraus? Alle Logikberechnungen des Programms nach den Flip ausfuehren! f'`8k
Gruß, TGGC (Was Gamestar sagt...)
-
BTW, mal von Profilern gehoert? Damit koenntest du dir das ganze LogTime sparen
-
Hab den Fehler gefunden.
Ich hab vergessen timercounter wieder runterzuzählen.
So ein blöder Fehler.Timercounter wird 60 mal in der Sekunde erhöht. Da er nie runtergezählt wird gibt dauernd overflows. Die langen Zeiten haben was mit dem DEBUG - Modus zu tun. Vorher gab es sogar ohne Debug so viele Overflows.
Warum aber das erste zeichnen so lange dauert weiß ich auch nicht, hauptsache es läuft jetzt flüssig.