spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

du kannst das problem ein wenig eingrenzen, in dem du mit texture atlase oder texture arrays arbeitest (kommt drauf an welche api du nutzt).

Zitat von »"Dustin Braun"«

Wo ist denn der Performance knackpunkt beim Texturieren?

Muss man darauf achte wenig texturen zu zeichnen, oder ist es egal wie oft ich zeihne, hauptsache es ist die selbe textur? Es wird also nur langsamm, wenn ich viele verschiedene Txturen verwende? Also, wrauf muss ich achten?

als grundregel gilt je weniger texturwechel desto besser. eher eine große als mehrere kleine.

Wenn du es ganz genau wissen willst, dann messe doch eingach mal die Zeit pro Renderdurchgang.

float fTime =0.00001f;
DWORD dwTimeOld=0;
DWORD dwTimeNew=0;

dwTimeOld = timeGetTime();

Renderfunktion(fTime); // Hier musst du noch die Zeit ausgeben

Move(fTime);

dwTimeNew = timeGetTime();

// Zeit in Sekunden
fTime = (float)((dwTimeNew - dwTimeOld) * 0.001f);

Nun Probiers mal mit vielen kleinen Texturen bei häufigem Wechsel.

Oder mit großen Texturen und nur einigen Texturwechseln.


P.s.: 1/fTime = FP/s

Die WinMM.lib must du auch einbinden und
falls nich schon vorhanden mmsystem.h .

Du darfst, dass doch nicht so überbewerten.

Mir scheint du hängst dich gerade zu sehr am Detail auf.

Man kann noch ewig darüber diskutiern, was denn schneller wäre oder nicht?

Wie gesagt mess doch einfach mal die Zeit, wenn es dir so 100 % darauf
ankommt, ob es nun mit 76 FPS oder mit 69 FPS läuft.

Wichtiger ist: Die Dreiecke, die nicht sichtbar sind, sollten erst gar nicht weiter betrachtet werden und sofart rausfallen, das spart auch viel an den Ressourcen.

Zitat von »"Dustin Braun"«

Ja, mir geht es wirklich sehr um das Detail, denn wenn ich überall nicht ans detail denken würde, würde das eine katasthrophe werden! Ich hole lieber aus allem das meiste raus!

Das Problem ist, ist, dass es nicht überall gleich ist.
Du hast unzähliche verschiedene Grafikkarten und die haben ja auch nicht alle die gleichen Stärken. Die einen haben mehr Speicher, die anderen sind höcher getaktet usw. Das heisst, dass du dich eigentlich auf nur sehr wenig verlassen kannst. Ansonsten musst du das einfach mal testen, indem du deine Fragestellung isolierst und dann genau auf das auf deinem Zielsystem testest. (mit einem Profiler wirst du sehr schnell fündig).

Wenn du allerdings Richtwerte haben willst, was so DX Funktionen kosten, kannst du mal hier schauen:
http://msdn.microsoft.com/en-us/library/bb172234(VS.85).aspx

Ganz unten sind ein paar Aufrufkosten aufgelistet. (Findest du auch in der Offline Doku.)

du machst einen fehler, den viele machen: sich über performance gedanekn zu machen bevor man anfängt zu implementieren. fang einfach an, und optimiere hinterher. oftmals findet man dann noch andere bottlenecks, die man gar nicht vermutet hätte.

Zitat von »"TrommlBomml"«

du machst einen fehler, den viele machen: sich über performance gedanekn zu machen bevor man anfängt zu implementieren. fang einfach an, und optimiere hinterher. oftmals findet man dann noch andere bottlenecks, die man gar nicht vermutet hätte.

da kann ich nur zustimmen. meistens sind es die bottlenecks, die man am wenigsten erwartet