Cross-Platform Game Loop

[milos]

Hi,

Meine kleine Spiele Engine hat momentan noch so einen loop mit Application.ProcessMessages:

Delphi-Quellcode:

begin
  while Running do
  begin
    Input;
    Update;
    Draw;
    Application.ProcessMessages;
  end;
end;

Mir ist bewusst dass das so nicht gut ist, jedoch habe ich es bisher so gemacht weil ich mich nur mit den form messages in windoof auskenne und nicht weiss wie ich sonst eine Schleife kriege ohne alle anderen Messages zu blockieren. Sollte man das lieber in einen weiteren Thread auslegen und dann von dort aus z.b. das Canvas neu zeichnen? Wie bekommt man das am besten hin ohne das es mal knallt?

Freundliche Grüsse

[Sir Rufo]

Gleiche Frage => Gleiche Antwort
http://www.delphipraxis.net/1243108-post2.html

Ok, der Link läuft ins Leere (auch wenn man über die Homepage dahin navigiert) - aktuell muss man sich das SmartMobileStudio installieren um an die Demos zu kommen. Eine Registrierung oder ein Trial Key ist für die reine Installation nicht erforderlich.

[milos]

Naja die Frage ist nicht die selbe. Hier frage ich wie ich die vorhandene Game Loop verbessere die auch auf Vorschläge im von dir verlinkten Thread basiert. Ausserdem scheint der Link tot zu sein... Und zwar möchte ich das anders machen, sodass während des "Loops" auch alle Form Events feuern ohne das ich unsichere aufrufe wie Application.ProcessMessages machen muss und das auf Windows UND iOS/Android...

Freundliche Grüsse

[mkinzler]

Ich habe den Link im anderen Thread an die Änderung der Homepage angepasst.

[Sir Rufo]

Dann mach es doch so wie es da steht ... Für die Taktung nimmst du einen Timer und los geht es

[milos]

Zitat von Sir Rufo:

Dann mach es doch so wie es da steht ... Für die Taktung nimmst du einen Timer und los geht es

Du willst mir doch nicht ernsthaft TTimer dafür vorschlagen? Soweit ich weiss ist der von Natur aus ungenau und das etwa zu 15ms. Mal mehr mal weniger und schon verabschiedet sich das flüssige Bild... Ich dachte eher an Window-Messages oder so ähnlich... Da ist mir gerade TApplication.OnIdle in den Sinn gekommen. Vielleicht geht es ja damit wie ich es mir vorstelle.

Freundliche Grüsse

[Sir Rufo]

Schau dir das Konzept einmal genau an, dann siehst du dass diese "Ungenauigkeit" überhaupt nicht interessiert. Den Rest erledigt das "träge" Auge des Betrachters

Und egal wie genau dein Timer ist es bleibt immer eine Zeitspanne x zwischen Signalisierung durch den Timer und der Darstellung. Dieses x ist abhängig von der allgemeinen Systemperformance, der aktuellen Systemauslastung, ...

Meinst du wirklich, das da ein 15ms Delta ins Gewicht fällt? Das ist im Übrigen eine Zeitspanne, die das menschliche Auge nicht wahrnehmen kann

[BUG]

Zitat von Sir Rufo:

Meinst du wirklich, das da ein 15ms Delta ins Gewicht fällt?

Auf jeden Fall. 15ms entsprechen ungefähr 60fps, was nach heutigen Standard die Mindestanforderung an ein Spiel auf dem PC ist.

Zitat von Sir Rufo:

Das ist im Übrigen eine Zeitspanne, die das menschliche Auge nicht wahrnehmen kann

Das ist ein Gerücht. Das Auge ist schneller, nur das Gehirn ist lahm. Wer schon mal 60 vs. 120fps Vergleichmaterial gesehen hat, merkt dass doch mehr Information rüber kommen ... vor allem bei schnellen Bewegungen und Drehungen.

Zitat von milos:

Ich dachte eher an Window-Messages oder so ähnlich...

Soweit ich weiß ist TTimer ein Wrapper um die Timer-Messages.

Ich würde auch auf die Messages verzichten und eine hochauflösende Uhr in einer Schleife (bzw. in onIdle) verwenden. Wenn du dann merkst, das noch viel Zeit über ist, kannst du ja immer noch schlafen. Alternativ könnte man sich Waitable Timer Objects angucken, die sehen ziemlich gut aus. SDL2 scheint QueryPerformanceCounter zu benutzen.

Zitat von Sir Rufo:

Dieses x ist abhängig von der allgemeinen Systemperformance, der aktuellen Systemauslastung, ...

Wenn da im Hintergrund noch etwas anderes aufwendiges läuft, sollte man vielleicht kein Spiel starten.


Für konventionelle Anwendungen würde ich SirRufo zustimmen, aber Multimedia ist doch etwas anderes.

[milos]

Danke Bug. Habe nun ein wenig mit OnIdle gespielt, das scheint mir ein Vernünftiger Weg zu sein.

Danke für den Link der Waitable Timer Object, das sieht sehr interessant aus und könnte sich als Nützlich erweisen.

Und ja, den Unterschied zwischen 30 - 60 - 120 (- 144 [nicht mehr so stark von 120 zu unterscheiden aber doch ein wenig]) sieht man mit einem geübten Auge sofort und wenn man sich 144hz gewöhnt ist (so wie ich) tun 30 FPS schon fast weh in den Augen. 60 wäre ertragbar aber nicht mit zusätzlichen TTimer rucklern, ist nämlich fast genau so schlimm x)

Freundliche Grüsse

[HolgerX]

Hmm..

Ich hab zwar keine Ahrnung von Spielprogrammierung, aber..

Delphi-Quellcode:

begin
  while Running do
  begin
    Input;
    Update;
    Draw;
    Application.ProcessMessages;
  end;
end;

Wenn die Funktionen hier zum Teil von SubThreads ausgeführt werden, kann sich der MainThread alleine um ProcessMessages und Draw kümmern..

Jeder Thread 'liest' den Input und 'berechnet' das Update eigenständig.
Da hier nur das 'lesen' z.B. per CriticalSection geschützt werden muss, ist auch kein Thread-Problem zu erwarten.

Der MainThread rüft dann zyklisch (z.B. alle x ms) das Draw der SubThreads auf und lässt dort das reine Zeichnen laufen, welche (interner Zugriff ebenfalls über CS geschützt) die vorab bereits berechneten Position des Objektes im Thread des MainThread zeichnet.