FMX = Spiele-Engine in schlecht?

[Phoenix]

Zitat von stahli:

Kann jemand beide Framework-Konzepte (FMX und SpieleEngines) grundsätzlich vergleichen und Parallelen und Unterschiede erklären?

Spiele-Frameworks arbeiten grundsätzlich sehr Linear:

* (Teil-)Eingaben verarbeiten und in die interne Datenrepräsentation integrieren
* Diese am UI darstellen (Rendering)
* Wiederholen

Um möglichst hohe Frameraten zu erzielen, passiert Schritt Zwei möglichst häufig, und Schritt Eins wird nicht zwangsläufig immer gemacht. Auch werden bei Schritt 1 oft Teileingaben (und damit unscharfe / unvalidierte) Inputs in Kauf genommen, damit das Spiel möglichst schnell auf (vorhergesehene) Eingaben reagieren kann. Das muss nicht unbedingt passen, aber das das Spiel so schnell ist kann es hinterher nach 3-4 Runden die korrekte Eingabe annehmen und ggf. den Ablauf der letzten drei/vier Frames korrigieren.

Da die Performance der Darstellung sehr stark abhängig von der Hardware des Rechners (sowie den Grafikeinstellungen) und damit sehr individuell ist, wird die Eingabe mit der real abgelaufenen Zeit normalisiert. Sonst hast Du auf modernster Hardware ein unspielbares Frogger (damals wurde das auch noch nicht gemacht).

Konkret heisst das, Spiele haben in aller Regel keine Message-Loop im Sinne von Windows-Anwendungen (wie übrigens iOS auch nicht), sondern laufen kontinuierlich ab.

Zudem konzentrieren sich viele Spiele-Engines darauf, das Rendering möglichst hochperformant hinzubekommen und reduzieren das ganze 3D-Zeug auf Matrizenoperationen, die man dann entsprechend durch den Input antriggert.

Klar lässt sich das eine grundsätzlich irgendwie auf das andere Mappen, aber eine Business-Anwendung hat grundlegend andere Anforderungen als ein Spiel, und dem tragen die unterschiedlichen Frameworks und Herangehensweisen eben (mehr oder weniger) Rechnung.

[Medium]

Jetzt lässt sich natürlich darüber streiten, ob eine Game-Main-Loop einer Messageloop nicht doch irgendwie arg ähnlich ist

MessageLoop: (Pseudo)

Code:

while true do
begin
  PeekMessage();
  case Message of
    WM_FOO: ...
    WM_KEYBDEVENT: VerteileAnAktivesControl;
    WM_PAINT: ZeichneNötigesNeu;
    ...
    WM_CLOSE: Terminate;
   end;
end;

Gameloop: (auch Pseudo)

Code:

while true do
begin
  GetAsyncKeystateUndInterpretiereInputState;
  UpdateSpiellogik;
  Render;
  WennExitStateDannExit;
end;

Bei beiden Systemen verbirgt sich der ganze restliche Rattenschwanz hinter, finde ich, strukturell doch arg ähnlichen Abläufen. Nur werden bei Spielen spätestens ab interner Verarbeitung keine Windows-Messages mehr benutzt, sondern es ist entweder eine Statemaschine ähnlich gebaut, oder man hat ein eigenes, oft THread-Basiertes Signaling-System. Am Ende aber Jacke wie Hose, es ist sicherlich nicht die WinAPI die FMX so bremst

PS: Und das Spiele "halbgare" Inputs irgendwie anders handhaben wäre mir auch unbekannt. Das trifft eher auf Netzverkehr zu, wo ein Client Vorhersagen über die eventuelle Bewegung anderer Spieleravatare trifft, und nach einem Updatesyklus vom gemeinsamen Server notfalls nachsynchronisiert. Gerade bei FPS Spielen ist eine ultra schnelle und korrekte Eingabeverarbeitung doch das A und O.

[blackfin]

Zitat:

...aber eine Business-Anwendung hat grundlegend andere Anforderungen als ein Spiel...

Was das Data Modelling angeht ganz sicher, aber es geht hier ja hauptsächlich um die Darstellung von GUI-Controls.
Es schliesst sich ja nicht aus, das Data Modelling mit einem "Business-Framework" zu gestalten, für die GUI jedoch dann 3D Technik zu verwenden.
Auf kurz oder lang wird das denke ich sogar der Standard werden. GUIs für Desktopanwendungen verschieben sich sowieso immer mehr in die Richtung "HTML-Technik", der nächste Schritt wird dann denke ich etwas in der Art wie WebGL-Technik für GUI-Darstellungen sein. (nur meine bescheidene Meinung).
Wenn ich mir sowas wie "Node-Webkit" ansehe, gehen mir echt die Augen auf. Und das ist erst der Anfang.