Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: Do Mär 28, 2024 13:20

Foren-Übersicht » Sonstiges » Community-Projekte
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 92 Beiträge ]  Gehe zu Seite Vorherige  1, 2, 3, 4, 5, 6, 7  Nächste
Autor Nachricht
 Betreff des Beitrags:
BeitragVerfasst: Mi Mär 30, 2005 14:23 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 05, 2002 10:35
Beiträge: 4234
Wohnort: Dortmund
Flash hat geschrieben:
Wie sähe dein dein Lösungsvorschlag aus?
Bei deinem Salomonischen letzten Beitrag kam das noch net so raus ;)

Wen meinst du jetzt damit?

@Flo: Eine OpenGL Oberfläche ist zwar ganz nett und schön hat aber im Endeffekt keinen Einfluss auf den Funktionsumfang. Abgesehen davon, dass sie verdammt viel an Zeit frisst. Und ich weiß wovon in rede.

Ich habe auch schon mal eine Benchmarksammlung gesehen die kam als Consolenanwendungen daher. Die hatte nicht mal ein sichtbares Fenster! Das war dann ein bisschen zu wenig Oberfläche. Man sollte lieber erst einmal das Augenmerk auf den Funktionsumfang richten anstelle auf Oberflächlichkeiten.

Vorher sollte zum Beispiel überhaupt erst einmal geklärt werden, wer damit überhaupt erreicht werden soll! Dann sollte geklärt werden was alles für Tests anstehen sollen. Also wie aufwendig diese werden können? Nicht zu vergessen sollte überlegt werden, wer alles mitmacht und wer welches Know-How besitzt. Also überhaupt erst einmal feststellen was man für Kapazitäten hat. Es nützt ja nichts, wenn sich nur 3 Leute dafür melden, die dann am Tag 2 Stunden Zeit haben und dann auch noch kurz vorm Abi stehen und anschließend arbeiten müssen. Das sind alles Faktoren die ich hier noch gar nicht gehört habe. Wenn man dann mit einer aufwändigen Oberfläche 85% der Entwicklerresourcen verbrucht dann nützt niemandem ein Program was außer schön aussehen nichts kann!


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Mär 30, 2005 14:57 
Offline
DGL Member
Benutzeravatar

Registriert: Sa Dez 28, 2002 11:13
Beiträge: 2244
Wenn man die OpenGL Oberfläche nur will, damit man es portabel in einem Programm haben kann, dann ist das ein ganz schön großer Aufwand. Das wäre ja dann das Java Prinzip, wo die ihre Oberfläche auch aus Portabilität selber machen. Sicherlich ein interessantes Project aber hier ein Umweg. Da wären eine getrennte Windows und Linux Version beide zusammen wesentlich schneller gemacht.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Mär 30, 2005 15:06 
Offline
Guitar Hero
Benutzeravatar

Registriert: Do Sep 25, 2003 15:56
Beiträge: 7804
Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Lossy eX hat geschrieben:
Flash hat geschrieben:
Wie sähe dein dein Lösungsvorschlag aus?
Bei deinem Salomonischen letzten Beitrag kam das noch net so raus ;)

Wen meinst du jetzt damit?

Dich. ;)

Lossy eX hat geschrieben:
Oberflächlichkeiten.

:lol: Den find ich richtig gut.

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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Mär 30, 2005 16:02 
Offline
Fels i.d. Brandung
Benutzeravatar

