FMX = Spiele-Engine in schlecht?

[stahli]

Ich war und bin begeistert von der Idee, von der VCL los zu kommen.
FMX verspricht ja viel, bringt aber real viele Probleme mit sich.

Neben mangelhaften Umsetzungen im Detail und dem unausgegorenen Style-Konzept ist die FMX-GUI sehr langsam.

Klar, da muss deutlich mehr berechnet werden als bei der VCL. Es ist auch verständlich, dass beim Umpositionieren von Controls die Umgebung neu (und somit mehrfach) gezeichnet werden muss.
Wenn man aber mal so 3D-Spiele sieht (was absolutes Fremdgebiet für mich ist), dann erkennt man, was wirklich möglich ist.

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

Könnte man nicht einfach eine SpieleEngine nehmen und statt Monstern und Drachen einfach Schalter und Edits als Figuren/Objekte darstellen?

Wenn im WOW ganze Welten flüssig und Live dargestellt werden können (sogar online), warum ist FMX dann so langsam und störrig?
Sollten sich nicht entsprechend auch Fachanwendungen in der Form von Spielen entwickeln lassen? Könnte man nicht eine Fachanwendung als grafisch anspruchsloses Spiel ansehen?
Gibt es dafür zwingende Gründe?

Die BL-Schicht und Datenverwaltung ist ja ohnehin gleich oder kann gleich sein.
Der Unterschied liegt in der Darstellung und Handling der GUI.

Ein Unterschied ist sicher, dass in Spielen Figuren kaum mit der Maus focusiert werden - oder?
Insofern sind dafür keine oder andere Handles notwendig?


Ich weiß, das ist eine recht naive Fragestellung aber vielleicht kann man sich ja hier mal thematisch ein wenig austoben...

[CHackbart]

Nun das Problem liegt nicht in dem Konzept, sondern in der gnadenlos vermurxten Umsetzung. Ich würde für die Umsetzung eins Spiels auf OpenGL setzen. In den letzten Wochen habe ich mich wieder damit herumgeschlagen, da ich eigentlich in den letzten 10 Jahren nur mit DirectX gearbeitet habe. Opengl ist echt klasse und funktioniert auch mit Firemonkey. Da wir in den letzten Jahren quasi so etwas wie die VCL für D3D umgesetzt haben und das ganze Framework recht abstrakt ist hat mich die Portierung weniger als eine Woche gekostet. Ich habe dabei 2 Varianten entwickelt, die erste war in reinem Firemonkey Code und die zweite Variante reines Opengl. Die CPU Last in ersterem beträgt 40% und bei OpenGl knapp 1%.

[stahli]

Zitat:

Zitat von CHackbart (Beitrag 1216419)

Da wir in den letzten Jahren quasi so etwas wie die VCL für D3D umgesetzt haben und das ganze Framework recht abstrakt ist hat mich die Portierung weniger als eine Woche gekostet. Ich habe dabei 2 Varianten entwickelt, die erste war in reinem Firemonkey Code und die zweite Variante reines Opengl. Die CPU Last in ersterem beträgt 40% und bei OpenGl knapp 1%.

Kann man da mal etwas sehen (DemoExe, Videos, Screenshots, Quelltext)?

[CHackbart]

Quellcode wird schwer, aber ein Video der D3D Version gibt's u.a. hier: http://m.youtube.com/watch?v=LJDhQWDYeRc

Wenn ich am PC bin, kann ich ja mal nen Screenshot bzw. Testbuild hochladen, ansonsten kann man mit der OEM Version von der Software spielen. Die gibt es u.a. Bei Technotrend, Terratec, TBS, Dvbsky. Wer keine DVB Gerät hat, kann zumindest die Videowiedergabe testen :)

[blackfin]

Zitat:

Könnte man nicht einfach eine SpieleEngine nehmen und statt Monstern und Drachen einfach Schalter und Edits als Figuren/Objekte darstellen?

Wenn im WOW ganze Welten flüssig und Live dargestellt werden können (sogar online), warum ist FMX dann so langsam und störrig?
Sollten sich nicht entsprechend auch Fachanwendungen in der Form von Spielen entwickeln lassen? Könnte man nicht eine Fachanwendung als grafisch anspruchsloses Spiel ansehen?

Das kann man sehr wohl. Allerdings ist die Programmierung einer allumfassenden GUI in OpenGL nicht gerade trivial, da man eben jedes Control erstmal mit allen Funktionen selbst bauen muss, auch die Events selbst implementieren muss etc.

An sich hast du jedoch vllkommen recht: Man kann eine Fachanwendung auch als "abgespecktes" Spiel sehen und alles in D3 (OpenGL / Direct3D) bauen.
Früher haben die meisten wohl davon abgesehen, da man dafür eine leistungsfähige Grafikkarte gebraucht hat und Software-Renderer durch die Bank performancetechnisch unbrauchbar waren.
Teilweise trifft das auch heute noch zu, allerdings haben selbst neuere Onboard-Karten inzwischen eine für simple GUI-Darstellung brauchbare OpenGL-Performance.
Der Performance-Gewinn durch OpenGL ist immens, ich habe mal testweise eine Art "Fenster-Manager" mit GLScene geschrieben, der konnte ca. 800 Fenster mit GUI-Controls tiefengestaffelt bei 60fps auf meiner Geforce 7 rendern.
Wobei das eben mit "nur" GLScene war...nativ ist da noch einiges mehr rauszuholen.

Zitat:

Ein Unterschied ist sicher, dass in Spielen Figuren kaum mit der Maus focusiert werden - oder?

Doch klar geht das, entweder über die veraltete GLUT oder eben schneller durch Raycasting etc. Damit kann man jedes Polygon unter der Maus schnell ermitteln.

[Namenloser]

Ich glaube Andorra2D hatte auch rudimentäre GUI-Funktionen...

[cookie22]

Zitat:

Zitat von stahli (Beitrag 1216415)

Ein Unterschied ist sicher, dass in Spielen Figuren kaum mit der Maus focusiert werden - oder?
Insofern sind dafür keine oder andere Handles notwendig?

In Spielen, wie WoW werden die Spielfiguren ständig mit der Maus fokusiert. Das wird im allgemeinen über Hit-Boxen realisiert.

Das Problem an FMX ist einfach die lieblose Umsetzung von Emba. Da wird immer neuer Senf zu gepackt, anstatt erst mal das ganze stabil zum laufen zu bringen. Daran wird sich auch nichts ändern, darum kommt FMX für mich auch nicht in frage.

[Phoenix]

Zitat:

Zitat von stahli (Beitrag 1216415)

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.