Mein Vorschlag wäre das unsere Gesamte Oberfläche auf OpenGL aufbaut. Wie verwenden also gar keine Delphi Kompoente sondern nur selbstprogrammierte.
Daher bräuchten wir für die Hauptanwendung auch nur eine Möglichkeit OpenGL zu nutzen, eine Möglichkeit Text auszugeben, sowie einen Maus- und Keyboard Input.
Menus haben hier schon einige programmiert, und viel wie ein paar Einstellmöglichkeiten und Ergebnis Ausgaben möchte man ja auch gar nicht haben, oder?

Um euch meine Variante etwas schmackhaft zu machen, zähle ich hier mal kurz ein paar Vorteile auf:
1.) Wir können ohne Problemme Erweiterungen hinzufügen ohne den Umweg über DLLs.
2.) Eine Installation von .net fällt weg, und der FPC-Compiler dürfte nicht alzu groß sein.
3.) Der dem Benutzer gebote Quelltext inklusive Compiler verleitet ihn verleicht auch eine Erweiterung zu erstellen.
4a.) Eine OpenGL Oberfläche würde bestimmt gut aussehen
4b.) Eine OpenGL Oberfläche würde es ermöglichen zum Beispiel Animationen einzubauen.(etwa einen Graphen der sich zeichnet)
5.) Da das Progamm direkt für das Betriebssystem compilert wurde ist es ideal daran angepasst.
6.) Wechsel zwischen der Ergebnis Präsentation und den Test verlaufen reibungfreier und ohne Fensterwechsel
7.) Es muss sich keiner in .net einarbeiten und keiner muss auf eine .net fähige Delphi warten.

(Als Beispiel für so eine OpenGL Oberfläche dürfte Blender dienen nur ist diese in C++ programmiert, und viel komplexer als unsere sein muss)

Wenn habe ich jetzt noch nicht überzeugt?

MfG
Flo

_________________
Danke an alle, die mir (und anderen) geholfen haben.
So weit... ...so gut

Naja Blender ist nicht gerade das allerbeste Beispiel für eine gute Oberfläche. Aber wenn man die Oberfläche portabel machen will ist man mit OpenGL besser bedient als mit diesem ganzen anderen Unsinn (außer Windows.Forms) . Nur dieses selber kompilieren finde ich nicht so toll. Dann kann man auch gleich direkt die entsprechenden Versionen zum Download anbieten. Das Problem ist, dass man bei Erweiterungen auch immer neukompilieren muß.
Die Sache mit dem Fensterwechsel hat das Problem, dass man ja auch andere Pixelformate ausprobieren will und dann muß man eh einen neuen RC anlegen.
Mit FP zu arbeiten ist bei den langen Kompilierzeiten auch nicht so wirklich schön.
Um Graphen anzuzeigen muß nicht die ganze Oberfläche in OpenGL gemacht sein, sondern es reichen da die entsprechenden Fenster aus.
Wenn man mal überlegt was da alles an Aufwand betrieben werden muß, nur damit das portabel wird, dann ist das glaube ich nicht zu rechtfertigen, weil es weit von einer schönen einfachen eleganten Lösung entfernt ist.

Ok, da sind wir schonmal einer Meinung!

Von dem selber kompilern soll der Benutzer gar nichts im eigentlichen Sinne mitbekommen. Ein Hilftprogramm erledigt das für ihn, und zweigt ihn falls die Zeit dazu reicht vielleicht die Inhalte der neu Installieren Dateien an.

Hier könnte es uns allerdings passieren das dies viel zu schnell geht. Meine Schätzung liegt bei 1-10 Sekunden je nach größe des Programmes (Man denke hier wie lange Delphi 2005 zum starten braucht!! - Da ist das gar nichts).


Ich habe nur erwähnt das er nicht mehr nötig wäre! Machen kann man ihn doch trotzdem noch .

Also mehere Renderkontexte würde ich zum Beispiel störend finden.(pro Anitmation einen)


Ich glaube das dürfte der geringste Teil sein. Wenn du den nicht machen willst. Also für Windows haben wir hier schon genügend Material da und für Linux wird sich schon was finden.("Zur Not" könnten wir auch noch auf die SDL zurückgreifen)


Musst du ja auch nicht! Das Projekt wird mit Delphi entwickelt. Wir werden schon noch rausfinden was man beachten muss damit die Andwendung ohne Problemme von FPC compilert werden kann.

MfG
Flo

_________________
Danke an alle, die mir (und anderen) geholfen haben.
So weit... ...so gut

