Ich hab in der Free Pascal Hilfe bisher nur einen Artikel zu DLL-Bibliotheken gefunden.
Bist du dann für .NET wenn, eine Aufteilung auf Bibliotheken unter Linux nicht möglich ist, Phobeus?

MfG
Flo

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

@Lars: Das halte ich eher für ein Gerücht. MS fängt langsam an Mono und Co mit Patentklagen zu drohen, dass MS Mannen mit denen zusammenarbeiten wäre ein wenig Schizophren (wobei das ja nichts heißen muss, Quellen?) Auch arbeiten die Leute von Mono und DotGnu eng miteinander und verwenden teilweise sogar die gleichen Bibiliotheken. Es hat sich auch eine Menge bei den WinForm-Unterstützung getan und ich vermute, dass gegen Ende des Jahres wirklich kleinere Anwendungen Problemfrei auf anderen Plattformen laufen würden. Die Bonusfrage wäre dann wohl eben eher, ob man sich die .NET-Last auflädt und davon ausgeht, dass es entsprechende Verbreitung hat. In der Windows-Welt wird es wohl spätestens 2006 eine hohe Verbreitung erreichen in der Linux-Welt... wohl nur sehr langsam. Bin bisher keiner einzigem sinnvollen Programm begegnet, dass darauf aufbaut.
@Flo: Prinzipiell bin ich gegen nichts. Ich würde nicht einmal auf einen Linux-Support pochen, allerdings halte ich es für ein professionelles Denken, wenn man versucht die beste Lösung anzustreben ohne dabei Nutzerkreise auszuschließen. Aus Codierungssicht bietet .NET einige Vorteile, die Frage ist nur, ob es Anwender auch so sehen werden. Die zentrale Frage, die wir uns also stellen sollten ist vielmehr: Wenn adressieren wir? Entwickler oder Anwender. Denn ich denke jeder seriöse Entwickler wird sich kaum davor zu schauen .NET oder Mono auf seinem System zu installieren.

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

Da große Teile des Programmes hauptsächlich für Programmierer interessant sein werden, gebe ich nun mal nach und stimme auch für .net . Jetzt müsst ihr nur noch Flasch überzeugen.
MfG
Flo

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

ich bin entschieden gegen .Net und habe noch kein wirklichen Vorteil dafür hier gesehen...
Lars hat doch schon eine gute und ausbaufähige Delphiversion geschrieben und ich sehe garkeinen Bedarf hier .Net zu verwenden.

_________________
. . .

Ich bin auch eher für die .Net freie Variante.
Es bringt uns nämlich wenig, wenn am Ende nur 10 Mann den Benchmark benutzen (weil sie selber was dazu proggen wollen). 10 Entwickler ist mehr als ok, 10 User ist absolut inakzeptabel.

Außerdem Linux...nicht nur das wir Linuxnutzer quasi vor den Kopf schlagen, nein auch der Pool von potentioellen Entwicklern aus der Linuxwelt wäre flöten gegangen.

Ihr könnt ja vieles glauben, aber solange .Net noch nichtmal in Windowskreisen akzeptiert ist wird sich kein Linuxuser mit .Net beladen.



In Sachen DLL kommt mir gerade eine Idee:

Was würde denn ein Entwickler einbauen wollen? - Er würde bestimmte OpenGL funktionen aufrufen, bzw. bestimmte Kombinationen von Funktionen.
Großartige Klassen muss er also gar nicht entwickeln.

Damit kann man den Benchmark doch so aufbauen:
Ein Basisprogramm welches aus einer DLL ein Unterprogramm aufruft, welches die zu testenden Funktionen beinhaltet.
Das Basisprogramm stoppt die Zeit, bereitet die Ergebnisse, macht halt die ganzen standard Sachen.
Der User muss nur noch (z.B. über eine .conf) festlegen welches Tests gefahren werden sollen.

Ein Entwickler denkt sich nur noch eine Testfolge aus, packt die in eine Funktion mit einem Vordefinierten Kopf und diese in eine DLL. Die DLL wird dann in der Conf eingetragen und kann dann von Hauptprogramm aus gestartet werden.
Die Rückgabewerte der Funktion können ja von Grund auf so allgemein gehalten sein, dass zusätzliche Infos zurückgegeben werden können. Das eigentliche Zeitmessen aber übernimmt das Hauptprogramm.


Was haltet ihr davon, bzw. was soll eurer Meinung nach der Benchmark entwickler sonst machen?

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

