JLI Spieleprogrammierung

[RayJunx]

Habe die Ehre!
da bin ich schon wieder, man möge mir verzeihen aber ich bin auf ein irrwitziges Performance Paradoxum gestoßen, folgendes:

Auf der Suche nach dem Flaschenhals:

Eigentlich wollte ich nur Ausloten welche Programmteile bei der Grafikausgabe
die meiste Leistung schlucken und wieviel Leistung noch durch Optimierung
herausgeholt werden kann.

Grundlage: Ein Programm das exakt die Methoden aus dem Buch zur
erzeugung von Sprites (sprite.cpp) und des ResourceManagers verwendet
um 2D Texturen auf den Monitor zu zaubert und dabei die Framerate
anzeigt. Es geht um die Performance. ( Man kann auch das Asteroid Programm
verwenden, ist im prinzip dasselbe ).

Wenn ich 2000 Objekte darstelle erhalte ich bei einer Auflösung von
1600x1200 Pixel 25+-1 Frames pro Sekunde. Texturgröße 64x64 Pix

Und zwar EGAL ob ich die Bilder drehe, scaliere, oder animiere
alleine "draw" scheint die Performance zu schlucken.
Wenn ich zweimal drawe halbiert sich die Framerate näherungsweiße.

Es liegt aber auch nicht an den Klassenzugriff, wenn ich die
Set rotation aufruhfe, mehrfach wie auch die anderen Funktionen
hat es keinen einfluß auf die Performance.

vorläufiges Fazit. Angewendete Effekte spielen keine Rolle,
einzig die anzahl der draw aufruhfe. Aber das kann doch nicht
sein? Wenn die grafikkarte richtig genutzt wird
müßte ich doch viel mehr grafiken direkt mappen können,
als ich grafiken, scaliere, rotieren und DANN auf den
bildschirm stempeln kann. Wo liegt der hund begraben?

Wenn ich die Auflösung der Grafik bis runter auf 16x16 schraube
ändert das nämlich auch in keiner weiße die Performance !?

Rechner: 3,2GHZ AMD 2GIG RAM 512 ATI-X850 256MB Grafikkarte

Hier habe ich einen Auszug der den Draw befehl der Sprite klasse
zeigt. Es würde mich sehr freuen wenn mir jemand sagen kann
woran das ganze Programm lahmt. Man will ja weder Leistung
noch Grafikpower verschenken, nicht wenn nur irgendwo ein
Flaschenhals das Programm herunterwürgt.

gruß an alle!

Rayjunx

[PeaceKiller]

