Huhu,

ich beschäftige mich eine Weile mit OpenGL und suche dafür einen möglichst akkuraten Weg einen konstanten Timer zu finden (also egal ob der PC zu 200% ausgelastet ist oder nur zu 2% *g*) - im Moment vergewaltige ich GetTickCount um Objekte/Kamera zu bewegen, aber das reicht mir nicht wenn ich mehr will als nur bewegen Man könnte zwar sowas in die glDraw-Funktion setzen
(wenn ich das event nur 1x aufrufen will):



aber das ist meiner Ansicht nach sehr beschränkt und bei wiederkehrenden Timer-Events gäbs schon die ersten Probleme (von der Übersichtlichkeit des Codes mal ganz abgesehen )

Natürlich _KÖNNTE_ man auch SetTimer vewenden, aber wie gesagt, ich steh mehr auf akkurates Timing - ein seperater Thread wäre ja auch noch drin (dann wäre es auch richtig akkurat), aber es geht auch bestimmt vieeel einfacher

und ich sag es im Voraus: ich möchte nicht hören dass der Endverbraucher das sowieso nicht merkt, es ist eine Frage der Qualität


Optimize? Are you nuts?! We have >1GHz's, we don't need to OPTIMIZE!

Schau mal in die Win32 Hilfe, da findet sich ein QueryPerformanceCounter... Oder ich blaub bei den Neobrothers gibts sogar ein kleines Tutorial dazu. Die sind für so gut wie alle Zwecke ausreichend genau.

Machs doch folgender maßen:


Und anstelle von GetTickCount kannst Du den von Delphic erwähnten Timer verwenden, um die Sache genauer zu machen. So ist auf jeden Fall Dein Code übersichtlicher und die Framerate wird nicht begrenzt. Allerdings muss LastTick eine globale Variable sein, aber das dürfte ja bekann sein.

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Ja dem kann ich mich nur anschließen. Wie wäre es, wenn du nicht deinen Timer nach der Szene ausrichtest sondern andersrum.
Zu gut Deutsch. Du misst mit hilfe vom PerformanceCounter die FPS und berechnest anhand dieser um wie viel du deine Objekte bewegen musst.
Das hat nämlich einen wesentlich besseren Vorteil. Du bekommst immer die maximal mögliche FPS. Und auch wenn der Rechner dafür zu langsam sein sollte, spielt sich in der gleichen zeit auch der gleiche inhalt ab. Bzw wenn deine Kiste zu gut sein sollte, langweilt sie sich wenigstens nicht.
So wird das ja auch in JEDEM Spiel auch gemacht!

SchodMC schrieb:


Ich habe diesen Code in meine Anwendung eingebaut und statt


eingefügt. Wenn man das Programm dann auf einen Pentium IV mit einer Geforce 4 compiliert und ausführt, ist die Performance ok, aber wenn man die Exe dann auf einem P3 1 Ghz mit einer GForce 2 Riva TNT2 ausführt, dann ruckelt es ohne Ende. Auch wenn man für LastTick + 5 anstatt der +5 einer Variable vom Typ Byte nimmt und die manuell verstellt, hört es nicht auf zu ruckeln ... wo liegt der Fehler ? Oder muss man einen High - Performance - Counter verwenden, um das Ruckeln auf anderen Processoren abzustellen ?

_________________
No pain, no gain

Ich an deiner Stelle würde den Fehler nicht umbeding an dem GetTickCount suchen. Sondern eher an dem Rest von deinem Program bzw an dem anderen Rechner. Es kann ja sein, dass du aus versehen etwas sehr Grafikkartenspezifischen benutzt. Oder so etwas. Das müsstest du ja am besten wissen.

Also ich habs heute nochmal probiert und festgestellt, dass das Programm nicht ruckelt, wenn es auf einem langsamen Rechner kompiliert wird und die EXE dann auf einem schnellen Rechner ausgeführt wird ...

Ich habe mich entschlossen, meinen Quellcode auf meiner HP abzulegen und darauf zu hoffen, dass jemand eine Lösung für mein Problem hat ... aber ich glaube, es liegt irgendwie an der Zeitmessung ... andersrum funktioniert diese Routine mit GetTickCount unter C++ auf jedem Rechner (ich weis, ist Feindesland ).