Registriert: Sa Mai 04, 2002 19:48
Beiträge: 3827
Wohnort: Tespe (nahe Hamburg)
@lossy: Doch, doch... lies mal genau nach ;-)
@lars: Wieso machen die Java Nutzer das? Die haben einheitliche GUIs, leider sehen die fast alle potthässlich aus (SWT mal ausgenommen, dass ist dafür zu kompliziert *g)
@flo: Warum ich mich bei einer Entscheidungsfindung nicht aktiv einsetzen möchte hat einfach den Grund, dass ich bezweifel so große Kapazitäten zur Verfügung zu stellen als das ich meine Meinung für Maßgeblich halten würde. Daher versuchte ich nur meine Gedanken so nieder zu bringen, dass sie ins Schema passen. Sprich Hybird ==> nein.
Ich mache das Spielchen einfach nochmal... Rom ist auch nicht an einem Tage gebaut worden und ich denke auch, dass wir es nicht tun sollten. Eine grafische GUI hätte zahlreiche Vorteile, gerade was die Portabilität angeht. Ich denke aber auch, dass man daraus fast ein ganzes eigenständiges Projekt machen könnte und daher davon erst einmal abstand nehmen sollten. Gleichsam denke ich auch, dass wir anfangs uns rein auf die Entwickler besinnen sollten und werfe in diesem Zusammenhang dann sogar gleich provokant in den Raum: Warum überhaupt eine Oberfläche? Vielleicht sollten wir uns erst einmal darauf besinnen die zentralen Schnittstellen lauffähig zu bekommen und einige der Tests anzubieten bzw. anzusteuern. Was spricht dort dagegen eine Konsolen-Anwendung mit einem altertürmlichen Menu zu machen? Entwickler werden damit umgehen können und wir halten uns durchaus etwaige Fragen für einen späteren Zeitpunkt offen, wenn es bereits etwas "zu sehen gibt". Ein kleiner "Loader" für die Tests in liesse sich ebenfalls sehr leicht auf die unterschiedlichen Plattformen portieren und auch in einem späteren Entwicklugnszyklus mit einer netten GUI verpacken (OpenGL, CLX, VCL, WinForms, whatever?) Der Endnutzer würde es sicherlich schrecklich finden in einer Konsole die Ergebnisse ausgegeben zu kriegen, aber ich denke die meisten hier interessiert sowieso dann eher das Ergebnis.
.NET würde ich einfach einmal aus Gründen der "Sprachfähigkeiten" der Mehrheit (ich lese das einfach einmal so heraus) nicht empfehlen. Statt dessen streben wir einen sauberen Pascal-Code an, der von allen OOP-Sprachen verstanden werden sollte. Wenn wir nun nicht innerhalb von 2 Wochen fertig werden(was ich sehr stark bezweifel, wenn ich daran denke wie oft das Thema auf dem Tisch steht), haben wir gute Chancen, dass einige der Entwickler zwischenzeitlich .NET besser beherrschen, die Verbreitung unter Windows gestiegen ist (das zweifel wohl niemand ernsthaft an) und evtl. WinForms oder andere gemeinsame Nenner von Mono und Co nahezu einwandfrei verstanden werden. Dann sollte bei einer sauberen OOP-Struktur auch eine Portierung auf .NET nicht sonderlich viel Verschleißzeit fordern. Ein Datenbank-Anbindung, sowie etwaige XML-Verarbeitung wird gleichsam mit der GUI auf einen späteren Zyklus verschoben um uns Anfangs auf die Schnittstelle und Tests zu konzentrieren. Das soll natürlich nicht heißen, dass man deswegen das ganze unkompatibel machen soll, aber ich denke, dass die Datenbank-Anbindung in Form einer XML-Übergabe erfolgen sollte, damit wir auch komplexe Tests flexibel abbilden sollten. Das eine oder das andere macht IMAO keinen Sinn, sondern die Konsole sollte ausreichen. Gleichzeitig erreichen wir dabei dann mit FPC/Delphi vermutlich einen großen gemeinsamen Nenner, den die meisten hier sprechen sollten... auch was die Plattformen angeht.
Ansonsten denke ich auch, dass wir erst einmal Kapazitäten abklären sollten. Keine Projektplanung macht auch nur den Hauch eines Sinnes, solange nicht die Ressourcen definiert sind und ein Projekt definiert sich nunmal aus einer zeitlichen und materiellen Abgrenzung ;) Ich selbst hätte mich über die Datenbankanbindung liebend gerne gekümmert. Ob es groß Sinn macht, dass ich an den Schnittstellen rumwusel bezweifel ich. Hier sind weitaus kompetentere mit am Werke. Da ich mich zeitlich nicht beschweren tue, würde ich dann wohl das "Mädchen" für alles bzw. derjenige der dann sicher stellt, dass der Kram auch unter Linux irgendwie zum laufen bewegt wird. (und sei es nur als Konsolen-App).

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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Mär 30, 2005 16:08 
Offline
Guitar Hero
Benutzeravatar