selber kompilieren und selbst nichts davon mitkriegen?

hört sich sehr linux-mäßig an.

man kompiliert sich da ja auch seinen eigenen apache zusammen - allerdings mit einem STANDARD c-compiler(GNU,ANSI...) - und nicht mit einem object-pascal- oder delphi-compiler, der dann erst noch installiert werden muss.

und für windows fällt das ja wohl komplett flach - wer kauft sich delphi, nur für ein opengl-benchmark?

ich hoffe sehr, ich habe dich da falsch verstanden.

_________________


"User Error. Replace User and hit Continue."

Der Quelltext sollte sowohl von Delphi als auch von dem Free PascalCompiler compilert werden können. Diesen würden wir einfach in einen Unterverzeichnis mitliefern, eine Installation des Compilers ist nicht nötig. Der Benutzer könnte, um es mal auf die Spitze zu treiben, nicht einmal merken das überhaupt bei unserem Projekt ein Compiler dabei war.

MfG
Flo

_________________
Danke an alle, die mir (und anderen) geholfen haben.
So weit... ...so gut

Naja aber so ein schönes PlugIn System ist das nicht gerade, immer neu kompilieren. Dazu kommt, dass FP nicht gerade der schnellste Compiler/Linker ist. Dafür sind ja die DLL's eigentlich gedacht. Ob man es mitbekommt oder nicht. Das kann man vielleicht bei der Linux Version benutzen. Da ist man es ja gewöhnt das System neu zu kompilieren, wenn man einen Treiber installiert. Natürlich ist es machbar. Genauso wie eine OpenGL gui keine Sache wäre, die man nicht in vertretbarer Zeit hinbekommen kann. Die Frage ist nur ob es der richtige Weg ist und da habe ich meine Zweifel. Aber man muß sich mal überlegen was wir hier eigentlich machen. Es existiert die absolut saubere und elegante Lösung .Net und weil hier niemand weiß, inwieweit das unter Linux läuft, soll das nicht nur unter Linux sondern auch unter Windows verworfen werden. Das ist einer dieser Fälle, bei dem man sich mit einer vermeintlichen Lösung mehr Komplexität in sein Programm holt, also versucht ein Problem zu lösen, indem man mehrere neue schafft und das ist meistens ein Indiz dafür, dass es nicht der richtige Weg ist. Unter Linux mag das ja vielleicht die beste Lösung sein, aber unter Windows gibt's außer dem Optimum .Net, noch jede Menge andere z.B. Interfaces/DLL's wie bereits gezeigt, die mit einem insgesamt kleineren Aufwand funktionieren. So schneidet man an beiden Ende jede Menge ab anstelle für jedes System das richtige zu machen. Spricht ja nichts dagegen unter Linux eine QT Anwendung zu machen. Das scheint ja da, das native System zu sein. Aber QT unter Windows ist fehl am Platze. Das gleiche sieht man ja am Beispiel Java. Es läuft angeblich überall, aber nirgends richtig gut. Wenn wir das portabel halten wollen, dann müssen wir die Schnittmenge der beiden Systeme nehmen und das ist jede Lösung für sich immer mindestens besser geeignet.

Wir nutzen den FPC Compiler .net den JIT-Compiler ... bei beiden muss bei der Ausführung noch compilert werden. Bei beiden könnte es theoretisch einen Zwischen Code geben. Bei der .net Variante ist der Compiler Vorgang allerdings nicht einmalig!


Ob es elegant ist auf eine Microsoft Technik zu bauen, die noch nicht einmal verbeitet ist sei dahingestellt. Aber wenn du dann behauptest die .Net Lösung sei "absolut sauber", dann frage ich mcih was du an der andern Variante als "unsauber" betrachtest?
-Ist der Freeware Compiler etwa noch nicht so ausgereift die die .net Technik?
-Ist es unsauber ein Programm(in dem Fall den Compiler) über ein anderes aufzurufen?(das macht übrigend Delphi auch!)
-Ist es unsauberer richtigen Quelltext zu compilern anstatt einen, der vorcompilert und unlesbar gemacht wurde?
-Ist es unsauber wenn ein Programm erst nach der Installation funktioniert?


Jetzt redest du aber die .net Variante.
- Viele kennen sich mit .net nicht aus!
- Viele haben .net noch nicht, oder eine .net fähige Delphi-Version.(ein paar werden Samstag eine erhalten aber nur ein paar)
- Sehr viele potenzielle nutzer haben das .net-Framework nicht installier!(klar wir können natürlich 3 Jahre warten und dann weiter diskutieren...)
- Wir wissen nicht ob noch weitere Problemme auftreten können, da wir uns in ein neues Gebiet begeben

