Bei mir ruckelt nix,
aber ich kann meinem Win-Hardware-Mauszeiger noch sehen...

@VCL: Ich stimme Delphic vollkommen zu. Ich arbeite gerade an einem Pojekt, wo 15 Units, viele von VCL mit drin sind... und das Ganze ist "nur" 466 KB groß... (+ ca. 600 Zeilen Source). Hat außnahmsweise nix mit OGL zu tun... *g*

Aber das entscheidende ist doch, wieso soll ich mir die Mühe und Unübersichtlichkeit machen, mit der API alles so kompliziert herzustellen, wenn mir doch dazu bereits über die VCL alles geboten ist.
Und ich arbeite in so manchem OGL-Projekt mit Buttons, Registry, VCL-Objs& Co. Und wieso soll ich dadrauf verzichten?!? Können mir die APIler einen - wirklichn gescheiten - Grund nennen, wieso sie mit der API arbeiten?

Egal - sollen sie sich quälen.. 8) Ich arbeite mit VCL... und Delphic wohl demnächst mit CLX ...
Wer darf die Proggs dann eigentlich portieren? Ups, immer der der fragt. Vergesst mich... ich habe so gut wie keine Ahnung von Kylix... leider ...

Waahak... ich werde schon wieder Off-Topic...

Also mal ehrlich: Sobald ich 'ne GUI benötige oder mehr als ein RC hab', werd' ich mich hüten auf die VCL zu verzichten und auf die API zurückzugreifen. Bin doch kein potentieller selbstmörder. Aber wenn ich sowieso nur ein Fenster brauche...

Zugegeben, bei einem Größeren Projekt würd' ich evtl. auch ein VCL-Fenster verwenden. Irgend wie zumindest. Aber wo Rendert man dann bei VCL? Im Application.OnIdle oder wo sonst? Und da fängt's an. Ich weiss nicht, was Borland VOR OnIdle und NACH OnIdle noch alles an blödsinn anstellt.

Wobei............, bei einem 1 - 2 GHz Proz dürfte das nun wirklich nicht mehr ins Gewicht fallen. Hmmm, manchmal häng' ich noch in den 386-66MHz Zeiten. Mein Chef jamert auch immer, wenn ich irgendwe versuche meine Progs zu optimieren, was bei den heuteigen Zeiten witzlos ist. Bin manchmal selber erstaunt, wie schnell sich die Schleife X nacher durcharbeitet. Hmmm, bin verwirrt....

Aber eines ist klar. Das mit dem API-Fenster macht man einmal und gut ist. Dannach braucht man es nicht wieder. Und wenn man z.B. auf das OnMinimize Reagieren will, muss man sich selbst bei der VCL eine eigene Message-Handling Funktion dafür implementieren. Eebenso wenn man den Bildschirmschoner und den Monitor-Standby-Modus verhindern will. Also macht es letztendlich wirklich keinen allzugroßen unterschied mehr.

Ist es nicht lustig? Wir haben uns auf OpenGL und Delphi geeinigt. Aber dann fangen wir einen Glaubneskrieg VCL <-> API an. Sonst könnte ja der Eindruck entstehen, dass wir uns langweilen und uns auch noch einig wären...

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

Hallo Leutz !
Erstmal Danke @ Lossy eX für die Hilfe und´s testen. Danke @ Blue Toby für den Performance-Check. Den Mauszeiger siehst Du noch, weil ich ihn zu Testzwecken nicht abgestellt habe (ShowCursor = True).

Also ... ich hab das ganze jetzt auf VCL übertragen, den QueryPerformance - Counter nach dem Tut von den NeoBrothers und siehe da ... es ruckelt auf einmal nicht mehr ... nur fragt mich jetzt bitte nicht, warum ... wenn ich die Zeitmessung wie im 3ten Beitrag von SchodMc mit einem QueryPerformance - Counter aufbaue, dann ruckelt es auch nicht mehr ... wahrscheinlich mag mein P3 keine Api´s oder mein Compiler hat seine Launen (Am Pentium-sicheren FDIV wirds ja wohl nicht liegen ...)