Registriert: Do Sep 25, 2003 15:56
Beiträge: 7804
Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Klingt logisch, den Fokus erstmal auf den Kernbereich "BenchmarkEngine" zu legen und die GUI außen vor zu lassen. Bin in der Beziehung auch für FPC/Delphi....ich schließ mich einfach mal Phob so an.

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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Mär 30, 2005 17:30 
Offline
Forenkatze
Benutzeravatar

Registriert: Mi Okt 22, 2003 18:30
Beiträge: 1944
Wohnort: Närnberch
Programmiersprache: Scala, Java, C*
Ganz schön deftiger Thread... Gab ein prima Lesefutter ab ;)

Ich wollte zwar jetzt selber auch noch meinen Senf dazu geben, aber nach Phobeus letztem Beitrag ist das wirklich unnötig geworden. Ich schließ mich Phobeus voll und ganz an.

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Mär 30, 2005 18:14 
Offline
DGL Member
Benutzeravatar

Registriert: Do Jun 19, 2003 10:44
Beiträge: 991
Wohnort: Karlsfeld (nahe München)
Ich glaube das einzig schwere an der Erstellung einer solchen Schnittstelle ist, das wir nicht wissen was sie alles bieten muss.
  • Im einfachsten Fall haben wir eine Zeichen Routine und möchten wissen wie viele Frames pro Sekunde gerendert werden können. In diesem Fall bräuchte bräuchte die Schnittstelle nur aus dieser einen Render Funktion bestehen.
  • Dazu könnte aber noch kommen das der Benutzer etwas einstellen möchte. Ein Input ohne Größeneinschränkung müsste also auch enthalten sein.
  • Diese Eingaben könnten nun aber auch aber auch auf ein Pixelformat oder eine Auflösung betreffen, es muss also möglich sein, zwischen den einzelnen Tests, Auflösung und Pixelformat zu ändern.
  • Es wäre natürlich auch wünschenswert das unsinniges hin- und herrwechseln vermieden wird. So könnte man vielleicht gezielt Test mit gleichen Auflösungen (und co.) direkt hintereinander legen.
  • Nun könnte es vorkommen das unabsichtlich ein Modul OpenGL nicht wieder in den Ausgangs Zustand versetzt hat und das Ergebnis eines anderen Vorgangs beeinflusst. Das wäre natürlich auch nicht wünschenswert.
  • Natürlich wäre es auch wünschenswert wenn dem Benutzer, nur mögliche Einstellungen präsentiert werden. Eine Auflösung von 576*231 würde zum Beispiel wenig sin machen genauso wie die Nutzung einer Extension die der Treiber des jeweiligen PCs gar nicht beherscht.
So das waren jetzt einige Punkte von mir die man beachten müsste.

Bisher könnte ich mir so etwas vorstellen:

  1. Beim Start wird für jede Erweiterung eine Klasse erstellt und in eine Liste A eingeordnert. Außerdem speiche
  2. Danach wird von bei jeder Klasse eine Funktion aufgerufen die vom Benutzer Einstellungen verlangt.
  3. Sind alle Einstellungen getroffen, wird eine Liste B der verschieden Modi erstellt. Jeder dieser Einträge verweißt auf die Klasse die ihn eingetragen hat. Mehrfacheinträge sind möglich.
  4. Nach dem der Benutzer dann den Test-Start bestätigt, werden die einzelnen Zustände hergestellt und die Klassen erhalten die Möglichkeit ihre Test durchzuführen und die Ergebnisse in ihren Eigenschaften zu speichern.
  5. Schlussendlich werden dann noch die Ergebnisse gesammelt ausgegeben.(nach Liste A logischerweise)


Wie die einzelnen Test durchgeführt werden müssen wir aber noch besprechen. Eine einfache Zeichenroutine Mag in manchen Fällen nicht ausreichen.

MfG
Flo

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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Mär 31, 2005 08:05 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 05, 2002 10:35
Beiträge: 4234
Wohnort: Dortmund
Also ich denke mal mit einer Rendermethode ist es nicht getan. Es muss in jedem Fall etwas initialisiert werden. Und zwar OpenGL. Du kannst OpenGL zwar aus der Anwendung heraus initialisieren hast dann aber in der DLL noch lange nicht die Funktionspointer. Dazu ist der derzeitige OpenGL Header auch nicht ausgelegt, da du OpenGL anhand eines DLL Handels initialisieren musst. Das müssten wir dann noch ermöglichen in dem wir den Header ein wenig umstellen. Und ich denke auch mal, dass du dann um ein Deinitialisieren nicht drum herum kommst.