Hier scheinst du sogar selber eine Andeutung auf die Zukunft von .net zu machen.


Da könntest du recht haben, allerdings brauchen wir das auch nicht!


Also ich habe lieber einmal etwas mehr Aufwand und dafür mehr Freiheiten. (Bei DLL bin ich an Schnittstellen gebunden; Bei .net an .net )


Also ich stell mir den Aufbau so vor:

Jeweil seine compilte Helfer Anwendung für Windows und Linux.(muss sogar gar nicht in Delphi geschrieben sein)

[Linux OpenGL Initialisierung]<-[Allgeminer Code & Erweiterungen]-> [Windows OpenGL Initialisierung]

MfG
Flo

_________________
Danke an alle, die mir (und anderen) geholfen haben.
So weit... ...so gut

Also um einige Dinge klar zu stellen.
a) SDL ist nicht von Haus aus dabei. Allerdings liegt ist das Geheimnis warum es auf einigen System ist wohl leicht gelöst. SDL wurde initiiert von einem Bliizard Entwickler. Ich denke jene, die davon Produkte haben, werden daher denken, dass SDL von Haus aus mitinstalliert wird.
b) .NET ist gut verfügbar unter Linux, WinForms hingegen nahezu nicht
c) Ist .NET in der Tat schlechter verbreitet als man annehmen darf. IMAO teilt der IE ja in seinem Referer mit ob .NET mit an Bord ist und mir schwirt da ein Heise-Artikel in Netz, wo einer der Messseiten mit ca 12% aller IE Nutzer angab (was sicherlich auch nicht wenige sind...).
d) FPC ist nicht bemerkenswert langsamer als die Windows-Konkurrenz. Eine Lösung die FPC-Kompatibel ist muss weder mit Lazarus noch auf der Konsole entwickelt werden.
e) Werden wir wohl eher Binaries für die Plattformen verteilen und den Interessierten den Compiler für den Code selbst auftreiben lassen. Zumindest in der Linux-Welt würde jeder gesteinigt werden, der bei seinem Programm einen Compiler mit ausliefert

Nun meine Gedanken zu den einzelnen "Hauptrichtlinien":
.NET
Ich halte das Argument, dass es nicht überall drauf ist für zu vernachlässigen. Fakt ist, dass MS als Motor es vorran treiben wird und auch wenn ich es vielleicht nicht gerne höre: Wir werden mit MS wohl oder übel mindestens ein paar Jahrzehnte vorlieb nehmen. Das sich niemand Longhorn besorgt, wage ich zu bezweifeln. Ich hörte ähnliches bei der Aktivierung von WinXP. Der große Vorteil von .NET ist in meiner Sicht keineswegs die Portabilität. Ganz im Gegenteil. Es würde viele Dinge sehr erschweren um es portabel zu halten. Der wahre Vorteil ist vielmehr das dahinter liegende Framework. Mit dessen Hilfe ist die Verwendung von XML, Datenbanken und die Internetprogrammierung ein Witz. Anstatt irgendwelche Daten in nicht interpretierbaren Reihenfolgen zu versenden könnte man das ganze in richtigen zukunftssicheren Datenstrukturen versenden.
Der Nachteil: Portabilität. Darum ist es leider sehr schlecht bestehlt. Die Grundlagen (XML, Internetprogrammierung) laufen auf beiden Plattformen bereits sehr gut. Allerdings der grafische Teil wird sich nur sehr schwer auf einen gemeinsamen Nenner bringen lassen. Unabhängig davon ist jenseits der Windows-Welt Mono nicht weit verbreitet. Die Hauptfrage, die wir uns hier wohl stellen sollen ist, wieviele .NET-Entwickler wir haben für dieses Projekt. Das Shared Libaries schlechter Portabel seinen als Assemblies kann ich mir momentan nur sehr schwer vorstellen. Es gibt Shared Libaries für Linux und entsprechend werden die Compiler auch dieser erzeugen können. Wir sollten nicht vom Standpunkt ausgehen, dass wir eine Windows-DLL auf anderen Plattformen zum laufen kriegen müssen, sondern nur den Code auf anderen so kompilieren zu können, dass die Schnittstelle paßt.