Gern geschehen. Dafür sind wir ja da.

Aber wegen dem Ruckeln schätze ich mal, dass es an der ungenauigkeit von GetTickCount (1ms) lag.
Es sah so aus, als ob sich eine ungenauigkeit (berechnung, messung, mondphase, ...) irgendwie hochgeschaukelt hätte.

Eigentlich müsste die FPS-Zahl ja bei einer komplett stilstehenden Szenen immer gleich bleiben - dem ist aber nicht so... sie verändert sich immer um wenige FPS(1-3), zumindest bei mir.
@Mondphase: Hm... vielleicht ein Komet, der die Gravitation verändert hat, die Grafikkarte hat schweben lassen, so eine winzige Ungenauigkeit.... oder aber dieser komische riesige Magnet neben dem Computer...

Oder eher die Tatsache, dass diverse Hintergrund-Tasks ablaufen, die Teilweise auch zu Windows selbst gehören und somit dein Programm nicht immer die gleiche "Tak-Zeit" zur verfügung steht...

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

Müssten die sich nicht auch vollkommen still halten?
Ansonsten mach ich im Taskmanger mal alle Prozesse aus... dieser "Leerlaufprozess" stört die Geschwindigkeit erheblich... Brauch ja immer 90 - 99 % CPU-Auslastung... *auf.opfer.wart*

Vielleicht sollte man erstmal die PSDK oder MSDN zu rate ziehen. Dann fallen die Erklärungen leichter

Unter NT hat GetTickCount ne Auflösungsbegrenzung von ~20ms. Kann man locker mittels GetSystemTimeAdjustment rausbekommen. Der MMTimer soll bei 1-2ms liegen. Der Windows Timer (SetTimer) liegt bei ~60ms. Und wer vor hat seine App mittels sleep um die überbleibenden ms abzubremsen dem sei gesagt das sleep minimal 10 ms bremsen kann. alles was darunter fällt liegt in der Blockzeit meist erheblich darüber.

müsste sie das? Rein theorethisch ja. Leider arbeit Windows und alle anderen Anwendungen im hintergrund ja auch. Also ich habe so etwas schon erlebt. Eigentlich ständig.

@JanBacke: Na ja. Man muss nicht gleich in den MSDN's suchen. Das ist mir zum Bleistift neu, dass die so eine komische Auflösung haben. 8O Das erklärt aber auch, warum ich das nicht verwende.
Und nach meiner Meinung sollte man ein Program nie ausbremsen. Außer es hat einen richtigen Grund (Extra Thread der alle 100ms irgendwo pollt,...). Bei Grafikanwendungen macht es ja generell kaum Sinn (mir fällt jedenfals keine sinnvolle Anwendung dafür ein)!

Es gibt auch nur ein M$ Developer Network.

Und schon haste was gelernt.

Dann erklär mal wie du eine konstante Framerate realisierst.
Wenn du denkst du kannst alles asyncron timen dann liegst du auf dem Holzweg.

Aus diesem Grund timet man komplizierte Dinge in eigenen Threads und nicht im Renderer - sort meistens übrigens für Übersichtlichkeit - hab ich selbst ausprobiert

Diese altklugen Direct3Dler!!!!
Phob hat Recht, die tauchen wirklich immer dann auf,
wenn man sie nicht braucht...

Ja gut hast recht das ist natürlich auch ne Möglichkeit aber du musst ja bei ner hohen Framerate so oder so den Thread resumen (sag jetzt nicht nein ) Und da die ganzen Eventgebenden Methoden aus Windows solche schönen Auflösungsprobleme haben hast du doch irgendwo nen HPC. Kontrollierst du jetzt be jedem Loopdurchlauf ob es Zeit für ein Resume ist oder legst du die App für die Restzeit schlafen?



Ich bin nicht altklug. Ich versuche nur objektiv zu sein.

Da sieht mans ja... nichmal Witze... gut, es war als eine Erkentniss "klug" und "prahlend" gemeint.
Und objektiv - dazu fällt mir jetzt auch nix ein.