Zusätzlich dazu brauchst du natürlich von einem Test auch infos. Also Name, Beschreibung etc. Evtl auch eine Liste mit Extensions, die benötigt werden um solche Tests schon zu begin an ausfiltern zu können.

Ich würde es auch ermöglichen, dass in einer DLL mehrere Test existieren können. Das dürfte Speziell dann sinnvoll sein, wenn sehr ähnliche Test implementiert werden.

Die Ergebnisse würde ich wohl auch als XML zurückgeben. Bilder etc würde ich als RAW Daten zurück geben. Wie die Daten auszusehen haben ist dann in dem XML beschrieben. Also Breite = 200; Höhe = 200; Format = RGB. Oder so.

Einstellungen würde ich vernachlässigen. Es soll ja schließlich ein Benchmark werden der representative Ergebnisse liefert. Und wenn ich mir den kaputt oder schneller tweake ist niemandem geholfen. Und ich würde auch auf keinem Fall für jeden Test die Einstellungen extra abfragen. Das hat zur Folge, dass der Benutzer 20 Fenster vorgesetzt bekommt in dem er simpelste Einstellungen vornehmen muss. Spätestens nach dem 5ten würde ich die Anwendung über den Taskmanager abschießen und augenblicklich löschen. Jeder test muss seine Standardeinstellungen mitbringen! Ich würde es wenn überhaupt nur als Zusatz anbieten, dann müsste man aber die Einstellungen komplett auf einem Fenster unterbingen. Das würde bedeuten, dass man eine Einstellungsdefinition auslesen muss und daraus dann eine Liste an Einstellungsfeldern generiert. Den Aufwand solltest du nicht unterschätzen.

Ich würde die Schnittstelle auch so gestalten, dass sie Spachunabhängig ist. So könnten dann zum Beispiel auch Test in C++ geschrieben werden. Und man bekommt weniger Probleme wenn man nach Linux Portieren will. Also anstelle eines Strings einen nullterminierten Pointer oder einen Pointer und eine Länge. Keine Klassen direkt sondern immer nur Daten.

PS: Für den Fall, dass XML zum Einsatz kommt wäre es wohl auch nicht schlecht, wenn man einen kleine Wrapper DLL anbietet mit der man XML generieren und wieder auslesen kann. Und zwar rein Prozedural. Das ist zwar ein bisschen Aufwand. Aber so müsste nicht jede DLL ihr eigenes Süppchen kochen. Außerdem bräuchte man auf Linux dann nur noch die DLL austauschen und braucht an den Tests dann so gut wie gar nichts mehr zu ändern. In dem Wrapper muss man aber auch nicht den ganzen Standard einfließen lassen sondern nur das was benötigt wird.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Mär 31, 2005 09:56 
Offline
DGL Member
Benutzeravatar

Registriert: Sa Dez 28, 2002 11:13
Beiträge: 2244
Schaut euch doch mal die Schnittstelle im alten Benchmark an. Die unterstützt das nämlich alles und die Daten werden auch in strukturierter Form zurückgegeben, wenn auch noch nicht in XML gespeichert, aber das kann ja auch im Hauptprogramm geschehen.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mo Apr 04, 2005 17:39 
Offline
DGL Member
Benutzeravatar

Registriert: Do Jun 19, 2003 10:44
Beiträge: 991
Wohnort: Karlsfeld (nahe München)
Zunächst einmal sollte hier geklärt werden was für Tests für unsern Brenchmark überhaupt in Frage kommen.

MfG
Flo

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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Mai 04, 2005 21:18 
Offline
Guitar Hero
Benutzeravatar

Registriert: Do Sep 25, 2003 15:56
Beiträge: 7804
Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Bei OpenGl.org hab ich nen Hinweis auf nen OpenGL Benchmark gefunden. Wie passt das ins Benchmark Konzept? Ideenquelle oder Abbruchgrund?

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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Mai 05, 2005 06:49 
Offline
DGL Member