FPC/SDL/OpenGLGUI
Was die Portabilität angeht ist dies wohl ein unschlagbares Duo. Auf zahlreichen Plattformen würde diese Lösung mit akzeptablen Aufwand funktionieren. Compilier und Libs sind leicht für beide "Welten" verfügbar. Die Programmiersprache wäre hier jeweils Native und damit eher traditionell orientiert.
Als Nachteil wäre hier wohl zweifelsfrei die GUI aufzuführen. Die kann man sicherlich hübsch (und damit sogar portabel machen), allerdings denke ich auch, dass sich der zusätzliche Arbeitsaufwand hierdurch erhöhen wird. Ich hielte das nicht für zu vernachlässigen. Des Weiteren würden wir nicht ohne weiteres auf XML und Co zugreifen können ohne den Arbeitsaufwand erneut zu erhöhren oder uns in andere Abhängigkeiten zu verstricken, die auf beiden Systemen nicht verfügbar sein würden.

Hybrid
Ein richtiges Pro/Contra fällt hier sehr schwer. Jede Entwicklung, die nicht auf der gleichen Basis erfolgt führt sofort zu einem Mehraufwand an Arbeit. Der unterscheidende Teil muss dabei so gering wie möglich gehalten werden. Würden die Windows-Entwickler SDL für einen zu großen Aufwand halten, so wäre es ein Kinderspiel in der Render-Loop eine andere Funktion aufzusetzen und es schnell auf die Win32-API zu bringen, während die Unixer sich einfach SDL bedienen. Allerdings wäre es wohl utopisch anzunehmen, dass wir eine .NET-Lösung in C#/Delphi2005 für WIndows schreiben, während die Linuxer den Code dann native portieren mitsamt jeder Änderung. Auch wenn man in .NET z.B. XML-Strukturen verwendet (weil es sich anbietet), so würden ganze Teile der Code-Basis komplett neu geschrieben werden. Wir sollten das realistisch angehen: Dafür haben wir nicht die nötige Manpower. Ich halte dies daher für den eindeutig schlechtesten Weg, sondern höchstens als Ausweich für ein "SDL-Freies Windows" in Kombination mit dem zweiten Vorschlag. Auch eine Hybird-Lösung von 1 und 2 wäre zwar genial, aber genauso abwägig. Was würde man dafür geben mit Mono SDL-Fenster zu haben und gleichzeitig XML-Unterstützung von .NET. Das würde unter Windows sogar vielleicht noch brauchbar sein, unter Linux allerdings an der Verbreitung scheitern.

Portabilität halte ich nicht für ein modernes Hexenwerk. Professionelle Hersteller machen es vor. Das Problem was sich uns hierbei nur stellt ist, wie weit wir den Spagatt überhaupt wagen wollen. Zu weit tut definitiv weh. Ich denke bevor wir uns daher mit den Technologien abgeben, sollten wir erst einmal erfassen, wieviele Leute wir überhaupt für die einzelnen Lösung haben. Was hilft uns eine .NET-Lösung wenn wir einen Entwickler haben? Was hilft uns eine OpenGLGUI, wenn wir nur einen .NET-Entwickler haben? *g Was sich mir momentan gänzlich den Horizont entzieht ist die Möglichkeit das Fensterhandling jeweils OS-Spezifisch zu machen und den gesamten Unterbau von .NET nicht zu verwenden und unter Linux dafür versuchen die Shared Libaries aus einem .NET-Delphi-Code zu generieren. Allerdings hielte ich .NET für eine reinen Fenstermanager für ziemlich Schade. Just my six cent...

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

Nur mal so als kleine Frage:
Der Grund warum .net-Programme keine alzugroße Start Zeit haben liegt daran, das Methoden erst compilert werden wenn diese aufgerufen werden. Normalerweise macht das ja auch sinn, aber könnte das bei einen Brenchmark nicht zu Verfälschungen führen?

z.B.

Test 1.
Zeit genommen
[Weitere Aufrufe]
-Erster Aufruf einer Methode(z.B. das Zeichnen eines Modelles)!-> zusätzliche Compiler-Zeit
Zeit gestop

Test 2.
Zeit genommen
[Unwesentlich abgeänderter Vorgang]
-Zweiter Aufruf einer Methode!->die zusätliche Compiler-Zeit fällt weg
Zeit gestop

Ergebnis:
Anscheinend waren die Änderungen von Test 1. gegenüber Test 2. zimlich stark, in wirklichkeit aber überhaupt nicht.



Ähm, Phobeus was wolltest du mit deinem Beitrag aussagen? (Du bist irgendwie zu keinen Ergebnis gekommen)

MfG
Flo

_________________
Danke an alle, die mir (und anderen) geholfen haben.
So weit... ...so gut

