Registriert: Mi Dez 15, 2004 20:36 Beiträge: 454 Wohnort: Wien, Österreich
Ich bin langsam in der Versuchung Delhpi und OpenGL zu verlassen. Heute habe ich etwas an dem Code von Quake 2 für Delphi gebastelt. Ich wollte FSP in "Caption" sehen, und das habe ich auch geschafft. Dabei bin ich mir 100% sicher dass die Technik, die ich benutze um FPS zu berechnen, korrekt ist und dass sie auch funktioniert.
Aslo ,
Mein Desktop Auflösung : 1024 * 768 / 32
Quake Auflösung : 960 * 720 /32 - windowed ( na ja logisch, man muss "Caption" sehen) und 8-bit Texturen waren ausgeschaltet, alles war am Max , was Quake anzubieten hatte..
Das Ergebnis :
min FPS : 182 - (nach minutenlangen Warten)
max FPS 902 -
Durchschnitt : 500-700 FPS (meistens 650+- )
Also wie haben die Leute in ID das erreicht????!??!
Ich schaffe es noch etwa rund um 640 - 700 bei meinem derzeitigen Projekt, aber ihr müsst wissen, ich benutze nur 3 ( DREI ) Texturen, das ganze Szene ist statisch, kein Licht, MultTex., oder sonst, benutze DL.
Haben Sie sich schon mal so gefühlt ? So...ich weiss nicht ....
Registriert: Mi Aug 28, 2002 19:27 Beiträge: 568 Wohnort: Chemnitz / Sachsen
ist an sich relativ egal ob du dls nimmst, wenn de scene sehr viele polygone enthält.
außerdem hat id doch schon paar tricks genutzt, das sollte dir bewusst sein !!!!
Registriert: Do Dez 05, 2002 10:35 Beiträge: 4234 Wohnort: Dortmund
Das sehe ich allerdings mal auch so. Unterschätze nicht die Erfahrung von Leuten die seit vielen Jahren außschließlich nur OpenGL programmieren. Die kennen Trick da kannst du als Außenstehender nur mit den Ohren schlackern.
Eines solltest du dir außerdem auch noch bewusst sein. Es kommt nicht nur auf OpenGL an. Je nachdem was du drumherum machst, kann dies dein Programm schon ziemlich ausbremsen. Und das obwohl du vielleicht nur die Hälfte an Textuen und Flächen hast. Dann kommt es auch noch darauf an was du an "unnötigen" Operationen machst. In Spielen wird üblicherweise der Farbbuffer nicht gelöscht. Sondern nur der Tiefenbuffer. In einem Raum würde der komplette Farbbuffer sowieso überschrieben werden. Dann kommt es auch darauf an wie du deinen Code aufbaust und optimierst. Zum Beispiel kannst du deine Berechnungen beschleunigen in dem du MMX oder 3DNow benutzt. Die FPU kann zur gleichen Zeit wie die CPU eine berechnung durchführen. So kannst du zwei Berechnungen (1x Int und 1X Float) anstelle von einer durchführen.
Ich persönlich bin ja auch ein Verfechter vom optimierten Programmieren aber an einigen Stellen muss man ganz klar sagen, dass dies einfach nur übertrieben ist. Bei deinem derzeitigen Projekt hast du 640-700 Bilder in der Sekunde. Hey. Was soll der Geiz! Ab 30 Bilder in der Sekunde nimmt das menschliche Auge sowieso keinen Unterschied mehr wahr!! Wenn das Projekt fertig ist und du bei ca. 100 FPS angelangt bist, ist das noch mehr als genug um es sinnvoll spielen zu können. Das dürfte dann auch noch halbwegs anständig auf älterer Hardware laufen. Also mach dir da nicht so einen Kopf drum. Das ist alles noch im grünen Bereich.
Es kommt nicht darauf an wie viele Texturen du im gesammten hast sondern eher wie oft man diese wechselt. Es kann ja sein, dass 60 MB Texturen auf der Grafikkarte nicht oder nur kaum genutzt werden. Deswegen wird es aber noch lange nicht langsamer.
PS: So Sprüche wie Delphi und OpenGL verlassen wollen wir hier net hören. Ne im Ernst. Optimieren ist gut und teilweise auch notwendig aber an einigen Stellen macht es kaum Sinn es bis zur Spitze zu treiben. Speziell im privaten Bereich. Firmen haben da einen ganz anderen Zeitrahmen. Und wegen so einer Kleinigkeit die Flinte ins Korn zu werfen finde ich mehr als übertrieben.
Solch hohe Frameraten zu vergleichen macht nicht so viel Sinn, weil die Unterschiede zwischen zwei FPS Raten immer kleiner werden. Der zeitliche Unterschied zwischen 600 und 700 fps ist ja weitaus geringer als zwischen 20 und 40 fps. Außerdem bedeutet eine zu hohe Framerate auch immer, dass Potential verschenkt wird. Man kann die zusätzliche Zeit ja besser in mehr Effekte investieren. Wenn es von der Komplexität her gerechtfertig ist kann man auch bis auf 30 fps runter gehen.
Registriert: Mi Dez 15, 2004 20:36 Beiträge: 454 Wohnort: Wien, Österreich
na ja...mir sind grossteils schon bekannt Dinge, die ihr schon erwähnt habt, aber was mich auch gewundert hat ist die Tatsache dass in einem Pass ("loop pass", nicht Renderpass) so viele verschiedene funktionen/procedur Aufrufe gibt bis es endlich zum gl-Command-s gelangt, und ich dachte, das sei ein Hinderniss für die Geschwindigkeit. Wahrscheinlich ist es auch, aber was das Ganze wircklich beschleunigt ist das, was VOR dem Zeichnen passiert, d.h. es wird NUR dass gezeichnet was wircklich gezeichnet sein muss und nichts anderes (aber das wissen wir schon )
Registriert: Mi Dez 15, 2004 20:36 Beiträge: 454 Wohnort: Wien, Österreich
ah, noch was...ich habe gerade festgestellt , dass die original Version von "ref_gl.dll" ( Zweck der Datei : "Refference to OpenGL", frei übersetzt, enthält änliches was sich auch in dglOpenGl.pas befindet, natürlich dem Zweck angepasst) im Schnit 80-100 FPS schneller ist als die Delphi version.
Wieso ? Ist es wircklich so , dass Programme, die im c / c++ geschieben sind, schneller als die im Pascal geschriebenen sind?
Eigentlich sollte es umgekehrt sein, die original Version wured im Jahr (wenn ich mich nicht irre) 1997 erstellt (kompiliert) und die Kompiler von Delphi Version ist junger (oder?, D6 Jahr 2001), also habe ich angenommen dass die Kompiler von Delphi neuerer ist und besseren und vorallem schnelleren Code generiert.
Wo liege ich falsch ?
Registriert: Mi Aug 28, 2002 19:27 Beiträge: 568 Wohnort: Chemnitz / Sachsen
die dll wird schon an sich paar kleine optimierungen enthalten.
außerdem laut meinem wissen ist delphi inzwischen ca. so schnell wie msvc++!!!
man sollte nicht unbedingt nach noch 100 fps bei 500 + frames suchen, das hält nur auf, wenns wichtig wird, dann is das legitim, aber ansonsten ... naja ob nu 500 oder 800 ??? wenns störts sehen tut mans eh ne mehr und durch timebased movement is es nochmals egal ...
Registriert: Do Dez 05, 2002 10:35 Beiträge: 4234 Wohnort: Dortmund
Der C++ Compiler hat diverse Optimierungen die Delphi nicht hat. Keine Frage. Aber ich denke mal, wenn man sauber und durchdacht programmiert spielen diese Optimierungen keine Rolle. Im Vergleich zu der restlichen Arbeit sind das nur wenige Millisekunden. Also alles andere als Gravierend. Man sollte lieber darauf achten, dass man seine Programme sinnvoll gestaltet und nicht zu viel vergeudet die irgendwo anders gebraucht wird. Auch das "Beste" C++ wird einen unsauberen Code nicht schneller machen als einen durchdacheten Quellcode. Der eigentliche Flaschenhals bei einem Programm ist immer der Programmierer selbst! Ich möchte auch nicht, dass dies zu eine der zahlreichen C++ vs. Delphi Diskussion wird. Davon hatten wir einfach schon zu viele!
Zu der Dll. Ich habe keine Ahnung wie der Code von Quake aussieht und was dort gemacht wird. Aber es würde mich wundern es an der dglOpenGL.pas liegt! Diese Unit implementiert lediglich die Schnittstelle von OpenGL. Und dann greifst du direkt auf die DLL zu. Das wird in C++ genau so gehandhabt. Ich denke einfach mal, dass die in der DLL diverse optimierungen von Hand eingebaut haben um es zu beschleunigen. Aber das sind nur vermutungen, da ich nicht weiß wozu die Dll gut ist. Abgesehen davon reden wir hier immernoch über Peanuts.
PS: Wenn du bei jedem Frame ActivateRenderContext aus der dglOpenGL.pas aufrufst ist es logischerweise lagsamer, da bei jedem Frame alle Funktionspointer neu geladen werden. Aber ich denke mal nicht, dass du das machst, da es sonst wohl sehr langsam sein dürfte.
Registriert: Mi Dez 15, 2004 20:36 Beiträge: 454 Wohnort: Wien, Österreich
mensch....
Ich habe nicht die Absicht pro und contra c++ Diskussion herzuleiten, wircklich nicht. Vielleicht bin ich falsch verstanden, weil meine Muttersprache kein deutsch ist.
@Lossy eX : ActivateRenderingContext gehört zum Init-kram, also bitte, ich bin etwas weiter gekommen und ich habe nicht gesagt dass es an dglOpenGL.pas liegt, ich habe lediglich ein Vergleich gemacht, denn ref_gl.dll ist NUR eine Schnitstelle für OpenGL, genau wie dglOpenGL.pas, aber wie schon gesagt, dem Zweck angepasst.
Es ist auch egal wie klein / gross die geschwindichkeut ist, sie ist FESTSTELLBAR.
Ich habe meine Vorstellungen voran es liegen könnte (die Geschw.-unterschied):
In c/c++ gibt es "#define A B", eine Macro, die kann und wird so oft wie möglich ansteller einer (einfacheren) Funktion benutzt. Nachteil einer Funktion in Delphi wäre also begin / end block, die jedes Mal ausgeführt sein muss
z.B.
in c/c++
#define DotProduct(V1,V2) ( v1[0]*v2[0]+v1[1]*v2[1]+v1[2]*v2[2] )
d.h. vor dem kopilierung wird ausdruck "DotProduct(V1,V2)" durch "( v1[0]*v2[0]+v1[1]*v2[1]+v1[2]*v2[2] )" ersezt. anders gesagt, es gibt keine "echte" funk. im delphi sinne
ich bin mir sicher dass es so was ähnliches in Delphi leider nicht gibt.
Registriert: Do Dez 05, 2002 10:35 Beiträge: 4234 Wohnort: Dortmund
Habe auch nicht gedacht, dass du so etwas machen würdest. Ist mir nur in dem Moment eingefallen.
Und zu den Macros hast du auf jeden Fall recht. Das ist ne Möglichkeit einen kleinen Code ohne die ganzen Stackgeschichten zu versehen. Macht dann aber die Exe größer. Aber in der heutigen Zeit kommt es nicht mehr auf 1 MB an. Weswegen das auch egal ist. In Delphi hätte man nur die Möglichkeit solche kleinen Methode so zu schreiben, dass sie noch komplett in den Registern ausführbar sind. Aufrufkonvention Register. Dann muss Delphi die Parameter nicht mehr umständlich auf den Stack schreiben oder wieder lesen. Nur leider klappt das nicht immer. Oder man schreibt die Methoden in Assembler, dann muss man aber alles per Hand machen. Was auch nichts für jeden ist.
Zum Thema C++ / Delphi. Ich wollte das nur schon mal ersticken bevor da eine Diskussion draus wird. Denn wir alle wissen ja wo so etwas endet...
Registriert: Di Dez 02, 2003 12:47 Beiträge: 300 Wohnort: Marburg
Huch!
Nimmt son "begin" und "end" nur platz im Quelltext ein oder verbraucht dass tatsächlig rechenzeit , wenn mann das Programm ausführt.
Ich dachte immer, nach der Kompilierung sähe dass alles sowieso ganz anders aus (Der Übersetzt dass doch ,ganz für dumme gesagt, beim Kompilieren noch mal den Quelltext für die CPU oder???).
Naja, vielleicht sollte ich mich da mal mit der Theorie befassen
_________________ Nothing, oh sweet nothing,
today we are doing nothing at all...
http://www.geo-progs.de
Im CPU Fenster kann man für den jede Anweisung die entsprechenden Befehle sehen. begin/end kostet selber nichts und ist ja nur dafür da um Anweisungen zu gruppieren.
Mitglieder in diesem Forum: Google [Bot] und 4 Gäste
Du darfst keine neuen Themen in diesem Forum erstellen. Du darfst keine Antworten zu Themen in diesem Forum erstellen. Du darfst deine Beiträge in diesem Forum nicht ändern. Du darfst deine Beiträge in diesem Forum nicht löschen. Du darfst keine Dateianhänge in diesem Forum erstellen.