Registriert: Do Mai 30, 2002 18:48
Beiträge: 1617
Das passt wunderbar, weil das hier ein Community Projekt werden soll und nur weil es bereits Benchmarks gibt, heisst das nicht, dass wir nicht auch einen schreiben dürfen - ganz so weit sind softwarepatente dann doch noch nicht ;-)


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Jun 28, 2005 11:17 
Offline
Guitar Hero
Benutzeravatar

Registriert: Do Sep 25, 2003 15:56
Beiträge: 7804
Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Nachdem das Thema wieder einzuschlafen droht, hab ich mir mal paar verworrene Gedanken zum Benchmark gemacht.

(Da ich mich mit der Funktionsweise der Interfaces in Delphi nicht wirklich auskenne und DLLs bei mir nur eine Gedankliche Daseinsberechtigung haben kann das auch alles falsch sein deshalb nenn ichs mal "Denkanstoß"...)

Die Hauptanwendung des Benchmarks benötigt Prinzipiell 2 Sachen:
1. Eine Möglichkeit Ergebnisse zu Visualisieren bzw. zu speichern.
2. Eine Möglichkeit wärend der Ausführung verschiedene Benchmark-DLLs zu laden.

Jede Benchmark-DLL hat dabei folgende Schnittstelle:
1. Eine Immergleiche Hauptfunktion (zumindest Namentlich) wie z.B. StartBench;
2. Einen Vektor/ein Feld mit 10 Integer Zahlen ("var"- / Referenzparameter)
3. Einen Vektor/ein Feld mit 10 Fließkommazahlen ("var"- / Referenzparameter)

Der IntegerVektor wird benutzt um der TestDLL Startwerte zu übergeben (Input-Parameter) und ganzzahlige Ergebnisse wie z.B. Frames/ Dreiecke etc. zurückzuliefern.
Der Fließkommavektor wird nur zur Rückgabe von Werten benutzt.

Mit diesen Einschränkungen ist man in der Lage verschiedenste Tests durchzuführen und einen immer gleichen Rückgabestrom zu erhalten.Den kann man dann z.B. in Diagrammen darstellen.


Soweit mein Denkanstoß.

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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Jun 28, 2005 15:16 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Hiho,
Wegen GUI für den Benchmark könnte ich meine GUI Unit beisteuern die ist denke ich sehr ausreichend screenshots dazu sowie source ist unter http://x-dream.sourceforge.net/?link=screenshot&section=GUI .
Ich glaube für das Datenspeichern sollte schon ein CVS her, da der Benchmark ein wohl grösseren Umfang erreichen wird.
Ich denke NoVCL ist auch ratsam, da es das Coden leichter macht(kein weiteren aufwand es an FPC anzupassen).
Das einzige Problem ist, dass man ein Code für Fenster unter windows und Linux einzeln schreiben muss aber die paar Zeilen könnte man notfalls mit SDL leicht umgehen.
Auf .Net würde ich völlig verzichten, nicht nur das es unter Linux noch keine gute Lösung gibt ist auch die verbreitung von gängigen .net Portierungen rar geseht.
Ich rate ab den Code in einzelne Libaries zu stecken, da erstens das in der reellen benutzung kaum einer macht und die Werte verfälcht und zusätzlich auch ein weiteren Punkt liefert den Benchmark nicht als solches zu akzeptieren. Weil Windows und Linux Libaries unterschiedlich behandeln (z.B. Rechtemässig) und somit wieder unterschiedliche Werte liefert.
Die einzelnen Benchmarks sollte man entweder in eine Binary oder jede in eine einzelne stecken aber nicht auslagern.
Ich sehe auch keine Notwendigkeit überhaupt den Code für einzelne Benchmarktests aus zulagern.

MfG TAK2k4


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Jun 28, 2005 16:38 
Offline
Guitar Hero
Benutzeravatar

Registriert: Do Sep 25, 2003 15:56
Beiträge: 7804
Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Die DLLs sollen es ermöglichen, dass mehrere Leute (auch externe) eigene Benchmarks schreiben können und die dann ins Projekt einbinden. DLLs sind also nur ein Mittel um die Modularität zu erhalten.

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


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 92 Beiträge ]  Gehe zu Seite Vorherige  1, 2, 3, 4, 5, 6, 7  Nächste
Foren-Übersicht » Sonstiges » Community-Projekte


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 14 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
cron
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.049s | 17 Queries | GZIP : On ]