Also ... den Quellcode (Delphi 6) findet Ihr unter
www.onkeltortysfiles.de/kopie.zip

Und eine mit einem P4 2 Ghz kompilierte Exe unter
www.onkeltortysfiles.de/ruckel.zip

Ich wäre für eine Lösung (noch mehr für einen korrigierten Quellcode) verdammt dankbar ...

_________________
No pain, no gain

Ich muss sagen bei mir ruckeln beide Versionen nicht. Nicht die vom P4 und auch nicht die Quellen.
Und das auf einem Duron 1.2 Ghz mit einer TNT 2!!!

Jetzt muss ich aber auch mal ne kritik loswerden. (nimm mir das bitte nicht übel) Aber deine Quellen. Die werden sehr unübersichtlich, wenn das mehr noch mehr wird.
Und mal ne bescheidene Frage. Warum hast du komplett auf die VCL verzichtet? (wegen 100Kb an der exe) Du hast hast das Delphi kastriert!!
Nebenbei erwähnt. OOP soll wunder wirken, was die lesbarkein und den Programmierkomfort angeht.

Was mir aus deinen Quelen auch nicht so ganz klar geworden ist. Wozu du die 5ms Zeit dazwischen überhaupt brauchst?
Ich befürchte aber mal, das rückeln (gelegentlich hacken) entsteht dadurch, dass du in dem Draw erst abprüfst ob die "notwendige" Zeit verstrichen ist.
Die Beste alternative zum Zeichnen ist einen eigenen Thread abspalten, der in dem Execute permanent das Zeichnen aufruft und mittels vom PerformanceCounter die FPS berechnet und diese als Faktor in die Bewegungen deiner Szene mit einfließen. Wie ich oben schon mal erwähnt hatte.

Ach ja mir ist noch etwas aufgefallen. In der Methode mauszeiger.
Dort kannst du das Ständige glBegin und glEnd weglassen. Aber auch nur wenn diese vom selben Typen (GL_QUADS, ...) sind. Das beschleunigt das Ganze noch mal ein ganzes bisschen.
Also nur zu Begin ein glBegin und ganz am Ende ein glEnd. Bzw. Das ganze dann auch, wenn du die Textur änders.

Das das bei Dir nicht ruckelt, haut mich glatt vom Hocker ... am besten, ich nehm mir mal nen anderen PC und lass es drauf laufen ... vielleicht hat der langsamere PC ja ne Meise oder so ....

Ich hab Deine Kritik zur Kenntnis genommen und bin immer froh um jede Hilfe, egal ob Sie aus Kritik besteht oder nicht ...

Du hast recht ... es war eigentlich Schwachsinn, eine API zu programmieren und ich werde das ganze jetzt mal auf VCL umstellen ...

Die 5 ms Zeit wollte ich eigentlich durch eine Berechnung ersetzen ... im Moment stellen sie den Wert dar, ab dem mein P4 nicht mehr ruckelt ... ab 6 ms sieht man die ersten Ansätze.

Das OOP Wunder bewirkt, ist mir klaro ... ist auch bei C++ so, aber das Projekt war eigentlich nur zum Experimentieren gedacht ... deswegen hab ich nur auf die Erforschung von Funktionen Wert gelegt ...

Das glBegin und glEnd bei der Methode Mauszeiger hab ich raus ... Danke für den Tip

So, nun werd ich mir mal den Performance - Counter vornehmen ... und hoffen, dass es klappt 8O Die Frage ist nur, in welcher Stelle im Code die Zeit gemessen werden muss ... (oder: ms per frame oder frame per ms ??)

_________________
No pain, no gain

Na ja. So viel ist der Szene ja nun wirklich nicht. Von daher sollte es mich vom Hocker hauen wenn es bei mir ruckeln sollte.