Soviel ich weiß verwendet die Erstausgabe von JLI mit DX8 (oder war's 9?) für jedes Sprite ein extra DX-Spriteobjekt. Das könnte ein Flaschenhals sein.

Außerdem ist das verhalten völlig normal auf heutigen GPUs. Die sind heutzutage auf wenige Calls mit vielen Polygonen ausgelegt. Also macht es einen riesen Unterschied, ob du 10*100 000 Polygone zeichnest, oder 100 000*10 Polygone.
_________________
»If the automobile had followed the same development cycle as the computer, a Rolls-Royce would today cost $100, get a million miles per gallon, and explode once a year, killing everyone inside.«
– Robert X. Cringely, InfoWorld magazine

[RayJunx]

Hi!
erstmal danke die ideen sind schonmal gut. Es sieht so aus als würde das buch schon die 9directx verwenden.
das eigene sprite objekte erzeugt werden könnte ein argument sein,
kann man das den irgendwie umgehen?
Anbei ist der direct3d code, ist unverändert von mir aus dem buch
übernommen worden.
Würde es klasse finden wenn man auf mehr objekte hochschrauben
könnte ohne das die performance sich alleine an der anzahl
aufhängt.
vielleicht findet ja jemand die achilles sehne

gruß

Rayjunx

[Patrick]

Ich sehe Du benutzt D3DX und D3DXSprite. Da wunderst Du Dich über schlechte Performance?
_________________
'Wer der Beste sein will muss nach Perfektion streben und jede Gelegenheit nutzen sich zu verbessern.' - KIA
[ German Game Dev | Boardsuche hilft sehr oft | Google rockt | Wie man Fragen richtig stellt | ICQ#: 143040199 ]

[GreveN]

Im Buch wird meines Wissens auch das D3DX-Spriteobjekt verwendet, und das ist sowieso nicht grade für seine überragende Performance bekannt, zudem ist der Code im Buch nunmal auch eher auf leichte Verständlichkeit als auf Highspeed ausgerichtet, von daher finde ich 25 FPS bei 2000 Objekten... naja... angemessen.

Lässt sich natürlich einiges mehr rausholen, wenn du das ganze per Hand machst, immer 4 Vertices + Textur drauf und du hast dein Sprite. Und an dieser Stelle gehts auch schon los, die Vertices sollten nach Möglichkeit im schnellen Grafikkartenspeicher liegen, das spart beim Rendern wertvolle Zeit, jedoch solltest du auch nicht für jedes kleine Kacksprite einen eigenen Vertexbuffer anlegen sondern mehrere zusammenfassen, wie Peace Killer schon sagte, ist das Rendern großer Datenmengen aus einem Buffer auf einen Rutsch wesentlich schneller als viele kleine Buffer zu rendern. Ordentlich Speed können auch nochmal Indexbuffer bringen. Ansonsten drauf achten, dass du nach Möglichkeit den best optimiertesten Primitiventyp verwendest (in OGL z.B. Triangle-Strips), dass du nicht unbedingt mehr renderst wie nötig (Stichwort Culling), wobei wiederum zusagen ist, dass es moderne GPU's einen Feuchten schert, ob sie mal eben ein paar Hundert Polygone mehr oder weniger zu Rendern haben, also an dieser Stelle mit dem Filtern und Sortieren nicht übertreiben. Weiterhin solltest du eine gewisse Sortierung in deine zu rendernden Objekte bringen, um z.B. unnötige Texturswitches zu vermeiden, usw. usf., um dir nur mal 'nen groben Überblick zu geben.
Über das Thema kann man ganze Bücher schreiben.

p.s.: Ich hab die Erfahrung gemacht, dass du moderne Grafikkarten eher durch das übermäßige Verpulvern von Füllrate in die Knie zwingst, als durch überflüssige Geometrie.

[RayJunx]

na da hab ich aber was losgetreten.
mußte eben auch feststellen das ich auf über die bisherige sprite methode auch weit mehr als 256 theoretischen texturenspeicher reinladen.
er verbraucht nur immer mehr normalen arbeitsspeicher. außerdem läuft
alles dadurch garnicht langsamer, was mir sagt das er von vornherein scheinbar nicht den grafikkarten speicher verwendet!??
ach man eigentlich will ich ja nur 2d texturen darstellen,
mit alphachanal überblendung, rotation, position, und das wars.
kann ich den ohne großes taram einfach solche optimierten
elemente erzeugen im grafikspeicher anlegen und verwalten?
ich dachte immer im buch stand das das schon im grafikkarten speicher abgelegt wird, siehe beispiel oben... ???
_________________
Just a Freak

[fast hawk]

Schon wieder ein doppelpost(du musst nur ein mal auf absenden gehen)!!
Du kannst des auch mit surface machen dann musst du sie aber
händisch rotieren. Dafür aber deutlich schneller vorallem bei großen Flächen
und wenigen.
_________________
Jetziges Projekt: The Ring War
Status: 40%
-----------------------------------
Nicht weil es schwer ist, wagen wir es nicht, sondern weil wir es nicht wagen, ist es schwer.
--
Lucius Annaeus Seneca (4)
röm. Philosoph, Dramatiker und Staatsmann

[GreveN]

Hm... das sauber mit ordentlich Speed hinzukriegen erfordert schon "etwas" Arbeit und Erfahrung, allerdings ist der Lerneffekt auch nicht zu verachten.

Wenn du meinst, dass du soweit bist, dass du dir auch losgelöst vom Buch etwas aneignen könntest, dann könntest du z.B. mal mit diversen Fix-und-Fertig-Engines rumspielen, HGE z.B. ist vom Design und Aufbau her zumindest relativ leicht zugänglich und liefert performancemäßig brauchbare Ergebnisse.

[51m0n]

Hi

[GreveN]

Hängt davon ab, reden wir von DirectDraw-Surfaces?

[RayJunx]

hi,
habe mich noch etwas schlau gelesen. Also einmal ist es ganz gut das program wie ich es verwende verwaltet die texturen dann, bzw schiebt sie in den schnellsten bereich laut buch, auf die grafikkarte bzw agp speicher, und soweit bin ich ja mit den ergebnissen ganz zufrieden.
außerdem belegen die texturen nicht die ungepackte größe so wie aussieht
eine 137mb textur (pixel mal 4byte) schluckt zum beispiel ca 12mb mehr arbeitsspeicher wenn ich ihn zum auslagern bringe. also irgendwie weiß ich nicht wie ers tut aber mit 1000 objekten bei 60hz was der rate meines
tfts entspricht fahr ich ganz gut. auch bei 1920x1200er auflösung.
ich habe auch gesehen das es maßgeblich von der prozessorleistung
abhäng, ein über oder untertakten meiner grafikkarte hat nämlich
praktisch auch keine auswirkung, bzw es hängt auch primär von
der geschwindigkeit der speicheranbindung ab, so bisher mein eindruck
werde jetzt erstmal damit arbeiten wenn ich dann wirklich an die grenzen kommen sollte kann ich sicher was anderes ausloten.

eine frage habe ich noch, wie viel schneller wären den andere
routinen? Kann mal eben einer einfach 2000 bildchen mit 64x64
pixel mit "seiner" engine darstellen und schaun ob er auf 60 frames
kommt? bzw wieviele sprites er bei 60 frames fahren kann ?

gruß
Rayjunx
_________________
Just a Freak

[GreveN]

Lol, da sollten 1000 FPS fast kein Problem sein.

[51m0n]

[AFE-GmdG]

Also mit meiner 3D-Engine Rendere ich derzeit etwa 100000 Polygone flüssig - wobei ich definitif sagen kann, dass ich den selben Vertex und Indexbuffer nutze, keine Texturchanges drinn hab und einfach nur ein und das selbe Objekt nur sehr oft pro Frame rendere. Aber 3D ist ja eh nicht mit Spritebasiertem 2D zu vergleichen...
_________________

[GreveN]

Wie gesagt, kann ich aus Erfahrung bestätigen, dass Geometrie heutzutage fast kein Problem darstellt, problematisch wirds nach meinen persönlichen Erfahrungen bei den Füllraten, insbesondere auch, wenn man ohne z-Buffer arbeitet.