Das mit dem Zeitmessen im Hauptprogrammen war beim letzten Mal auch eine Disussionsache. Ein Test muß ja nicht zwangsläufig einen Benchmark durchführen, sondern kann auch beliebige Informationen, z.B. über irgendwelche Extensions, oder ab welcher VBO Größe gibt's einen Fehler, zurückgeben. Da macht ja Zeitmessen dann relativ wenig Sinn. Deshalb die Idee, allgemein Schlüssel/Werte Paare für so eine Art Baum wie in der Registry zurückzugeben. So in der Art von "StateChanges/Textures/1024x1024","0.1ms" .
Da kann man dann noch den GL_RENDERER Namen vorne dranhängen und hat dann eine halbwegs eindeutige Bezeichnung, die man auch in eine Online Datenbank eintragen kann.
Von der Sorte kann man hunderte/tausende von Werten sammeln, deshalb ist die Hierachie notwenig um den Überblick zu behalten. Vor allem kann man dann auch später auswerten wie sich das in den Treiber Versionen geändert hat.
Nein, es müssen ja nicht Klassen sein, aber mit Klassen kann man viele Dinge elegant Lösen.Warum soll man dann drauf verzichten. In meinem letzten Entwurf hatte ich dann Interface genommen, weils damit ja auch über DLL's keine Probleme gibt. Ich weiß aber nicht ob FreePascal das auch kann. Linux Benutzer sollen ja nicht ausgesperrt werden. Da müßte man mal genau untersuchen, wie weit das mit dem dotGNU schon läuft. Einen Link habe ich nicht und da ich kein Linux habe, habe ich's auch noch nicht ausprobiert.
Die Sache mit der Config finde ich nicht so toll. Nicht jeder Windows Benutzer ist mit dieser Linux typischen Art Einstellungen zu verwalten vertraut und ich habe mich auch schon einige Male gewundert. Es hätte aber zumindest den Vorteil, dass man sich die Oberfläche sparen könnte. Aber so eine CheckListbox mit allen DLL's im Verzeichnis ist wesentlich schöner. Hatte das erst so gemacht, dass jeder Test auch noch eine beliebige Anzahl von Konfigurationselementen (String,Enum,...) im Hauptprogramm registrieren konnte, aber das war zu kompliziert. Eventuell reicht es, wenn jeder Test so wie beim Bildschirmschoner die Möglichkeit hat, einen Dialog anzuzeigen. Nur wenn man eine OpenGL GUI nehmen will, dann muß die ja im Hauptprogramm sein und da muß man dann schon jede Menge Schnittstellen wieder definieren. Unter .Net wäre es mit einem kleine Script für jeden Test getan und man könnte da sogar noch einen kleinen Eigenschaftsdialog drin definieren. Oder man nimmt das PropertyGrid um die Eigenschaften einzustellen und ist mit einer Zeile fertig. Wenn man das irgendwie halbwegs unter Linux hinbekommt, dann wäre das optimal.

Hier stelle ich einfach mal zur Diskussion was bislang erarbeitet worden ist. Das Programm ist von vorletzen Jahr, nutzt also noch eine sehr alte Header Version, die mit dabei ist. Vor dem Testen bitte auch Module1.dpr erstellen. Denke mal ich habe seit November 2003 auch was dazugelernt (z.B. Quelltext einrücken), so übernehmen sollte man das vielleicht nicht. Außerdem geht's ja vermutlich nicht mit fp.

Das mit den VBOs könnte man dann ja so lösen, dass die Function ein FlagFeld und Werte zurückliefert. Im FlagFeld steht dann quasi drinnen, dass die Zeitmessung verworfen werden kann. Und die Werte sind z.B. immer Reals oder Integers. Damit kann man dann so ziemlich alles zurückliefern. Von Größen bis Adressen.

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

[Habe oben editiert.]
Aber was ist, wenn man zwei Zeiten messen möchte? z.B. wenn man eine kleinere und eine größere Texture immer im Wechsel binden will oder die Kompilierungsgeschwindigkeit von Shadern, abhängig von der Länge messen möchte? Das mit den allgemeinen Werten sehe ich ja genauso, aber dann kann man auch gleich die Zeit selber messen. Aber man braucht man eventuell noch Strings als Ergebniswert. Dann kann man gleich für alles Strings nehmen. Unter .Net würde man einfach Object nehmen. Dann hätte man gleich für wirklich alle Werte vorgesorgt, weil jede Klasse nämlich die function ToString:String hat.

Mal eine ganz andere Idee:
Die einzelen Test sind Mini-Programme die vom Hauptprogramm aufgerufen werden. Die Werte können etweder per Window Messages übertragen werden, oder per IOStream des Mini-Programmes.

Das hierbei eigene Fenster (und somit RC und DC) genutzt werden, hätte natürlich Vor und Nachteile. So könnte man verschiedene Pixelformat Einstellungen testen, hätte dann aber bei einer Test-Reihe viele Fenstererstellungen die eher nerfig als nützlich sind.

Die Frage ob wir nun .net verwenden scheint mir allerdings immer noch nicht geklärt!

MfG
Flo

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

Und wenn man eine Liste mit Zahlen zurückgibt? (Also ein Handgeschriebene. Weil vermutlich TList net unter FreePascal verfügbar ist)
Da kann man dann die Millisekunden oder was auch immer messen. Was die Werte bedeuten, muss dann allerdings der Entwickler selber wissen.

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

Welche Möglichkeiten haben wir bisher?

1.) Wir nutzen .net um unsere Anwendung leicht erweiterbar zu halten
2.) Wer benutzen DLL um unser Programm zu erweitern und nehmen in Kauf das es nur unter Windows läuft
3.) Unser Projekt kann man nur in fertigen compilten Zusammensetzungen von uns nutzen.

