Jein. Theoretisch, so wird es im Bomberman-Tut erklärt, ist es richtig.
In der Praxis wird man aber bemerken, dass auch außerhalb des Renderns Zeit draufgeht. Zeit, die nicht im Timefactor berücksichtigt wird, sollte man da nur die Renderzeit messen.

Dies kann zu komischen Effekten führen. Daher einmal pro Frame Zeit messen und nicht zweimal (vor und nach Rendern). Also z.B. bei erneuten Aufruf vom Gameloop.

Damit bist du auf der sicheren Seite.

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Der richtige Ort für das TBM ist z.B. der Idlehandler. Also immer das was tatsächlich periodisch aufgerufen wird.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Arbeite derzeit mit C++ da gibt's sowas ja leider nicht direkt ..

Hab jetzt die Überprüfzeit mehr an die Schleife angepasst, funtzt jetzt sehr gut. Hab ein paarmal durchgetestet und sehr gute Ergebnisse bekommen - scheint zu funtzen

öh bei C++, so rückständig es auch sein mag, gibt es sowas bestimmt auch Wenn nicht, dann nimm einfach den ersten Punkt deines Gameloops.

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Hab ich funtzt jetzt super!

Wahrscheinlich gibts sowas schon, allerdings wären dann sicher irgendwelche zusätzlichen Librarys nötig und die sind wahrscheinlich plattform-abhängig - nichts für mich.

Wie wäre es mit SDL? Plattformunabhängige Library, die hier auch fleißig verwendet wird

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Ich benutze SDL in C++ und für 2D output OpenGL. Mir wär so ne Funktion nicht bekannt

In OpenGL-Anwendungen gibt es auch kein IDLE :p
(Ausnahmen ausgenommen)

Aber der Idlehandler existiert auch nur in VCL. Dort wird einfach geschaut ob irgendwelche Eingaben vom User kommen, wenn ja werden diese direkt verarbeitet, wenn nein wird der Idlehandler aufgerufen.

Also:


SDL hat sowas nicht, und wird auch mit Biblotheken (solange es keine Engines sind) es nicht hinzubekommen.
Du kannst dir sowas natürlich selber programmieren, bringt aber nichts, weil der Game-/Mainloop schon die richtige Stelle ist.

Aber SDL ist trotzallem die richtige Wahl, einfach weil man genug Kontrolle über alles hat und es plattformunabhängig ist.

höm? Also afaik hat SDL sowas. Und wenn nicht, kann man es sich ganz leicht selber basteln.

€dit: In diesem Fall zieht Teil 2: "Und wenn nicht, kann man es sich ganz leicht selber basteln."

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

In meiner Anwendung gibts onehin kein Idle weil die GameSchleife ja sooft wie möglich aufgerufen wird.

dann ist das dein "Idle-Handler" weil er dafür sorgt, dass dein Programm nicht faul ist, sondern immer was macht.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Wenn man es genau betrachtet ist es fast schon eine Grundsatzfrage. Immerhin gibt es ja theoretisch kein idle. Sobald die CPU oder sonstwas mal nichts zu tun hat, beginnt der IDLE-Prozess die restliche CPU-Zeit zu verbrauchen. Was macht der da eigentlich? Und warum macht er das? Damit die anderen Prozesse nicht auf dumme Gedanken kommen?

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Die CPU muss immer etwas tun, weil sobald kein nachfolgender Befehl (ASM) mehr da ist, bleibt sie stehen und nichts in der Welt kann sie wieder aufwecken (mal abgesehen von interrupts, aber da weiss ich nicht, ob die überhaupt durchkommen wenn die CPU steht).
Das heisst, wenn der Scheduler im moment keinen sinnvollen Prozess der CPU zuweisen kann, weist er einfach Idle zu, damit die CPU 'aufweckbar' bleibt. will heissen dass sie nach Ablauf der Zeitscheibe wieder vom BS eingenommen werden kann, um jetzt wieder zu kucken, welcher Prozess nun dran ist.
Es wäre nämlich bedeutent komplizierter, die CPU im BS verweilen zu lassen, wenn kein Prozess ansteht, anstatt einfach einen Dummyprozess mit in die Prozessliste einzutragen.

Aus dem selben Grund bauen manche Spiele, die auch netztwerkfähig sind selbst bei singleplayer eine Client-Server Architektur auf, weil man dann keine zweite Schnittsrtelle zwischen Oberfläche und Spielkern benötigt.

_________________
Manchmal sehen Dinge, die wie Dinge aussehen wollen, mehr wie Dinge aus, als Dinge.
<Esmerelda Wetterwax>
Es kann vorkommen, dass die Nachkommen trotz Abkommen mit ihrem Einkommen nicht auskommen und umkommen.