Bei vielen Benchmarks wird die Zeit erst nach einer kurzen Startphase gemessen, also nicht gleich die ersten Frames, weil es da wohl noch mehrere Dinge gibt, die zwischengespeichert werden. Außerdem kann man sich sowieso nicht mit einem Funktionsaufruf begnügen und dann die Zeit von glBindTexture o.Ä. bestimmen, da Zeitmessungen im kleinen Bereich in einem System mit mehreren Prozessen sowieso ungenau sind, weil ja nicht nur der Benchmark läuft und jederzeit unterbrochen werden kann. Daher fällt das nicht ins Gewicht.

Arbeitet Lossey nicht an openGL-Bedienkomponenten? Die könnte man doch schick für die GUI verwenden.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Da ist man mal 2 Tage nicht da und darf sich dann gleich nen Wolf lesen.

Eine kleine Sache am Rande. Ihr habt dort einen kleinen Denkfehler. Ein Benchmark so wie er geplannt ist wird zu 100% nur von Entwicklern genutzt. Dafür sind die Test (StateChanges, Rendertechnicken, etc) viel zu uniteressant für irgendwelche Spieler. So schön wie es für normalen Beutzer auch angedacht ist, es ist a. zu Unspektakulär und b. sind das für nicht Entwickler unwichtige informaten. Was kann ein nicht Entwickler denn damit Anfangen, dass sein VBO Typ 0815 2 MTris/s mehr schafft.

Wenn man nicht Entwickler damit ansprechen möchte, dann muss man denen auch etwas bieten. Und dann dürften die Szenen ähnlich komplex werden wie in 3D Mark. Vielleicht nicht wie in der neusten aber für nicht Entwickler ist es ja nur wichtig wie gut ist ihr System für Spiele geeignet. Von daher würde ich auch ganz klar sagen. Lasst nicht Entwickler aus der Betrachtungsweise herraus oder es muss richtig angepackt werden.

@Flash: Ja ich habe so etwas mal gemacht. Aber Aufgrund einer neuen Arbeitsstelle liegt das alles ziemlich brach. Die meisten Standardkomponenten funktionieren so halbwegs. Allerdings existiert noch keinerlei Tastaturhandling womit es sich nur mit der Maus steuern lässt. Bevor man die sinnvoll in einem Programm einsetzen kann muss dort noch ein wenig arbeit gesteckt werden. Vor allem fehlt noch ein visuelle Gestaltungsmöglichkeit. Ja auch das hatte ich schon mal angefangen. Nur leider funktioniert die Skriptkomponente nicht so wie ich es gerne hätte was die ganze Sache ziemlich unbrauchbar macht.

Ich persönlich würde da aber eher empfehlen, dass man auch bereits existierendes zurück greift. Das macht vieles einfacher. Was ist denn zum Beispiel mit CLX? Kylix gibt es auch in einer freien Version. Schon hätte man einen Code der sich sowohl unter Windows als auch Linux kompilieren ließe. Und dann würde ich damit eine Oberfläche machen. Wenn dennoch interesse daran besteht.

Ich würde momentan auch nicht mit .NET entwicklen. Dafür ist es in meinen Augen noch zu früh. Ich würde mich davor aber auch nicht verschließen und zu mindest ein wenig in die Zukunft blicken. Das Programm sollte man so aufbauen, dass man es später ohne Problem auf .NET oder auf zur Laufzeit kompilierte Test (etc) heben kann.

Die Testengine würde ich so gestallten, dass man eine abstrakte Klasse hätte die eine Schnittstelle zur Verfügung stellt mit der ich alles steuern kann. Die Oberfläche arbeitet dann mit dieser Schnittstelle und legt lediglich eine Instanz von einer Ableitung an. Da würde ich zu Begin eine Ableitung erstellen die mit DLL's arbeitet. Da könnte man dann ohne sonderliche große Probleme eine erstellen die mit zu kompilierenden Test arbeitet. Wenn die eigentliche Funktionalität nur auf wenige Bereiche beschränkt ist, dann sollte das ja alles in halbwegs erträglichem aufwand lösbar sein. Man sollte sich das nur gut überlegen.

Wie sähe dein dein Lösungsvorschlag aus?
Bei deinem Salomonischen letzten Beitrag kam das noch net so raus

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Da stimme ich zu 100% zu.

Wir sollten aber defintiv die Frage klären ob wir eigene GUI machen, unabhänig davon ob wir nun .net nutzen oder nicht!

Hier geht es zur Umfrage!

MfG
Flo

_________________
Danke an alle, die mir (und anderen) geholfen haben.
So weit... ...so gut