Den PerformanceCounter fragst du vor dem Rendern der Szene ab und nach dem Rendern. Dann liegen nur noch Mininaloperation (z.b: Events, FPS berechnen, ...) außerhalb der Zeitmessung.
Wenn du dann mit den beiden Werten die FPS (mind. Singlewert) berechnest, dann kannst du damit wunderbar deine Szene bewegen. In dem du zum Bleistift den weg deiner Objekte für 1 Sek nimmst und dass dann durch die fps rechnest.
Und du wirst sehen alle deine Objekte werden egal wo gleich schnell sein.
Zu testzwecken kannst du in dem Render der Szene mal ein sleep(100) machen oder so. Sprich auf ca. 10 Fps begrenzen. Nur mal so um zu testen obs geht.
Achja die FPS kannst du natürlich nicht anzeigen. Weil diese FPS nur die FPS vom letzten Bild ist. Da kannst du rein gar nichts mehr erkenne, wenn du das ausgibst.

Gegenfrage: Warum das ganze VCL-Geraffel verwenden, wenn man es sowieso nicht braucht?!? Ein einfaches API-Fenster ist für die Ausgabe voll ausreichend. Wenn man dann später noch für's Render 'nen eigenen thread verwenden will, gibt's wenigstens keine Probleme mit dem VCL-Haupt-Thread.

Außerdem, ist es durchaus möglich, dass durch die VCL ein paar ms verloren gehen, da die VCL eine recht aufwendige Haupt-Schleife mit allen möglichen abfragen hat, die für ein einfaches OpenGL-Programm einfach nicht notwendig sind. Zugegeben, das fällt mit ziemlicher sicherheit so gut wie garnicht in's Gewicht.

Wenn ich ein größeres Projekt mache, dann eigentlich ohne VCL-Form, sondern mit einer eigenen da ich die VCL-Form nicht verwende. Und kastriert ist Delphi damit auch nicht. Ich lasse lediglich die VCL weg. Arg viel kleiner ist deswegen mein Prog auch nicht, denn die Sysutils sind einfach praktisch und brauchen auch ihren Platz!

Aber was OOP angeht, da muss ich Dir recht geben. Und wenn man sein Prog in verschiedene Units und Objekte aufteilt, ist es eigentlich egal ob man VCL verwendet oder nicht. Bei richtigem Programmierstiel (Kommentare, sauberer Source-Code, ...) behällt man immer die Übersicht.

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Die VCL ist reine Geschmackssache.
Aber wenn ich schon mit Delphi arbeite, dann will ich nicht alles bis auf die WinApi runterbrechen. Wobei ich sowieso sehr sehr selten nur 1 Fenster habe auf dem sich nichts anderes ist als ein RC befindet.
Von daher macht es für wich wenig Sinn auf die VCL zu verzichten. Da würde ich mir nur noch mehr arbeit schaffen. Die ich ja genau damit abschaffen wollte.
Und das was durch die VCL an overhead entsteht kann man durch guten Code schon wieder ohne Probleme ausgleichen. Es kommt halt nur drauf an, dass man nicht irgendwelche super Performancefressenden Sachen macht.

Die meisten OpenGL-Programme laufen in Vollbild ab. Egal ob du einen Bildschirmschoner oder ein Spiel schreibst, du wirst keine Windowsbuttons o.ä. haben wollen. Also kannst du dir den ganzen Klickibunti-Kram sparen.

Ist ja schön, dass Delphi mir anbietet die VCL zu benutzen. Wenn ich Fenster-Programme z.b. Tools schreibe werde ich das auch tun aber wenn sich der RC sowieso über das ganze Fenster erstreckt und ich deshalb sichtbare Komponenten der VCL eh nicht benutzen kann, dann weiß ich nicht wozu ich die VCL überhaupt einbinden soll.

_________________
Selber Denken macht klug!

42

Ich glaube auch, dass die von Borland die VCL mittlerweile ziemlich gut optimiert haben. Da kann man kaum etwas verbessern. Und vor allem was spricht gegen eine OpenGL Componente? Okay Okay. Es ist EIN zusätzliches Handle und die Messages müssen erst dur 2 bis 3 Klassen durch bis sie denn endlich da sind. Aber dafür kann man zum Bleistift 2 oder 3 oder 4 OpenGL Ansichten gleichzeitig darstellen. OHNE das diese sich durch irgendwelche RC's in die quere kommen.
Aber wie gesagt. Ist jedem sein Ding. Wenn er sich mehr arbeit machen will. Bitte.