|
AW: FMX = Spiele-Engine in schlecht?
Es ist in der Tat immer schwierig, da einen gescheiten Tradeoff zu finden. Ich glaube in der Firefox-Rendering-Engine (Gecko) steckt auch so ein Mechanismus, Layers genannt (zumindest nehme ich an, dass es sowas ist). Mozilla hat da jahrelang dran entwickelt (wird u.a. für die hardwarebeschleunigte Darstellung benötigt), und die haben hunderte Mitarbeiter.
Ich denke, man sollte zumindest nicht jedes einzelne Control cachen. Mal angenommen, man hat z.B. zwei Button in einem Panel, das selber wieder zusammen mit anderen Controls in einem Panel liegt. Dann sollte man vielleicht nicht die Buttons selbst als Bitmap cachen, sondern nur das Panel, auf dem sie liegen, oder vielleicht sogar nur das Panel, auf dem das Panel liegt (oder nur die Buttons cachen aber dafür keins von den Panels). Dafür müsste man sich irgendwelche Heuristiken überlegen. Z.B. wie viele Untercontrols es gibt, oder man misst die Zeit, die das Zeichnen braucht, und entscheidet basierend darauf, ob es Sinn macht, das Ergebnis zu cachen. |
AW: FMX = Spiele-Engine in schlecht?
Out of Memory hatte ich bei dem Versuch von 10000 "Panels". Näher eingerenzt hatte ich das in der Nacht nicht mehr.
Ich weiß nicht, ob Bitmaps und die verwendeten Kopierfunktionen das Maß aller Dinge sind. Grundsätzlich kann ich mir aber nicht vorstellen, dass ein Kopieren von Speicherinhalten so sehr langsam sein muss. Bestimmt kann man hier auf schnelle Lösungen umstellen. Wenn man sich das ständige Neuzeichnen von gestylten Controls vorstellt würde ich schon eher mit erhöhtem Zeitbedarf rechnen. Gemäß meiner Überlegung könnte man den bunten Button mit Schörkeln und Lichteffekten im Puffer lassen und lediglich den Text neu schreiben, wenn ein neues Caption zugewiesen wird. Erst wenn der Button gedrückt wird muss auch sein Aussehen (nämlich gedrückt) neu berechnet werden. Ob man das Konzept ohne OpenGL oder ähnliches brauchbar realisieren kann, weiß ich immer noch nicht. Der Knackpunkt ist wohl, dass selbst das Kopieren des berechneten Gesamtbildes auf die Formularfläche mit dem Mainthread syncronisiert werden muss - und das verhindert dann eben dass die Darstellung von Formularänderungen unabhängig vom Mainthread erfolgen kann (eben z.B. auch nicht während dem schrittweisen Debuggen einer Anwendung). Evtl. könnte man - mal so als Überlegung - die gesamte Businesslogik in einen eigenen Thread auslagern. Dann würde der Mainthread sich allein um die Formularaktualisierung kümmern und die Mausereignisse an die Businesslogik geben. Die Businesslogik (die man ja ohnehin von der GUI trennen sollte) könnte in einem eigenen Thread gestartet werden (TMyBusinesslogic.Start). Das sind natürlich alles recht unscharfe Überlegungen aber das Thema würde ich gern noch diskutieren und entsprechend lernen... @Namenloser Das stimmt. Die Verwendung gleicher "Bitmapmuster" für gleiche Controls gleicher Größe und gleichen Statuses habe ich auch schon als zweckmäßig erachtet. Als einzelner Programmierer in 3 Stunden habe ich dann ja schon mal ein bissl was erreicht. Wenn meine Firma 100 Angestellte hätte wäre ich aber auch nicht unglücklich ;-) |
AW: FMX = Spiele-Engine in schlecht?
Ich hab den Thread jetzt weiter gelesen (bei meiner ersten Antwort habe ich nur deinen letzten Post beachtet).
Es macht sich manchmal bezahlt einen langsamen Rechner zu haben, denn dann sieht man einiges manchmal in Zeitluppe, was andere gar nicht sehen. So bin ich wohl einer der wenigen Glücklichen auf der Welt die tatsächlich beobachten konnten wie ein Button gezeichnet (zumindest den Anfang). Es begann oben rechts und zeichnete dann Pixel für Pixel das erste Rechteck entgegen dem Uhrzeigersinn. Aber das ist es nicht auf was ich hinaus wollte (auch wenn es interessant ist), denn was ich auch beobachten konnte ist, dass jedes Objekt einen Clipping Bereich hat. Ist ein Button nicht verdeckt, wird er komplett gezeichnet. Das dauert am längsten. Ist er verdeckt, wird er nicht gezeichnet. Ist er zum Teil verdeckt, wird nur das sichtbare Teil gezeichnet. Windows arbeitet in der Hinsicht also effizient. Selbst ein Fenster mit Buttons wird zuerst so gezeichnet, dass die Bereiche des Fensters auf denen sich die Buttons befinden, nicht gezeichnet werden. Windows zeichnet das Fenster dan sozusagen mit Löchern. Die Löcher werden erst dann gefüllt, wenn die Buttons gezeichnet werden. Somit ist es nicht verkehrt bei jedem Objekt zuerst den Bereich zu berechnen der sichtbar ist und gezeichnet werden muss (bzw. den schon im Speicher zu haben). Denn warum soll man, wenn man z. B. ein Fenster wie der Notepad.exe es hat, zuerst das leere Fenster zeichnen? Das wird später ja sowieso überzeichnet. Es reicht ha nur den Rahmen und Titelleiste zu zeichnen. Der Rest wird später nachgeliefert. Ich denke mir so kann man viel Zeit und Rechenleistung sparen. |
AW: FMX = Spiele-Engine in schlecht?
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. |
AW: FMX = Spiele-Engine in schlecht?
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. |
AW: FMX = Spiele-Engine in schlecht?
Das Problem Out-Of-Memory dürfte von den offenen Handles herrühren. Ich hatte so etwas ähnliches auch schon gemacht. Da habe ich dann genau aus dem Grund nicht für jedes Element ein Handle (z.B. TBitmap, TCanvas, ...) geöffnet.
Ich habe allerdings die OS-Funktionen wie Mapping von Views usw. mit benutzt um gedrehte Inhalte usw. direkt zu zeichnen usw. So liefen auch mehrere tausend gut. |
AW: FMX = Spiele-Engine in schlecht?
Also mein Wunsch:
- Optik wie VCL Style oder besser FMX Style incl. Effekten und Schatten ist völlig ausreichend. - Dinge wie Lichteffekte und 3D wären Schmankerl, müssten aber nicht sein. - Der Anwender bedient das Programm und auch bei aufwendigen Berechnungen werden Fortschritte eines AniIndicators (drehende Sterne oder Punkte), einer Progressbar oder eines Gitters bei Datensatzwechseln flüssig, verzögerungsfrei und flimmerfrei dargestellt. - Ich will also auf ein Application.Processmessages verzichten. - Der AniIndikator soll laufend vor sich hin wackeln wie ein Baum im Spiel, egal was ich in der Anwendung tue. Das ist eigentlich das, was man m.E. ohne negative Vorerfahrungen mit der VCL auch erwarten würde. (Wobei ich natürlich einsehe, dass vor 20 Jahren noch ein anderer Stand der Technik vorherrschte.) - Wenn ich in meiner Anwendung in Zeile 500.000 schreibe: "Panel1.Left := Panel1.Left + 1" dann will ich die Änderung im Formular auch sehen, wenn ich diese Zeile mit F8 ausführe. Dazu darf die Formularänderung nicht im gleichen Thread laufen wie der Rest der Anwendung. - Die Funktionalität sollte möglichst auf allen Windows-Versionen ab XP und mit allen möglichen Grafik-Hardwaren gegeben sein. - Funktionalität auf MAC und mobilen Plattformen wäre natürlich nicht falsch. Das alles habe ich mir auf Grund der schönen bunten Emba-Videos von FMX erwartet. Im Nachhinein weiß ich, dass ich da ... ma sagen ... äh ... einem Missverständnis auf den Leim gegangen bin. Nichts desto trotz halte ich die Zielstellung für legitim und im Grunde wohl auch realisierbar. Ob das Ganze hardwarebeschleunigt laufen muss, glaube ich noch nicht mal. So eine Formularanwendung ist ja doch ziemlich einfach gestrickt, auch wenn man Transparenz, ein paar Styles und Skins verwendet. Es kommt (denke ich) mehr auf eine sinnvolle Optimierung an und auf eine Formularaktualisierung in einem eigenen Thread. Ich denke, das ist der Knackpunkt. Wer schon mal CodesiteLogging genutzt hat - das ist ein schönes Beispiel. Die Logs werden schnell an eine unabhängige Stelle (LogManager, sage ich mal) geschickt und die Anwendung kann normal weiter laufen. Im LogManager werden die Infos dann aufbereitet und nach und nach ausgegeben. So ähnlich sollte die Formularaktualisierung laufen. Die Controlabbilder werden nach und nach auf die Formularfläche kopiert und die entsprechenden Regionen vermerkt. Anschließend werden Maus- und Tastaturereignisse geprüft und an die Controls weiter gegeben, die sich unter der Maus befinden oder den Focus haben... Das hätte ich gern und das würde m.E. völlig neue Möglichkeiten und Anwendungen ergeben. FMX hat ja leider auf ganzer Linie mehr als enttäuscht. Ich selbst will eigentlich erst mal nur etwas auf dem Gebiet lernen um etwas Hintergrundwissen zu sammeln. @jaenicke Genau. Bitmap und Canvas habe ich jetzt nur der Einfachheit halber auf die Schnelle verwendet. Ich denke, dass das auch schlanker gehen müsste. Gedrehte Controls und Zuweisung von Schatten oder Effekten wäre natürlich auch super. Insofern wären schon komplexere Zeichenfunktionen wünschenswert. Aber lösbar sollte das sein (wenn auch nicht unbedingt für mich, so ohne Vorkenntnisse). Kann man mal was von Deinem Geraffel sehen? @all Die Frage auch an alle anderen: Wer irgendwelche Teilergebnisse, Exen, Bilder, Videos oder Kenntnisse zu diesem Thema vorzeigen kann ... ich würde sofort alles begierig aufsaugen! :stupid: |
AW: FMX = Spiele-Engine in schlecht?
Liste der Anhänge anzeigen (Anzahl: 1)
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! |
AW: FMX = Spiele-Engine in schlecht?
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.
|
AW: FMX = Spiele-Engine in schlecht?
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 :| |
AW: FMX = Spiele-Engine in schlecht?
Zitat:
Zitat:
Seit Vista übernimmt das Rendern (inkl. Überlappungen usw.) die Grafikkarte statt der CPU, sofern das möglich und Aero aktiv ist. |
AW: FMX = Spiele-Engine in schlecht?
Liste der Anhänge anzeigen (Anzahl: 1)
@Daniel
Ich würde gern noch hier bleiben, weil ich noch bei der Idee der gepufferten Bitmaps bleiben will. Wenn Du das verschieben willst ist das natürlich auch ok (in meinen neuen OpenGL-Thread passt es aber auch nicht besser). @all Anbei nochmal eine neue Testversion. Die GUI wird im Mainthread gezeichnet. Die Businesslogik läuft in einem eigenen Thread. Dort erfolgen die Positionsänderungen usw. Die Geschwindigkeit des Threads kann über den Sleepwert geändert werden. Eine echte Anwendung würde man natürlich ohne Sleep laufen lassen. Da würden ja normalerweise keine Controls verschoben. Wenn man die VCL-Schleife startet, dann hängt die Anwendung natürlich so lange. Die Test-Schleife vom unteren Button läuft im Business-Thread. Die Geschwindigkeit ist vom Sleepwert abhängig. Der Zahlenwert in den Controls zeigt den Schleifenzähler an. Die Controls zeichnen sich jetzt bei jedem Frame neu. Es gibt also keine Bitmaps zum puffern mehr. Das Ganze läuft trotzdem sehr schnell (bei der einfachen Grafik). Bis 10.000 Panels läuft das flüssig, danach wird es hakelig. Der Flaschenhals bei FMX dürfte also wohl nicht mit Bitmappuffern zu verbessern sein, wie ich ursprünglich meinte. Was aber wichtig ist, ist bei Controländerungen nicht rings herum ständige Neuzeichnungen auszulösen. Ich habe drei neue Controls gebastelt: AniIndicator, Progressbar, Edit. Die sind natürlich nur mal schnell angetestet. :-) Der AniIndicator läuft ständig vor sich hin. Die Geschwindigkeit ist einstellbar. Die Progressbar kann mit der Maus eingestellt werden und läuft dann automatisch auf null zurück. Beide sind verbunden (ist natürlich hier kein echtes Binding ;-)) Die Edits können einen Fokus erhalten und Zeichen annehmen (sonst geht da noch nix - also kein Cursor, kein Select, kein Löschen usw!). Um das weiter auszubauen wäre natürlich einige Arbeit notwendig. Die VCL-Controls sind natürlich hier nur für Testzwecke. Real könnte man auf VCL-Controls verzichten (wenn es ausreichend Alternativen gäbe). Warum nun das Ganze? So richtig habe ich keine Ahnung! ;-) Die VCL und FMX will ich nicht mehr gern verwenden. Die sind einfach nicht angenehm, stabil und flüssig zu händeln. Die Demo gefällt mir vom Handling schon ganz gut. Man hat eine flüssige GUI, die unabhängig vom Businessthread läuft, der in einem Objekt gekapselt ist. Die Windowsereignisse spielen dann eigentlich keine Rolle mehr, außer dass das Formular diese abfängt und an die GUI übergibt. Die GUI-Controls können direkt in die Businesslogik gebunden werden. Ich habe jetzt m.E. einen Ablauf, wie er auch mit OpenGL o.ä. funktionieren würde - natürlich auf ganz anderem Niveau. ;-) Wenn ich das Projekt schrittweise debugge, dann werden Änderungen natürlich wie bei der VCL auch nicht sichtbar, da die Formularaktualisierung im Mainthread läuft. Evtl. könnte man den Formularcanvas einer fremden Anwendung kapern, so dass man Formularaktualisierungen so beim Debuggen erkennen könnte. PS: Jetzt gehe ich erst mal ins´ Bettchen - vielleicht bin ich morgen schon schlauer. :stupid: |
AW: FMX = Spiele-Engine in schlecht?
Zitat:
|
AW: FMX = Spiele-Engine in schlecht?
Vollkommen wegkommen von den Windows Events wirst du nicht, wenn du deine Zeichenvorgänge korrekt umsetzen willst. Dazu musst du nunmal zwangsweise auf die WM_PAINT reagieren (wenn du nicht auf gut Glück periodisch alles neu Zeichnen willst).
Dass alle Windows Messages in einem einzigen Message Loop (bei Delphi im "Main-Thread") empfangen werden, kann man als Vor- oder auch als Nachteil sehen. Klar blockiert eine Schleife von 1..10000 dann natürlich erstmal den Empfang weiterer Nachrichten, weshalb dann auch die GUI nicht mehr aktualisiert wird, oder Button Click Ereignisse nicht sofort umgesetzt werden. Auf der anderen Seite kannst du dieses Verhalten recht einfach beeinflussen, indem du (wie von jaenicke schon erwähnt) ein Paar
Delphi-Quellcode:
Aufrufe einstreust (oder System-nah direkt
Application.ProcessMessages
 PeekMessage, TranslateMessage, DispatchMessage).Zu den Neuzeichnungen .. nehmen wir an ich habe folgende Hierachie:
Gehe ich hier mal generell von der Möglichkeit aus, dass eine Komponente semitransparent ist, so muss in jedem Falle alles was darunter liegt neu gezeichnet werden. Im "schlimmsten" Falle würde eine Änderung von Button3 also ebenfalls das Panel und das Formular neu zeichnen. Analog dazu muss natürlich bei einer Änderung des Panels sowohl das Formular (falls das Panel z.b. semintransparent ist oder einen AlphaChannel hat), als auch die darüberliegenden Buttons 3 und 4 (in jedem Falle; da diese ggfls. durch das Neuzeichnen des Panels teilweise überdeckt werden) neu gezeichnet werden. Man sieht also recht schnell, dass diese Zeichenlogik keine triviale Sache ist und dass man in gewissen Fällen halt einfach nicht um ein Neuzeichnen herumkommt. Optimieren kann man hier z.b. indem man jedem Control ein Flag zuweist, welches angibt, ob die Komponente semitransparent ist oder nicht. Dann spart man sich ein paar Zeichenoperationen von darunterliegenden Controls (macht die VCL soweit ich gesehen habe auch so). Falls das Zeichnen ansich wirklich ein Flaschenhals sein sollte, kann man natürlich auch das "Bitmap Caching" (mindestens GDI+, weil hier zwingend Transparenz / AlphaChannel benötigt wird) verwenden. Ich wage allerdings mal zu behaupten, dass die Zeichenoperationen in der Regel schneller sind, als die ganze Cache Geschichte. Auch wichtig ist, dass man exzessiven Gebrauch von Clipping macht und somit wirklich immer nur die Teile aktualisiert, die sich wirklich geändert haben und nicht wild drauf los das komplette Control. Im Hintergrund gehe ich zwar davon aus, dass sich ein Control IMMER komplett neu zeichnet, aber die GDI (oder zumindest mal DirectX, OpenGL) sollten die Zeichenoperationen entsprechend des Clippings optimieren, was sich dann wohl in einer kleinen Performancesteigerung sichtbar macht. |
AW: FMX = Spiele-Engine in schlecht?
So, nun nehme ich mir mal ein paar Minuten um das Konzept meiner selbst gezeichneten Komponenten zu erklären. Das ist vor FireMonkey entstanden. Im Moment sieht es allerdings so aus als ob das in der Praxis wegen FireMonkey nie zum Einsatz kommen wird und wir stattdessen FireMonkey einsetzen werden.
Deshalb kommt das ganze größtenteils aus der Erinnerung und einem kurzen Blick in den Quelltext, denn das ist schon eine Weile her... Das Grundprinzip: Beim Zeichnen bekommt die Komponente eine Zeichenfläche mit übergeben. Dort zeichnet sie sich selbst einfach drauf. Ob die Zeichenfläche der Bildschirm oder eine Bitmap ist, interessiert die Komponente nicht. Jede Komponente besitzt eine Methode, die eine Region erstellt, die die Grenzen der Komponente festlegt. Vor dem Zeichnen wird die Zeichenfläche mit ExtSelectClipRgn auf diese Region in Kombination der Region der Elternkomponente beschränkt. Man kann also z.B. günstige Gradientmethoden usw. nutzen, die eigentlich über die Komponente hinaus zeichnen würden, statt diese manuell auf die konkrete Region anzupassen. Muss eine Komponente neu gezeichnet werden und ist Transparenz aktiv, wird ein umgebendes Rechteck der Region benutzt um alle Komponenten, die im selben Bereich liegen, zu finden und ebenfalls neu zu zeichnen. Der Vergleich der Regionen kostete bei vielen Komponenten zu viel Zeit, ebenso die Sichtbarkeitsprüfung um nur nicht verdeckte und somit sichtbare Teile neu zu zeichnen. Dazu kommt nun, dass eine Komponente gedreht, gezerrt, gedrückt usw. werden kann. Dies weiß die Komponente selbst aber nicht, sondern wird über eine Matrixtransformation der Zeichenfläche realisiert. Die Komponente zeichnet sich selbst also ganz normal, sieht aber auf der realen Zeichenfläche entsprechend transformiert aus. Die Transformation geschieht mit SetWorldTransform, die reine Versetzung um einen gedrückten Zustand darzustellen mit SetViewportOrgEx (womit dies vor die weitere Transformation gesetzt wird ohne dass das normale Zeichnen diesen Extraoffset kennt), Transparenz kommt am Ende mit AlphaBlend dazu. Für den Designmodus wird ebenfalls das umgebende Rechteck verwendet und daran die Henkel zum Anfassen, drehen, zerren usw. gezeichnet. Das funktioniert natürlich direkt in Delphi wie man es gewohnt ist. Für den Objektinspektor war ein wenig Tools API Trickserei nötig, aber es funktioniert gut und war nicht weiter kompliziert. Quelltext kann ich wie gesagt nicht viel zeigen, daher nur in sehr groben Ausschnitten:
Delphi-Quellcode:
Auf diese Weise kann man das Bild z.B. drehen und versetzen. Mehr zu diesen Berechnungen findest du hier in der Doku zu SetWorldTransform:
var
TransForm: TXForm; TransForm.eM11 := Cos(RadAngle); TransForm.eM12 := Sin(RadAngle); TransForm.eM21 := -Sin(RadAngle); TransForm.eM22 := Cos(RadAngle); TransForm.eDx := OffsetX; TransForm.eDy := OffsetY;  http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspxbzw. in der Doku zu ExtCreateRegion, mit der Funktion lässt sich eine Region analog transformieren: http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspxDas Zeichnen selbst ist daher sehr gradlinig:
Delphi-Quellcode:
Sprich es wird immer entsprechend geclipped und auch bei Fehlern das alte Clipping wiederhergestellt. Das try..finally ist hier sehr wichtig.
procedure T...Element.Paint(ACanvas: TCanvas);
var RegionRect: TRect; DisplayRegion, OldRegion: HRGN; begin DisplayRegion := AutoClipElement(ACanvas, RegionRect, OldRegion); try PaintTo(ACanvas, RegionRect); finally SelectClipRgn(ACanvas.Handle, OldRegion); DeleteObject(OldRegion); DeleteObject(DisplayRegion); end; end; Das mal als kurze Übersicht... |
AW: FMX = Spiele-Engine in schlecht?
Schade, dass sich solche Entwicklungen bisher nicht durchgesetzt hatten.
Ich hätte Dir auf jeden Fall mehr Qualität zugetraut als (nach leidlicher Erfahrung) Emba. |
AW: FMX = Spiele-Engine in schlecht?
Liste der Anhänge anzeigen (Anzahl: 4)
Nur mal am Rande: Transparente Controls bzw. Formulare habe ich jetzt auch mal versucht (normale Grafik, also kein OpenGL o.ä.).
Für Farbverläufe, Drehungen usw. wäre sicher die Nutzung von OpenGL o.ä. sinnvoll. Wenn man unter OpenGL eine Ausgabe drehen würde wäre mir nur unklar, ob man später Mausereignisse direkt auf die das Ergebnis der gedrehten Region umrechnen kann. Kann es sein, dass SDL so etwas unterstützt? |
AW: FMX = Spiele-Engine in schlecht?
Liste der Anhänge anzeigen (Anzahl: 1)
Zitat:
Wenn man den Anhang betrachtet, könnte man im ersten Falle ja einfach
Delphi-Quellcode:
verwenden, um zu prüfen, ob das Control "getroffen" wurde. Im zweiten Falle sieht das schon anders aus, da das BoundsRect nicht mehr der gezeichneten Darstellung entspricht.
BoundsRect.Contains(ClickPoint)
|
AW: FMX = Spiele-Engine in schlecht?
Liste der Anhänge anzeigen (Anzahl: 2)
Beim Aufräumen ist mir jetzt nochmal eine etwas überarbeitete Version "in die Hände gefallen". ;-)
Falls es jemanden interessiert: Man kann jetzt "Edits" und "ListBoxen" ein- und ausblenden und die Controls auf Wunsch transparent schalten. Bei den "Edits" kann man nur Zeichen eingeben und rückwärts wieder löschen. Die Listboxen kann man mit der Maus scrollen. Den Wert der "Progressbar" kann man mit der Maus einstellen und er geht nach dem Loslassen langsam wieder auf 0. Die Panels kann man mit der Maus einfangen und von Hand verschieben. Bis 10.000 Panels läuft das bei mir flüssig. Ziel war es, mal eine flüssige, kleine, aber funktionsfähige GUI selbst aufzubauen. Diese soll von der BL unabhängig lauffähig, allerdings auch leicht an die BL bindbar sein. (Das Projekt ist natürlich recht provisorisch und mit möglichst wenig Aufwand umgesetzt.) |
AW: FMX = Spiele-Engine in schlecht?
Liste der Anhänge anzeigen (Anzahl: 1)
Ich habe die Quellen von dem letzten Testprojekt leider nicht mehr, aber jetzt mal ein neueres Testprojekt etwas ausgebaut.
Das neue Projekt ist langsamer als das alte aber dafür mit geskinten Controls und einfachen 3D-Effekten. Das Programm kombiniert Daten, die es von einem Server abholt (der Drehwinkel des "Pulsars" wird laufend nur auf dem Server weiter berechnet) und den Positionsberechnungen der Controls, die eigenständig auf den Clients erfolgt (so wie ein ein- oder ausfliegendes Control oder ein AniIndicator individuell im Formular eines Anwenders). Das Projekt selbst kann ich nicht veröffentlichen aber hier mal ein kleines Video: https://youtu.be/s3la9s-3tR4 (8 Min) |
AW: FMX = Spiele-Engine in schlecht?
Liste der Anhänge anzeigen (Anzahl: 1)
Hallo Zusammen...
FMX ist zwar keine Gameengine, das bedeutet aber nicht, dass man damit nicht trotzdem schnelle 3D Geschichten hinbekommt. Hier mal ein kleines Demo das ich for knapp 8 Monaten mal geschrieben habe. Läuft bei mir mit ~2000-2280 FPS. Was natürlich quatsch ist, da mein Monitor "nur" 144Hz hat, aber FMX zählt hier nicht Frames sondern rechnet aufgrund der Darstellungszeit aus, wie viele Frames theoretisch möglich wären! Grüsse Mavarik :coder: |
AW: FMX = Spiele-Engine in schlecht?
Ja, das ist cool.
Mir ging es aber eher um flüssige (und asynchrone) Oberflächen von Geschäftsanwendungen. Wenn die 3D-Engine im Hintergrund von FMX selbst gut läuft, dann ist (oder war?) die Control-API nicht gut umgesetzt, die in den 2D-Formularen verwendet wird. Inzwischen habe ich schon einiges dazu gelernt. Ist auf jeden Fall immer noch ein interessantes Thema, finde ich. |
AW: FMX = Spiele-Engine in schlecht?
Diese TScene Komponente könnte auch interessant sein für die Implementiereng, falls noch nicht bekannt. |
AW: FMX = Spiele-Engine in schlecht?
Zitat:
> Oberflächen von Geschäftsanwendungen Habe ich in der Regel keine 3D Button die sich bewegen. Daher verstehe ich Deine Aussage nicht so ganz, bzw. was Dein eigentliches Ziel ist... Sorry Mavarik |
AW: FMX = Spiele-Engine in schlecht?
Zitat:
|
AW: FMX = Spiele-Engine in schlecht?
Bei meinen damaligen FMX-Versuchen war die GUI sehr langsam.
EIN Problem (welches ich nachvollziehen konnte) war, dass ständig alles Mögliche neu gezeichnet wurde. Dadurch wurden wieder andere Neuzeichnungen getriggert usw. Insgesamt war das Zeichnen der Formularoberfläche fehlerbehaftet und langsam. Außerdem waren Animationen (wie der AniIndicator) an den Mainthread gebunden, was ich auf Grund der Werbung vorher anders erwartet hatte. Ich habe dann mal einige Versuche angestellt und wollte Euch das Ergebnis zeigen. Dafür, dass hier keine Grafikkartenfunktionen genutzt werden finde ich es schon überraschend flüssig. Wenn eine Geschäftsanwendung weniger Funktionalität (Bewegung) braucht, umso besser. Eine schnelle und zum Geschäftsprozess asynchrone GUI sollte sich so zumindest realisieren lassen (sogar geskint und mit ein paar 3D-Effekten und Schatten, wenn man will). |
AW: FMX = Spiele-Engine in schlecht?
Das ist leider richtig, deshalb hat wohl Embarcadero die Nutzung als Spieleengine seit FMX V1.0 explizit nicht empfohlen.
|
AW: FMX = Spiele-Engine in schlecht?
Zitat:
|
AW: FMX = Spiele-Engine in schlecht?
Zitat:
|
AW: FMX = Spiele-Engine in schlecht?
Verglichen mit VCL aber leider immer noch nicht perfekt.
|
AW: FMX = Spiele-Engine in schlecht?
Zitat:
|
AW: FMX = Spiele-Engine in schlecht?
Zitat:
Das ist mir noch nicht aufgefallen. Meinst Du nur spezielle Komponenten, oder generell ? Hast Du da mal ein Demoprogramm ? |
AW: FMX = Spiele-Engine in schlecht?
Zitat:
|
AW: FMX = Spiele-Engine in schlecht?
Zitat:
Beispiel: Ein VCL Form mit 100 Controls auf verschiedenen Panels... Da kann ich zuschauen wie sich die Controls aufbauen. ~ 1 Sekunde. In FMX wird das von der GPU in einem Refresh-Cycle erledigt da her auch keine Paint-/Draw-Messages an von Windows gesendet werden. Wenn mehrere Fonts verwendet werden sieht es auf VCL Seite noch schlimmer aus. Mavarik |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 19:54 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz