FMX = Spiele-Engine in schlecht?

[Namenloser]

Also falls du OpenGL verwenden willst kann ich dir aus eigener Erfahrung nur folgenden Tipp geben: Geh davon aus, dass Context-Switches *extrem* langsam sind. Ein Context-Switch ist z.B. wenn du erst auf Bitmap A zeichnest und dann auf Bitmap B.

Bei mir ging es in einer Schleife immer abwechselnd, und ich hatte mir keine Mühe gemacht, das zu optimieren, weil ich davon ausgegangen war, die Treiber wären bestimmt intelligent genug, das zu optimieren – wenn die Hersteller schon Hacks in ihre Treiber einbauen, nur damit bestimmte Benchmarks schneller laufen, dann werden sie doch sowas nicht weglassen, wo doch selbst Festplatten schon NCQ haben, oder? Nun, es stellte sich raus, sie sind es nicht, und so war die „hardwarebeschleunigte“ Darstellung am Ende langsamer als das CPU-Rendering. Ich habe das zwar im Nachhinein noch etwas hinbiegen können, aber es war dann eher eine Frickellösung. Inzwischen habe ich angefangen, eine neue Engine basierend auf diesen Erfahrungen zu schreiben... die Entwicklung wird allerdings jetzt seit Monaten davon blockiert, dass ich eine Lösung bräuchte, Polygone in Dreiecke zu zerlegen, und momentan nicht wirklich die Zeit habe, mich damit genauer auseinanderzusetzen

Was ich sagen will: Berücksichtige die Einschränkungen von Grafikkarten schon ganz am Anfang im Entwurf, denn es ist schwierig, das im Nachhinein umzuändern.

[Popov]

Bei der Diskussion stellt sich die Frage auf was die Engine später können soll. Denn aus eigener Erfahrung weiß ich, dass für ein Game wie Space Invaders keine besondere Mühe machen muss. Früher vielleicht, aber die heutigen Rechner bügeln das alles aus. Die 1000 kleine Bitmaps kriege ich locker über die Canvas bewegt, ohne das es flackert.

Anders sieht es aus wenn man etwas anspruchsvolles machen will. Dann muss man alles was unnötig ist ausklammern. Deshalb die Frage - was soll die Engine später können.

[stahli]

Ich habe das gestern noch etwas umgebaut:

Das Formular wird jetzt im Mainthread fortlaufend aktualisiert - mehr passiert dort nicht mehr.

Die "Businesslogik" (die vorliegend nur die Positionen der "Panels" neu berechnet) ist jetzt in einem Objekt gekapselt und läuft in einem eigenen Thread.

Die VCL-Controls senden nur "Anweisungen" an die Buisinesslogik (BL), z.B. wird dort der Wert für Sleep geändert, der die Geschwindigkeit der BL regelt.

Insofern erfolgt die Neuzeichnung des Formulars ständig gleich schnell und die Geschwindigkeit der sichtbaren Verschiebungen hängt nur vom Ablauf der Neuberechnungen in der BL ab (also vom Sleep-Wert).

Wenn man Sleep runter regelt sieht man, wie fix die Änderungen erfolgen können. Es ist dabei schon ein Unterschied zwischen meinem privaten (schnellen) und meinem dienstlichen (langsamer) Rechner zu sehen.

Das Ganze ist noch nicht der Weisheit letzter Schluss, aber die Grundausrichtung finde ich nicht schlecht.

Letztlich will ich zu einer Lösung komplett ohne VCL (also ohne Bitmaps und Canvas) kommen. Offenbar führt die VCL zu verschiedenen Problemen wenn die Anzahl der Zeichenaktionen zu iel wird.

Z.B. habe ich einen kleinen "AniIndicator" gebaut, der sich fortlaufend neu zeichnet. Dabei zerhaut irgend etwas die Bitmaps. Offenbar verkraftet die VCL die Überbelastung nicht bzw. kommt dann mit der Formularsyncronisation nicht klar.

Der Grundgedanke der Komponentenzeichnung im Hintergrund und des späteren Zusammenbaus des Formulars mit den fertigen Bausteinen gefällt mir aber. Ich werde mich wohl mal mit OpenGL befassen (müssen).

Falls wer das Thema reizvoll findet und mitrödeln will... sehr gern! Einfach melden!

[Daniel]

Macht es Sinn, an dieser Stelle ein eigenes Thema zu eröffnen? Denn mit "Firemonkey" bzw. "Spiele-Engine" hat die aktuelle Entwicklung ja wenig zutun, wenn ich das richtig sehe.

[Memnarch]

Praktisch wäre auch vllt soetwas wie "SHared-COntext"(so würde ich das mal nennen)

wenn du nämlich sowas hast:

Form
--Frame
----Panel
----Panel
----Frame
--Frame
----Panel
------Panel
------Panel

Gbts eine ziemliche verschachtelung an "Bitmaps"(Setze hier ein, was immer du mal nutzen willst).

Für große Applikationen der Tod würde ich mal behaupten.
An der Stelle müsste man halt dann doch bestimmen können, das die Frames jeweils nen Zeichenkontext haben und die childs sich direkt dort draufzeichnen.
Kommt man halt nicht drumherum

[freimatz]

Zitat von Daniel:

Macht es Sinn, an dieser Stelle ein eigenes Thema zu eröffnen? Denn mit "Firemonkey" bzw. "Spiele-Engine" hat die aktuelle Entwicklung ja wenig zutun, wenn ich das richtig sehe.

Ja.