Bei all diesen Versionen wurde ein gewalltiger Vorteil übersehen denn wir als OpenSource-Programmierer haben, dies ermöglicht noch eine 4. (geheime ) Möglichkeit. Im Ggensatzt zu irgendwelchen Firmen die darauf aus sind ihre Quellen geschlossen zu halten, kann es uns egal, bzw. sogar gerade recht sein wenn der Anwender den Quelltext einsehen kann.

4.) Das entgültige Projekt was der Benutzer runterladen kann besteht aus einen kleinen auf das Betriebsystem zugeschnittene Hilfsprogramm, den Erweiterungen in Quelltextform, einen Compiler sowie dem Hauptquelltext.
Das Projekt kann sich dann der Endbenutzer so zusammen stellen wie er möchte und es läuft absolot schnell da es direkt für das Betriebssystem compilert wurde. Dieses Hilfprogramm macht nichts anders als das gesamte Projekt benutzerfreundlich zu compilern, oder falls dies schon für diese Einstellung gemacht wurde das Hauptprogramm zu starten.

MfG
Flo

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

Also ich hatte Probleme LarsMiddendorf's Version zum Laufen zu bringen. Zum einen fehlt die Unit ValEdit, welche die verwendete Komponente TValueListEditor beinhaltet. Des weitern ist die dglOpenGL gerade die Version, welche zu Delphi 5 nicht kompatibel ist, und weitere kleine Kompatiblitäts Fehler gab es auch.(z.B. existiert die Unit Variants und der TabIndex von TPageControl in Delphi 5 noch nicht )

Als ich das nun so weit hingetrickst hatte das es keine Fehlermeldungen mehr gab, stürtze mir das Programm bei einen Klick auf den Button "Start" ab.

Die von Unterteilung von Lars der Module in mehere Kategorien halte ich für eine gute Idee. Meine Vorschläge für Kartegorien wären : Herstellerangaben im Vergleich ; OpenGL Erweiterungen; Techniken; Praxis-Test; Optimierung
(Die Namen können wir ja noch abändern.)

MfG
Flo

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

Das ist ja wie gesagt auch eine sehr alte Version von dglopengl.pas. Kann durchaus sein, dass die damals noch nicht so kompatibel war. Habe die beiden kompilierten Dateien hochgeladen. Ob es mit Delphi 5 nicht läuft ist dann eh egal, wenn man es mit FreePascal machen will, weil bei dieser Lazarus VCL noch eine Menge fehlt.
Das Problem mit der plattformübergreifenden Entwicklung ist, dass man da so viele Kompromisse eingehen muß, dass keine der Versionen mehr wirklich schön ist. Die einzige Möglichkeit das halbwegs gut hinzubekommen sehe ich in .Net, falls die Windows Formen da auch funktioniern. Da werde ich mich jetzt mal genauer informieren. Ansonsten ist es vielleicht besser man macht zwei funktional identische aber getrennte Versionen. Die Linux Version kann dann ja auch ruhig ohne GUI mit Kommandozeile sein. Das stört Linux Benutzer ja eher weniger als wenn man unter Windows, so eine halbherzige Lösung wie die Lazarus Oberfläche nimmt oder noch 20MB SDL laden muß, die unter Windows gar nicht wirklich gebraucht werden. Dann kann man ja unter Windows .Net mit all den Vorteilen nehmen und wir teilen das auf, das es dann ein Linux Team gibt, das die Version die Portierung übernimmt. Für Linux ist dann SDL und QT usw.. alles kein Problem und unter Windows kann man eben die .Net Vorteile ausnutzen. Gibt ja am Samstag schon für einige die PE.

www.3d-seite.de/dateien.zip

Also ich lebe z.Z. noch unter Windows und besitze kein .Net und hab auch keine Ambitionen mir das zu installieren. SDL ist keine 20MB Groß. Selbst das JEDI Paket was Beispiele und zich (un-)nütze Files enthält ist nur 1/4 so groß wie .Net. Außerdem ist die SDL.dll sogar bei XP schon da. (system32)

Also ich bin wirklich gegen .Net.
Wenn wir .Net nehmen müssen auch potentielle Nutzer .Net nehmen. Wenn wir SDL nehmen müssen Potentielle Nutzer gar nix weiter installieren. Und das ist bei >20MB bei .Net wirklich ein Pluspunkt für SDL.

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

Mittlerweile müßte doch eigentlich fast jeder das Framework haben. Gehört ja zum Betriebssystem dazu und demnächst erst recht. Daher sind das auch keinerlei zusätzliche Downloadkosten. Wenn man nicht gerade alles abschaltet ist es doch auch bei Delphi 2005 dabei. Die sdl.dll ist zumindest bei meiner Version von Windows XP nicht vorinstalliert und ich sehe auch nicht ein, warum ein Windows Benutzer das installieren sollte, damit der Benchmark auch unter Linux läuft. Die beiden System sind da nicht sinnvoll zu vereinen. Daher besser jeweils spezielle Versionen machen.