Geschwindigkeitsvergleich DirectX - SFML: Komische Ergebnisse
-
TGGC schrieb:
Du benutzt unter DDraw einen Clipper?
Ich sagte ja, ich hab das eher auf Grundlage eines anderen Projekts zusammengefrickelt, da ich mich mit DirectX noch nicht wirklich beschäftigt habe und nur mal schnell gucken wollte, ob DirectX viel schneller als SFML ist.
TGGC schrieb:
Du benutzt ein DX, was schon 10 Jahre alt ist!
Ich wollte das ganze möglichst kompatibel mit allen Windowsen halten. Wenn ich ein Spiel programmiere, dann wird es grafiktechnisch eher auf dem Niveau eines NES-Spiels sein. Da wollte ich nicht, daß für sowas die minimalen Systemvoraussetzungen Windows 7 mit DirectX 10 sind. Das soll eben möglichst auch auf einem alten Windows 95-PC laufen. Aber im Moment hätte ich's eh lieber, wenn ich ein plattformunabhängiges Framework hätte. Erstens natürlich, weil ich es dann eben auch für Nicht-Windows-Betriebssysteme kompilieren kann und zweitens, weil man bei der Betrachtung des Quellcodes, der für so eine simple Grafikausgabe auf einem Fenster geschrieben werden muß, rammdüsig werden kann.
P.S.: Falls jetzt jemand denkt: "Wenn Du sowieso bloß so anspruchslose Spiele schreiben willst, kannst Du doch selbst die langsame SDL nehmen": Nun ja, das Problem liegt darin, daß der Benutzer auch in der Lage sein soll, die Ausgabe im Fenster zu vergrößern. Das Spiel selbst braucht mit seinen 320 x 240 Pixeln vielleicht keine schnelle Verarbeitung, aber bei einem PC mit einer Auflösung von 1280 x 1024 oder noch größer, wo das Programm maximiert, aber trotzdem nicht im Vollbild, sondern im Fenster ablaufen soll, brauch ich eben die Geschwindigkeit.
-
SFML ist auch nur bis Win 98 kompatibel. Ein sinnvoller Vergleich waere daher mit der DirectX 9 August 2009 Version moeglich. Dein Codeargument ist auch etwas unsinnig, das sich kaum mehr als 5 Prozent des Code mit DX auseinandersetzen wuerden.
Falls du dich doch auf Zielsystem Windows beschraenken kannst, schau dir mal HGE an, denn das ist genau fuer das von dir gewuenschte konzipiert: http://hge.relishgames.com/overview.html (und wie gesagt: 5 mal schneller bei nahezu identischem Codingaufwand). f'`8k
AutocogitoGruß, TGGC (Was Gamestar sagt...)
-
TGGC schrieb:
SFML ist auch nur bis Win 98 kompatibel. Ein sinnvoller Vergleich waere daher mit der DirectX 9 August 2009 Version moeglich.
Ja, gut, das Argument war etwas übertrieben. Aber prinzipiell gilt es trotzdem: Was bitteschön hat denn die 2009er Version von DirectX 9, das ich so unbedingt brauche, daß ich Benutzer, die noch DirectX 6, 7, 8 oder ein älteres 9 auf dem PC haben, auffordern müßte, es zu aktualisieren? Denn wenn ich mein Zeug mit DirectX 2 realisieren kann, ohne daß das für mich mehr Aufwand ist, sehe ich keinen Grund, DirectX 9 zu nehmen, bloß weil das andere zu alt ist.
TGGC schrieb:
Dein Codeargument ist auch etwas unsinnig, das sich kaum mehr als 5 Prozent des Code mit DX auseinandersetzen wuerden.
Das war mehr so ein Sekundärargument. Ich weiß schon, daß ich, wenn's einmal steht, mich nicht mehr großartig mit DirectX befassen muß. Aber die Programmierung mit der SDL oder der SFML macht einfach mehr Spaß, weil ich da nicht erstmal stundenlang das Grundgerüst aufbauen muß, um dann endlich mal zum eigentlichen Spiel zu kommen.
TGGC schrieb:
Falls du dich doch auf Zielsystem Windows beschraenken kannst
Wenn ich das tue, werde ich wohl wahrscheinlich tatsächlich DirectX direkt nehmen. Wenn's sowieso bloß Windows ist, gibt's keinen Grund, zwischen meinen eigenen Bild- und Sprite-Klassen zur Abstraktion und den DirectX-Funktionen noch ein weiteres Framework zu schalten. Da unterliegt dann die Bequemlichkeit doch gegenüber der Tatsache, weniger Abhängigkeiten zu haben.
-
Sagt mal, kann es sein, daß die SFML sogar langsamer als das stinknormale Windows-GDI ist? Wenn ich ein Bild von 320 x 240 Pixeln 1000 mal hintereinander blitten lasse und die Zeit messe, komme ich bei der GDI auf 735 bis 812 Millisekunden. Bei der SFML sind es 1656 bis 1672 Millisekunden. Das heißt also, dieser ach so tolle OpenGL-Wrapper ist doppelt so lahmarschig als die langsame Standardgrafikbibliothek in Windows.
-
Wie kommst du darauf, das SFML schnell waere? Wie kommst du darauf das GDI langsam waere?
Warum du ein neuerer DX benutzen sollst, habe ich doch schon oben erklaert: Du benutzt ein Grafik-Api von vor 10 Jahren also kannst du ja auch gleich eine 10 Jahre alte Grafikkarte benutzen und dich wundern, das sie langsam ist. f'`8k
AutocogitoGruß, TGGC (Was Gamestar sagt...)
-
Naja das Alter ist für sich genommen ja wohl überhaupt kein Argument. Wir benutzen mit x86 grösstenteils (abgesehen von Erweiterungen als MMX/SSE/...) einen Befehlssatz der mehr als 10 Jahre alt ist. Deswegen sind die Programme trotzdem nicht 3x langsamer als mit z.B. AMD64.
-
TGGC schrieb:
Wie kommst du darauf, das SFML schnell waere?
Weil SFML angeblich OpenGL benutzt und, genauso wie OpenGL selbst, unter anderem dazu gedacht ist, damit Spiele zu programmieren.
TGGC schrieb:
Wie kommst du darauf das GDI langsam waere?
Weil keiner mit GDI Spiele programmiert. Und die Geschwindigkeit schon bei mittelgroßen Bildern merklich in die Knie geht.
TGGC schrieb:
Warum du ein neuerer DX benutzen sollst, habe ich doch schon oben erklaert: Du benutzt ein Grafik-Api von vor 10 Jahren also kannst du ja auch gleich eine 10 Jahre alte Grafikkarte benutzen und dich wundern, das sie langsam ist. f'`8k
Ist Dir die Ironie aufgefallen, daß ich mich an keiner Stelle über eine zu langsame Geschwindigkeit bei DirectX beschwert habe? (Bei dem Vergleich im Ursprungspost ging es eher um die Inkonsistenz in den Ergebnissen und nicht darum, daß DirectX per se langsam wäre.)
-
Ich glaube ein paar sinnvollere Tests wären mit 1000+ Sprites die rotieren und evtl. Shadern (wobei der Shaderzeichenablauf eigentlich bei pur-DirectX und SFML identisch sein sollte und sich somit kein Performanceunterschied rausstellen sollte, zumindest fällt mir nix ein was für einen merklichen Unterschied spricht).
Dann sollte GDI+ relativ schnell an seine Grenzen kommen.
Trotzdem wird SFML wohl immer ein bisschen abkacken. Laurent Gomilla hat im Forum mal gemeint, dass es n Haufen Zeug gibt dass er für Performance optimieren könnte. Einiges davon will er in SFML2 umsetzen, anderes lässt er aber absichtlich bleiben da es sonst Probleme mit dem Design gibt (er bleibt z.b. bei glBegin und glEnd Blöcken anstatt irgendwie nen Scene Manager mit Vertexarrays zu benutzen).
Ich such mal nach dem Post und editier dass dann rein falls ich ihn finde.
Und achja: in Windows Vista war OpenGL ja (man munkelt absichtlich von Microsoft so hingefrickelt) langsamer als DirectX, ich weiss nicht ob das mit Windows 7 auch noch gilt.
-
TravisG schrieb:
Ich glaube ein paar sinnvollere Tests wären mit 1000+ Sprites die rotieren und evtl. Shadern
Nein, wieso? Wenn ich ein Spiel programmiere, dann wird das eins auf dem grafischen Niveau eines NES-Spiels. Da gibt's keine Rotation oder sonstige Effekte. Da ist das einzige, was mich interessiert, wie schnell die Bilder dargestellt werden können, vor allem, wie schnell sie dargestellt werden können, wenn ich das Ausgabefenster vergrößere. (Die eigentliche Spielfeldauflösung wird zwar nur 320 x 240 oder 256 x 224 Pixel sein, aber dieses Bild soll ja für den Benuter auch vergößert werden können.)
TravisG schrieb:
Dann sollte GDI+ relativ schnell an seine Grenzen kommen.
GDI+ sowieso. Das hab ich mal vor Monaten ausprobiert. Der lahmarschigste Scheiß überhaupt. Ich rede hier von der GDI.
Aber es ist auch egal, ob die GDI an ihre Grenzen kommt. Die wurde ja nur als Vergleich benutzt. Die GDI ist ohnehin zu langsam. Und wenn SFML noch langsamer ist, während DirectX (also, direktes DirectX, nicht über noch viel, viel langsamere SDL gekapselt) abgeht wie Schmidts Katze, dann frag ich mich, was die SFML (und SDL) ausbremst.TravisG schrieb:
Trotzdem wird SFML wohl immer ein bisschen abkacken.
"Ein bißchen" ist gut.
TravisG schrieb:
Und achja: in Windows Vista war OpenGL ja (man munkelt absichtlich von Microsoft so hingefrickelt) langsamer als DirectX, ich weiss nicht ob das mit Windows 7 auch noch gilt.
Also, die Tests wurden auf jeden Fall mit Windows XP und auf dem alten PC mit Windows 2000 gemacht.
-
Hi, I'm from sfml-dev.org
I don't speak German.
Looking at your src code you need sf::RenderWindow::SetFramerateLimit()
screen.SetFramerateLimit(60.f);
DirectX is a lower level API so it should be faster.
Also, raw total FPS is also not a good benchmark of performance.
-
NES-Spieler schrieb:
Ist Dir die Ironie aufgefallen, daß ich mich an keiner Stelle über eine zu langsame Geschwindigkeit bei DirectX beschwert habe? (Bei dem Vergleich im Ursprungspost ging es eher um die Inkonsistenz in den Ergebnissen und nicht darum, daß DirectX per se langsam wäre.)
Und dir ist wohl nicht aufgefallen, das die Inkonsistenz aus genau diesem Grund entsteht. Du benutzt etwas, das nur aus jahrzehntelanger Abwaertskompatibilitaet existiert - wie gut das funktioniert ist im Grunde Zufall. Genauso wie das "Streckverhalten" aus deinem anderen Thread - so etwas war damals einfach noch nicht standardisiert. f'`8k
AutocogitoGruß, TGGC (Was Gamestar sagt...)
-
Wenn ich ein Spiel programmiere, dann wird das eins auf dem grafischen Niveau eines NES-Spiels.
Mal abgesehen davon was warum wie schnell ist solltest Du Dir primaer die Frage stellen, welches Framework fuer Dich am geeignetsten ist und ob "langsamer" bei der gegebenen Aufgabe nicht immer noch "schnell genug" ist.
-
NES-Spieler schrieb:
TravisG schrieb:
Ich glaube ein paar sinnvollere Tests wären mit 1000+ Sprites die rotieren und evtl. Shadern
Nein, wieso? Wenn ich ein Spiel programmiere, dann wird das eins auf dem grafischen Niveau eines NES-Spiels. Da gibt's keine Rotation oder sonstige Effekte. Da ist das einzige, was mich interessiert, wie schnell die Bilder dargestellt werden können, vor allem, wie schnell sie dargestellt werden können, wenn ich das Ausgabefenster vergrößere. (Die eigentliche Spielfeldauflösung wird zwar nur 320 x 240 oder 256 x 224 Pixel sein, aber dieses Bild soll ja für den Benuter auch vergößert werden können.)
Ja, für verschiedene Zwecke gibt es sicherlich verschiedene Libs die dafür optimal sind, je nachdem auf was man abzielt (Performance / Erleichterung des Entwickelns / Hübsch-heit des Codes usw.). Theoretisch könnte man bestimmt auch irgendwie seine eigenen Treiber zusammenfrickeln, die für die eigene Anwendung auf die schnellstmögliche Art ausführen.
TravisG schrieb:
Trotzdem wird SFML wohl immer ein bisschen abkacken.
"Ein bißchen" ist gut.
Bei solchen 2-Bilder-Tests ist der Unterschied zwar noch heftig, aber ich bin mir ziemlich sicher, dass die Geschwindigkeitsunterschiede bei aufwendigeren Tests viel geringer ausfallen. Dennoch wird "pures" DirectX oder OpenGL in der Regel immer schneller sein, als ein Wrapper, weil ein Wrapper ja in der Regel nicht einfach "wrapped" sondern noch einige Komfortfunktionen mit einbaut. Aus dem Grund finde ich einen Vergleich von SFML vs DirectX eher unsinnig. HGE vs. SFML kann da passender sein, aber dazu kann ich nichts genaues sagen. HGE hab ich nie ausführlich benutzt, nur kurz angeschaut usw. Aber wie gesagt, wenn du nur (wenige) gerade Vierecke mit Bebilderung brauchst, gibts wahrscheinlich andere Libs die besser für dich geeignet sind.
-
TravisG schrieb:
HGE vs. SFML kann da passender sein, aber dazu kann ich nichts genaues sagen.
Ich kann dazu genaueres sagen: HGE war bei mir 5x schneller. Warum weiss ich aber auch nicht. f'`8k
AutocogitoGruß, TGGC (Was Gamestar sagt...)
-
Ich buddel das hier nochmal aus, Laurent hat was dazu geschrieben (der Thread verlnikt auf unseren Thread hier und jetzt umgekehrt):
http://sfml-dev.org/forum/viewtopic.php?t=2496 schrieb:
Hi.
As long as the window is in its original size, everything is quite fine. But now imagine someone has a screen resolution of 1280 x 1024 and wants to play the game in a maximized window. On my new QuadCore PC the speed is still acceptable. But imagine a person with a PC of 700 MHz. On this PC the movement takes more than three seconds.
First, I don't think that "imagine" is really meaningful when talking about performances, I'd prefer real numbers
But ok, let's say that these "3 seconds" are the benchmark result. 3 seconds to perform 1280 moves gives approximately 2.3 ms per frame, right? 2.3 ms per frame is 430 frames per second. I don't see what's critical here.
Did I miss something?Generally speaking, drawing one or two sprites is not a significant benchmark, because the results are polluted with the overhead of event / window handling. This is not significant when drawing a real scene because it happens once per frame regardless the number of sprites that you draw, but when you draw only one or two it becomes significant.
And 2.3 ms per frame is not really signficant too. I'd suggest that:
- you perform many tests (drawing strings, drawing sprites, drawing shapes, using rotations, alpha-blending, scale, ...)
- you draw a huge number of thingsAnd after that, don't forget to test SFML 2 too, because it has better performances than SFML 1.6
