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

Aktuelle Zeit: Mo Nov 30, 2020 02:13

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: Di Jun 28, 2005 18:34 
Offline
DGL Member
Benutzeravatar

Registriert: Do Jun 19, 2003 10:44
Beiträge: 991
Wohnort: Karlsfeld (nahe München)
Ich glaube auch nicht das wir DLLs wirklich brauchen.

Also nehmen wir mal Person X möchte ein Modul schreiben. Was macht diese Person nun sie besorgt sich erstmal Quelltext um darauf das Modul aufbauen zu können. Da X logischerweise ein Programmierer ist, würde ich es nicht schlimm finden, wenn wir den Sourccode über ein Versions Kontolle System wie CVS oder SVN verwalten und austauschen würden.

Wem das nichts sagt hier die Vorteite die mir bisher aufgefallen sind:
1.) Jeder kann immer mit den aktuellen Sourcecode arbeiten.
2.) Man braucht nur einmal den gesammten Quelltext runterladen. Danach nur noch die Änderungen.
3.) Mit dem Upload dürfte das ähnlich sein
4.) Hat man etwas unfreiwillig verändert kann man es auch ohne Internet zugang die letzte Version wieder herstellen.(zumindest bei svn)
5.) Das Programm was man braucht ist relativ klein.(ca. 3mb)

Wenn nun diese Person X sein Modul, wohlgemerkt nur für unser Projekt, geschrieben hat wird sie es wohl uns irgendwie zukommen lassen wohlen damit es ins nächste Realease mit reingenommen wird. Obwohl die Person uns natürlich auch eine DLL zuschicken könnte fände ich es besser wenn wir das Modul direkt in die Anwendung rein compilern. DLLs würden das fertige Projekt nur unnötig groß machen, da jede DLL alle von ihr benötigten Units beinhalten muss unabhängig von andern Bibliotheken. Auserdem haben wir so mehr programmiersprachliche Freiheiten(z.B.: Strings statt PChars).

Das Feature sich die Moduelle selbst zusammen suchen zu können finde ich gar nicht mal so toll. Wer verzichtet denn schon freiwillig auf die andern Modulle? Die meisten weden aus Bequemheit gleich alle Moduelle runterladen...

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: Di Jun 28, 2005 20:35 
Offline
Guitar Hero
Benutzeravatar

Registriert: Do Sep 25, 2003 15:56
Beiträge: 7772
Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Und die Punkte fallen mir zu DLLs ein:

Der Programmierer schnappt sich ein DLL-Template und schreibt dort seinen Code rein. Ein Upload von Versionen ist nicht nötig. Nur die fertige Version (mit Code) wird zu uns geschickt.
Keine anderen Leute schreiben im eigentlichen Benchmark rum, sondern nur das DGLTeam.
Die Exe bleibt verhältnismäßig klein. Wer spezielle Tests machen will holt sich die DLL dazu.
Zusätzliche SW wie ein CVS Server wird nicht benötigt.

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


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

Registriert: Do Jun 19, 2003 10:44
Beiträge: 991
Wohnort: Karlsfeld (nahe München)
Flash hat geschrieben:
Der Programmierer schnappt sich ein DLL-Template und schreibt dort seinen Code rein. Ein Upload von Versionen ist nicht nötig.
Nur die fertige Version (mit Code) wird zu uns geschickt.

Ist ja nicht viel anders :wink: :
Der Programmier schnappt sich das Modul Template und schreibt dort seinen Code rein. Ein Upload von der unfertigen Version ist nicht nötig aber möglich wenn er es darf. Der programmier kann immer auf die akutellsten Templates zugreifen und seine Anwendung noch anpassen falls sich in der Zwischenzeit etwas geändert hat. Wenn er keine Berechtigung hat sein Modull selbst einzubauen schickt er den Code zu uns.

Zitat:
Keine anderen Leute schreiben im eigentlichen Benchmark rum, sondern nur das DGLTeam.

Kein Problem bei den Current Version Controll System kann man auch Benutzer einrichten die zum Beispiel nur downloaden dürfen.
Zitat:
Die Exe bleibt verhältnismäßig klein. Wer spezielle Tests machen will holt sich die DLL dazu.
Zusätzliche SW wie ein CVS Server wird nicht benötigt.

Wir erhalten durch die automatische Integration aller Modulle mehr Ergebnisse. Riessige Downloads durch eine große DLL Anzahl sind nicht nötig. Diese könnten evt. die Nutzer abhalten sich mehre Test anzuschauen. Da die Module in der Exe enthalten sind werden sie mit upx gleich mit gepackt.
-> Die Exe mit allen Modulen könnte sogar fast kleiner sein als die andere Exe mit 2 DLLs. :wink:

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: Di Jun 28, 2005 21:05 
Offline
DGL Member
Benutzeravatar

Registriert: Sa Dez 28, 2002 11:13
Beiträge: 2244
Also ich kann auch nur DLL's empfehlen. Da braucht der Benutzer sich nicht erst den Quelltext zu laden und vor allem braucht man außer bei dem recht kleinen Hauptprogramm keine zentrale Versionsverwaltung. Da man hoffentlich, zumindest in meiner Version, mehrere Benchmarks in eine DLL packen kann, sollte sich das auch in Grenzen halten. Alle Arten von PlugIn Systemen nutzen sowas wie DLLs. Unabhängigkeit und Aufteilung in Komponenten ist doch gerade der Sinn der Sache. Das ist ja auch ein ganz großer Fortschritt bei .Net, dass man Komponenten dynamisch und ohne großen Aufwand zusammenstecken kann. Am besten nimmt man da noch eine möglichst allgemeine Schnittstelle, nicht 16 Werte reichen aus, denn die Schnittstelle ist das einzige was man später wirklich nicht mehr ändern kann.


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

Registriert: Do Jun 19, 2003 10:44
Beiträge: 991
Wohnort: Karlsfeld (nahe München)
Zitat:
Da braucht der Benutzer sich nicht erst den Quelltext zu laden und vor allem braucht man außer bei dem recht kleinen Hauptprogramm keine zentrale Versionsverwaltung.

Also für den Benutzer gibt es doch zwei Möglichkeiten. Entweder er ist ein Programmier der mitprogrammiern möchte. Dann lohnt es sich für ihn ein Versionskontrolle Programm zu runterzuladen wenn er noch keines hat. Möchte der Benutzer nichts programmiern dann läd er sich eben das fertig kompilerte Programm runter. Natürlich könne wir auch eine fertige Version mit Quelltext hochstellen. Und man könnte sogar überlegen zwei Versionen zu veröffentlichen wenn ein Teil Gebiet, etwa Shader Programme nicht für jeden interessant sind.

Mehre Tests in eine DLL zu stecken, macht auch keinen Sinn wenn man ein wirkliches Plugin Programm haben möchte. Damit nimmst du den Nutzer die Freiheit die du ihm eigentlich geben wolltest. Was auch wirklich fraglich ist ob der Benutzer diese Freiheit überhaupt haben möchte? Wer will schon 10 Downloads für ein und das gleiche Programm starten? Also ich nicht! Und wenn man alles in ein Paket zusammen fast ist fährt man klar ohne Pluginsystem besser.

Bei einem Plugin System hätte weiterhin den Nachteil das Ressourcen nicht gemeinsam verwendet werden können. Also zum Beispiel Modelle.

Zu dem erschwert doch ein Plugin System die Programierung. Warum umbedingt ein Feature bieten was nur kaum einer nutzt und was einen zusätzlichen Aufwand bedeutet?

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 Jun 29, 2005 09:50 
Offline
DGL Member

Registriert: Mi Okt 16, 2002 15:06
Beiträge: 1012
Also finde es ne klasse idee mit dem Community Benchmark hab da allerdings noch einige fragen/vorschläge:

Wie siehts jetzt aus, wurde sich jetzt schon festgelegt, wie das ganze aufgebaut werden muss.
Librarys oder direkt Units, Delphi, FreePascal oder .net ?

Weil mich würde es sehr freuen wenn das ganze wirklich Platform unabhängig wird.
Dann könnte ich nämlich als Unix (FreeBSD) nutzer auch an dem Projekt mithelfen.

Es wäre sogar dann ne gute bereicherung für die Linux/Unix Welt, weil es gibt da bisher kein wirklichen brauchbaren Benchmark :( Nur das "glxgears" und das ist wirklich nicht toll :(

Also FreePascal mit SDL wäre das beste denk ich.

Versionskontroll system wäre definitiv SubVersion das einfachste =)


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Jun 29, 2005 10:46 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 05, 2002 10:35
Beiträge: 4234
Wohnort: Dortmund
@Flo: Hast du auch schon mal daran gedacht wie es aussieht, wenn jemand einen Test schreiben möchte darin aber seine für 200.000€ gekaufte Bibliothek verwendet? Ich denke mal nicht, dass er bereit dazu wäre diese auf einen offentlichen Server zu legen. Bei einer DLL hingegen schon, da er so seine Hosen nicht runter lassen müsste.

Abgesehen davon müsste man sowieso eine saubere Schnittstelle implementieren (Idealerweise eine zu registrierende Klasse), da man sonst den Verwaltungsaufwand nicht mehr tragen könnte und die Übersicht in dem Haupprogramm zerstört würde. Und wenn man es so gekappselt hätte, dann wäre es ein leichtes das in eine DLL auszulagern.

Mit einer DLL könnten dann Sprachenfremde also C / C++ etc. auch daran Teil haben. Und das kommt ja letzten Endes dem Projekt zu Gute. Die würdest du ohne DLLs aber komplett ausschließen. Und ob du es wahrhaben willst oder nicht so würdest du eine Übermacht ausschließen.

Klar ein PlugIn System bedeutet mehr Aufwand aber du verkennst dort einfach den Vorteil. Du könntest zum Beispiel Test zum Projekt hinzufügen oder individuelle Konstelationen zusammenstellen alleine dadurch, dass du Dateien mit auslieferst oder eben nicht. So müsstest du rein gar nichts an der Anwendung ändern um am Funktionsumfang etwas zu ändern.

Zitat:
Bei einem Plugin System hätte weiterhin den Nachteil das Ressourcen nicht gemeinsam verwendet werden können. Also zum Beispiel Modelle.

Wenn ein Test abgeschlossen ist würden die sowieso alle entladen werden. Man kann nicht versuchen zwischen den Tests parallen zu schließen. Das würde ja bedeuten, dass ein jeder Test jeden anderen kennen müsste. Außerdem denke ich mal nicht, dass 2 Test gleichzeitig laufen würden, oder?


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Jun 29, 2005 14:32 
Offline
DGL Member
Benutzeravatar

Registriert: Do Jun 19, 2003 10:44
Beiträge: 991
Wohnort: Karlsfeld (nahe München)
Bisher hat noch keiner einen Modul Vorschlag näher ausformuliert(in diesem Wiki Artikel). Ohne grobe Kenntnis über das was die Modulle machen und was sie für ein Ergebnis liefern können wir gar nicht weiter machen. Denn unabhäng davon ob wir nun eine DLL verwenden oder nicht festlegen wie die Modulle aussehen sollen müssen wir ganz am Anfang.


--------------------------------------------------
Lossy eX hat geschrieben:
@Flo: Hast du auch schon mal daran gedacht wie es aussieht, wenn jemand einen Test schreiben möchte darin aber seine für 200.000€ gekaufte Bibliothek verwendet? Ich denke mal nicht, dass er bereit dazu wäre diese auf einen offentlichen Server zu legen. Bei einer DLL hingegen schon, da er so seine Hosen nicht runter lassen müsste.

Also wenn so jemand mit 200000€ teuren Code kommt, und der DLLs möchte, dann wäre ich auch für eine DLL. :mrgreen:

Scherz beiseite, sollte es wirklich jemanden geben der einen guten Grund hat seinen Code geheim zu halten (was ja aber nicht umbedingt in unserem Interesse ist), so kann er uns diesen immer noch als Objekt-Dateien zukommen lassen.

Zitat:
Abgesehen davon müsste man sowieso eine saubere Schnittstelle implementieren (Idealerweise eine zu registrierende Klasse), da man sonst den Verwaltungsaufwand nicht mehr tragen könnte und die Übersicht in dem Haupprogramm zerstört würde. Und wenn man es so gekappselt hätte, dann wäre es ein leichtes das in eine DLL auszulagern.

Ja eine saubere Schnittstelle müssen wir machen. Aber immerhin brauchen wir uns dann keine Gedankem mehr über DLL Problemme mehr machen.

Zitat:
Mit einer DLL könnten dann Sprachenfremde also C / C++ etc. auch daran Teil haben. Und das kommt ja letzten Endes dem Projekt zu Gute. Die würdest du ohne DLLs aber komplett ausschließen. Und ob du es wahrhaben willst oder nicht so würdest du eine Übermacht ausschließen.

Genau das Gegenteil ist der Fall. Was mit DLL geht geht ohne schon lange...
Dazu kommt noch das DLL Windows spezifisch sind. Und du willst ja nicht wirklich .so und .dll Dateien ausliefern oder? Und mindestens 3 Linuxer haben wir hier schon mal.

Zitat:
Klar ein PlugIn System bedeutet mehr Aufwand aber du verkennst dort einfach den Vorteil. Du könntest zum Beispiel Test zum Projekt hinzufügen oder individuelle Konstelationen zusammenstellen alleine dadurch, dass du Dateien mit auslieferst oder eben nicht. So müsstest du rein gar nichts an der Anwendung ändern um am Funktionsumfang etwas zu ändern.

Ich würde hier vorschlagen sämtliche Moduele in Abhängkeit von einer Compiler-Direktive einzubinden. Die gewünschten Module auswählen, einmal kompilern und schon hast du das fertige Projekt.

Zitat:
Bei einem Plugin System hätte weiterhin den Nachteil das Ressourcen nicht gemeinsam verwendet werden können. Also zum Beispiel Modelle.


Ich meine hier nicht die geladen Resourcen sondern die Dateien die man mitliefert oder als Ressource in die Anwendung einbindet. Und bei einer solchen 3D-Anwendung wird es viele davon geben. Man denke nur an die Texturen oder Modelle.

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 Jun 29, 2005 15:17 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 05, 2002 10:35
Beiträge: 4234
Wohnort: Dortmund
Zitat:
Bisher hat noch keiner einen Modul Vorschlag näher ausformuliert(in diesem Wiki Artikel).

Ich will ja nicht kleinlich sein aber vielleicht wäre es praktischer, wenn man sich auf ein Medium beschränkt. Ich kann mich da an diverse Forenthreads erinnern in denen bereits Vorschläge gesammlt wurden. Ich frage mich gerade allen ernstes welche Sammlung an Ideen und Vorschlägen als nächstes neu gemacht wird. Da hätte ich meine Beiträge ja auch gleich an /dev/nul schicken können. Das hätte mir arbeit und zeit gespart.

Zitat:
Dazu kommt noch das DLL Windows spezifisch sind. Und du willst ja nicht wirklich .so und .dll Dateien ausliefern oder? Und mindestens 3 Linuxer haben wir hier schon mal.

Wieso nicht? Es spielt doch keine Rolle ob man eine 20 MB Windowsanwendung und eine 20 MB Linuxanwendung zum Download anbietet oder eine 2 MB Anwendung mit 18 MB DLLs. Windows und Linixspezifisch ist beides. Es wird so oder so auf ein für ein Betriebssystem spezifisches Paket hinauslaufen.

Zitat:
Ich würde hier vorschlagen sämtliche Moduele in Abhängkeit von einer Compiler-Direktive einzubinden. Die gewünschten Module auswählen, einmal kompilern und schon hast du das fertige Projekt.

Und wenn du in einen kleinen Test eine Vertexnormale minimal veränderst ist der Benutzer dazu gezungen sich das KOMPLETTE Paket zu ziehen. Wenn man aber nur ein Bugfix an einen Test macht, dann könnte man das über Autoupdate im Programm oder über ein seperates Paket anbieten. Speziell Benutzer mit eingeschränktem (Volumen, 56K) Internetzugängen werden es dir danken.

Zitat:
Ich meine hier nicht die geladen Resourcen sondern die Dateien die man mitliefert oder als Ressource in die Anwendung einbindet.

Okay. Falsch verstanden. Klar das ist natürlich ein Problem. Aber 2 DLLs können ja auch durchaus auf ein und das selbe Bild zugreifen. Interesant wird es dann nur, wenn man die Später hinzufügt, dann müssen alle benötigten Dateien bei liegen ob sie nun bereits installiert wurden oder nicht. Aber das ist dann immer noch kleiner als wieder das ganze Paket.

DLL oder nicht DLL: Du hast recht, wenn du sagst, dass es ohne DLLs einfacher ist. Das ist auch durchaus richtig. Speziell was die Verwaltung angeht. Aber im Endeffket verbauen wir uns dadurch nur die gesammte Flexibilität. Dann könnten wir auch gleich so etwas wie 3d Mark machen. Da gibt es X Test und keine Möglichkeit etwas daran zu ändern. Genau da läuft die aktuelle Diskussion jetzt hin. Und ob das so sinnvoll ist wage ich mal ernsthaft zu bezweifeln. Abgesehen davon kann ich gerade überhaupt nicht nachvollziehen warum das jetzt auf einmal Mittelpunkt der Diskussion ist wo das doch eines der Punkte die von Anfang an so ziemlich klar waren. Wenn man so will könnte man auch sagen, dass man sich nach 6 Monaten intensiven gesprächen einig ist, dass man etwas machen will. Das ist aber auch das Einzige!


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Jun 29, 2005 16:57 
Offline
DGL Member
Benutzeravatar

Registriert: Do Jun 19, 2003 10:44
Beiträge: 991
Wohnort: Karlsfeld (nahe München)
Lossy eX hat geschrieben:
Zitat:
Bisher hat noch keiner einen Modul Vorschlag näher ausformuliert(in diesem Wiki Artikel).

Ich will ja nicht kleinlich sein aber vielleicht wäre es praktischer, wenn man sich auf ein Medium beschränkt. Ich kann mich da an diverse Forenthreads erinnern in denen bereits Vorschläge gesammlt wurden. Ich frage mich gerade allen ernstes welche Sammlung an Ideen und Vorschlägen als nächstes neu gemacht wird. Da hätte ich meine Beiträge ja auch gleich an /dev/nul schicken können. Das hätte mir arbeit und zeit gespart.

So? Dann nutze die doch mal und erklär mir, wie wir das Modul gestallten so das es allen recht ist. :twisted:

Zitat:
Zitat:
Dazu kommt noch das DLL Windows spezifisch sind. Und du willst ja nicht wirklich .so und .dll Dateien ausliefern oder? Und mindestens 3 Linuxer haben wir hier schon mal.

Wieso nicht? Es spielt doch keine Rolle ob man eine 20 MB Windowsanwendung und eine 20 MB Linuxanwendung zum Download anbietet oder eine 2 MB Anwendung mit 18 MB DLLs. Windows und Linixspezifisch ist beides. Es wird so oder so auf ein für ein Betriebssystem spezifisches Paket hinauslaufen.

Nehmen wir mal an wir wollen 3 Betriebsysteme unterstützen.
Für den Fall hätten wir ohne DLLs: 3 Downloads vielleicht 6 wenn wir eine abgespeckte Version auch noch hochladen
Ohne DLL hätten wir bei 10 Modulen: 10*3 + 3 = 33 Downloads; oder 36 wenn man ein Komplettpaket auch noch anbietet.



Zitat:
Und wenn du in einen kleinen Test eine Vertexnormale minimal veränderst ist der Benutzer dazu gezungen sich das KOMPLETTE Paket zu ziehen. Wenn man aber nur ein Bugfix an einen Test macht, dann könnte man das über Autoupdate im Programm oder über ein seperates Paket anbieten. Speziell Benutzer mit eingeschränktem (Volumen, 56K) Internetzugängen werden es dir danken.

Welcher Benutzer mit einer geringen Bandbreite zieht sich nach der kleinsten Änderung wieder die nächste Datei runter? Das machen nur Programmierer und die haben mit einer Versionkontrolle bei der nur die Zeilenänderung heruntergeladen wird definitv den geringsten Traffik im vergleich zu 100-1000 kb einer DLL.

Zitat:
DLL oder nicht DLL: Du hast recht, wenn du sagst, dass es ohne DLLs einfacher ist. Das ist auch durchaus richtig. Speziell was die Verwaltung angeht. Aber im Endeffket verbauen wir uns dadurch nur die gesammte Flexibilität. Dann könnten wir auch gleich so etwas wie 3d Mark machen. Da gibt es X Test und keine Möglichkeit etwas daran zu ändern.

Das Brenchmark wird doch hauptsächlich für Programmier interessant sein. Daher würde ich dennen auch den größten Komfort bieten. Wenn ein Programmier schon mit einer Versionkontrolle gearbeitet hat wird er es begrüßen wenn er so auch an den Quelltext kommen kann. Und wenn nicht, dann hat er immer noch die Wahl sich den Sourcecode so runterzuladen oder sich mal so ein Versionskontrolle system mal anzuschauen. Ist ganz praktisch ;).

Somit hätten also schon mal die Programmier die aktuellste Version! Alle nicht Programmier darf man sowieso nicht überfordern. Ein Baukasten prinzip auf DLL Basis halte ich daher für verkehrt. Und für Programmier ist das ja ein Sourcecode Baukasten praktischer.

Über all das meiste hier kann man sicher diskutieren mich stört aber vorallem das:
- ich bezweifle das hier jeder der ein Modul machen möchte Crossplatfrom kompilern kann. Wärend er wenn er den Sourcecode an ein CVS System übermittelt das jemanden andern machen lassen kann.
- DLLs können sich keine Units teilen. Zum Beispiel müsste die DGL OpenGL.pas in jede DLL mit eingebunden werden. Eine leere DLL ist so knapp 60 kb groß jedoch kommen dann so 140 kb für die eingebunden Units hinzu so das jedes Modus 200 kb extra verursacht die bei einer einzelen Anwendung wegfallen würden. Die kb durch den Code werden vermutlich 50 kb nicht übersteigen. In der Summe hätte man dann so 2850 kb (350kb Hauptanwendung +2500kb für 10 DLLs). Wärend eine Einzelne Hauptanwendung nur 850 kb (350kb + 10*50kb) groß wäre, also genauso viel wie eine Hauptanwendung mit 2 DLLs. Die externen Ressourcen, wie Textuen habe ich bei der Rechung mal außer acht gelassen. Sie werden von beiden benötigt.

Also wenn jemand da meine Zweifel ausräumt könen wir von mir aus eine DLLs benutzen :wink:

Ansonsten würde ich mal gerne wissen was die andern von DLLs halten.
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 Jun 29, 2005 17:36 
Offline
DGL Member

Registriert: Mi Okt 16, 2002 15:06
Beiträge: 1012
Also damit das ganze hier mal bissel voran kommt hier mal ne idee von mir:

Wenn wer weiss wie die sache mit LoadLibrary unter FreePascal ausschaut ob das dann auch für Linux/Unix sowie Windows gilt !

Wir haben unser Hauptprogramm, das hat ne Modul schnittstelle (.so/.dll).
Momentan sind grad 5 drin.

Ihr könnt in einem netten Assistenten auswählen, was für Auflösung, Farbtiefe usw. haben wollt +
welche Module ihr Benchen wollt via Checklistbox.

Hmm ich will Module 1,2 und 5 benchen.

Danach stellt ihr in einer weiteren Karteikarte die Feineinstellung für jedes Modul einzeln ein.
Diese Einstellung Infos müssen aus dem Module entnommen werden !

Code:
  1.  
  2. Nun klickt ihr auf nen Starten button:
  3.   OpenGL wird Initialisiert.
  4.  
  5.   Modul 1 wird gestartet.
  6.     Rendervorgang läuft solang ihr abbricht oder am ende ist.
  7.     Hauptprogramm holt sich ergebnis aus dem Module und Speicherts in ne Array.
  8.   Modul 1 wird gekillt.
  9.  
  10.   Modul 2 wird gestartet.
  11.     Rendervorgang läuft solang ihr abbricht oder am ende ist.
  12.     Hauptprogramm holt sich ergebnis aus dem Module und Speicherts in ne Array.
  13.   Modul 2 wird gekillt.  
  14.  
  15.   Modul 5 wird gestartet.
  16.  
  17.     Rendervorgang läuft solang ihr abbricht oder am ende ist.
  18.     Hauptprogramm holt sich ergebnis aus dem Module und Speicherts in ne Array.
  19.   Modul 5 wird gekillt.
  20.  
  21.   OpenGL wird freigeben.
  22.  
  23.   Statistik wird nun angezeigt mit allen infos global für alle module.
  24.   Pro module kann man nun noch Detailiert infos abrufen, diese stehen ja in den Arrays.
  25.  
  26. Fertig :p
  27.  


Was jetzt wichtig jetzt noch zu klären gibt:

- Welche Informationen muss das Modul am ende ausspucken, Dreiecke Pro Sekunde, FPS Max, Min, Durchschnitt usw.
- Welche Infos muss das Hauptprog dem Modul übergeben ?
- Wie läuft das mit OpenGL in den jeweiligen Modulen hab, da OGL ja Thread based ist müsste man es schonmal nicht initialieren.

Im grunde brauch die DLL ne Initialize, Kill, Run (solange läuft bis es fertig ist oder abgebrochen wird), GetRelevantData (bench ergebnisse die relevant sind), GetInfos (Infos wie name des Moduls, usw.), GetConfigInfos (Die für die Detail-Konfigurationsinfos wichtigen infos), GetConfig, SetConfig (Ein / Ausgabe von den Configs)

Im detail läuft ein module vorgang so ab:
Code:
  1.  
  2. Modul.Initialize;
  3. Modul.SetConfig;
  4. Stopped := False;
  5. while (Modul.Run and (not Stopped)) do
  6. begin
  7.   SwapBuffers()
  8. end;
  9. Modul.Kill;
  10.  


Modul run sieht ungefähr so aus, als beispiel:

Code:
  1.  
  2. function Run : Boolean; stdcall;
  3. begin
  4.   // In die Modelansichtsmatrix wechseln
  5.   glMatrixMode(GL_MODELVIEW);
  6.   // Identitätsmatrix laden
  7.   glLoadIdentity;
  8.   // Farb- und Tiefenpuffer löschen
  9.   glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT);
  10.  
  11.   // Camera
  12.   gluLookAt(0, 0, 400, 0, 0, -400, 0, 1, 0);
  13.   glRotatef(gRotCount, 0, 1, 0);
  14.  
  15.   // Den Mega Cube rendern
  16.   DrawUltraHyperCube;
  17. end;
  18.  


Jo hoffe mal das ihr was mit anfangen könnt, werde später vielleicht bissel beispiel code basteln.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Jun 29, 2005 18:56 
Offline
DGL Member
Benutzeravatar

Registriert: Sa Dez 28, 2002 11:13
Beiträge: 2244
Zitat:
Bisher hat noch keiner einen Modul Vorschlag näher ausformuliert(in diesem Wiki Artikel).
Ich will ja nicht kleinlich sein aber vielleicht wäre es praktischer, wenn man sich auf ein Medium beschränkt. Ich kann mich da an diverse Forenthreads erinnern in denen bereits Vorschläge gesammlt wurden. Ich frage mich gerade allen ernstes welche Sammlung an Ideen und Vorschlägen als nächstes neu gemacht wird.


Verstehe auch nicht, warum alles immer wieder neu diskutiert wird. Ich hatte doch vor einiger Zeit mal einen sehr flexibelen Entwurft gemacht.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Jun 29, 2005 20:20 
Offline
DGL Member
Benutzeravatar

Registriert: Do Jun 19, 2003 10:44
Beiträge: 991
Wohnort: Karlsfeld (nahe München)
LarsMiddendorf hat geschrieben:
Verstehe auch nicht, warum alles immer wieder neu diskutiert wird. Ich hatte doch vor einiger Zeit mal einen sehr flexibelen Entwurft gemacht.

Nicht neu diskutieren. Sammeln! Alles ist in irgendwelchen Threads verteilt. Ein Wiki Artikel könnte das auffindbar speichern.
Also wenn jemand eine Idee hat oder schon hatte, so stellt sie doch auch einfach ins Wiki. (z.B. in den Artikel DGL Benchmark, oder in einen verlinkten Artikel)

Also ich hab zumindest nicht mehr den Überblick!

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 Jun 30, 2005 08:11 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 05, 2002 10:35
Beiträge: 4234
Wohnort: Dortmund
Zitat:
Ohne DLL hätten wir bei 10 Modulen: 10*3 + 3 = 33 Downloads; oder 36 wenn man ein Komplettpaket auch noch anbietet.

Du meintest bestimmt mit DLLs. Aber ganz ehrlich. Ich denke du verstehst da etwas nicht. Nur weil man eine Plugin Schnittstelle einbaut heißt das noch lange nicht, dass man alles Plugins einzeln anbieten muss. Über einen Webinstaller könnte man so etwas auswählbar gestalten. Gimp hat reichlich Plugins und die haben komischerweise nicht solche Probleme. Die bieten das auch nur als ein Paket an. Evtl das ein oder andere noch als erweiterung. Zip macht es möglich. Denk mal drüber nach was du hier versucht für Argumente vor zu bringen.

Zitat:
Welcher Benutzer mit einer geringen Bandbreite zieht sich nach der kleinsten Änderung wieder die nächste Datei runter? Das machen nur Programmierer und die haben mit einer Versionkontrolle bei der nur die Zeilenänderung heruntergeladen wird definitv den geringsten Traffik im vergleich zu 100-1000 kb einer DLL.

Ist das nicht ein bisschen viel Aufwand für den jenigen der es benutzen will. Wie viele Entwickler arbeiten mit dem gleichem System? Kaum einer. Fast alle haben unterschiedliche Systeme. Und die Programme die ich nur als Quellcodepaket herunterladen kann und dann Tage lang am rumprobieren um es wenigstens Halbwegs kompilierbar zu gestalten die hasse ich wie die Pest. Die fliegen gleich wieder runter. Wir sollten schon drauf achten, dass es überhaupt jemand benutzen kann der nicht daran mit entwickelt hat.

Abgesehen davon. Es war ja auch mal im Gespräch, dass die Resultate alle in eine Datenbank geschrieben werden und dann online zugänglich sind. Wie will man sicher stellen, dass die Resultate auch nur ansatzweise Vertrauenswürdig sind wenn jeder das Programm erst einmal kompilieren muss. Auch wenn nichts verändert wurde besteht ein Unterschied zwischen en Kompilern und somit bekommt man auch immer unterschiedliche result. Vor allem wenn es bei einem im Debugger läuft und bei anderen nicht.

Mich als Entwickler würden aber hauptsächlich bloß die Unterschiede zwischen den einzelnen Methoden machen. Und dann evtl zu einem oder zweien der Code wie es gemacht wurde. Aber dazu bräuchte ich bloß eine Quellcode Datei und wenn die sogar noch deutlich von dem Rest getrennt wäre, dann würde ich das viel besser finden als wenn ich mich durch 300 Dateien durchwühlen müsste.

Schnittstelle: Ich denke mal man sollte die nicht anhand von 5 Modulen aufbauen. Man sollte sich schon überlegen was alles passieren kann. Dabei darf es ruhig ein wenig utopisch werden. Und dann versucht man einen Mittelweg zu finden. Dabei genügen aber Anwendungsfälle und keine konkreten konzepte. Außerdem würde ich die Schnitstelle erweiterbar gestalten. Also man macht in der DLL eine Methode die eine Schnittstellenversion (Bitset oder sonst etwas) zurückgibt. In dieser Version ist dann kodiert welche Schnittstellen alle unterstützt werden. Und anhand von der Version lädt man dann 3 Methoden und in Version + 1 ist halt noch eine zusätzliche hinzugekommen. Das prinzip könnte man auch mit dem von OpenGL Vergleichen in der die Version ein Text ist. Also der Extensionstring. Aber so komplex muss es ja gar nicht werden. Und somit würde man sehr einfach ein system erhalten was im Zweifelsfalle dann später noch erweiterbar wäre.

Bei der Rückgabe der Werte würde ich keine komplexen Strukturen zurückgeben sondern es modular gestalten. Also wenn man die Möglichkeit hat Integer, Floats, Texte und evtl Bilder in eine Baumstruktur einzuordnen sollte das für so ziemlich alle Anwendungsfälle ausreichen.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Jun 30, 2005 09:23 
Offline
DGL Member
Benutzeravatar

Registriert: Do Jun 19, 2003 10:44
Beiträge: 991
Wohnort: Karlsfeld (nahe München)
Wie gesagt alles obere ist etwas, was man Diskutieren kann, und wahrscheinlich auch so und so sehen kann, mich stören vorallem die untern zwei. Wobei ich mir das heute nochmal überlegt habe. DLLs schließen ja ein Versionskontrolle system nicht aus, ganz im Gegenteil es würde sogar sinn machen dort eines zu benutzen. Dann wäre es zum Beispiel möglich Tests die geleichen Ressourcen nutzen zu lassen auch wenn sie von zwei Leuten programmiert werden. Ein Versionskontrolle system macht soetwas erst möglich.

Zitat:
Ist das nicht ein bisschen viel Aufwand für den jenigen der es benutzen will. Wie viele Entwickler arbeiten mit dem gleichem System? Kaum einer. Fast alle haben unterschiedliche Systeme. Und die Programme die ich nur als Quellcodepaket herunterladen kann und dann Tage lang am rumprobieren um es wenigstens Halbwegs kompilierbar zu gestalten die hasse ich wie die Pest. Die fliegen gleich wieder runter. Wir sollten schon drauf achten, dass es überhaupt jemand benutzen kann der nicht daran mit entwickelt hat.

Da kann ich dich beruhigen. Ich glaube nicht das du da lange rumprobeiren musst um es kompilebar zu haben. Dank Compilerdirektiven können Quelltexte so gestalltet werden das sie sich ohne Problemme auf einen anderen System compilern lassen. Gerade hier ist ein Versionkontrolle system wieder von Vorteil, denn hier kann jemand mit der gleichen Plattform ebenfalls an dem Prolbem arbeiten. Ich würde sagen wir machen das einfach zur Bedinung für neue Moduelle das sie sich zumindestens mit Delphi und Freepascal unter Windows, sowie mit FreePascal unter Linux compilern lassen.

Zitat:
Abgesehen davon. Es war ja auch mal im Gespräch, dass die Resultate alle in eine Datenbank geschrieben werden und dann online zugänglich sind. Wie will man sicher stellen, dass die Resultate auch nur ansatzweise Vertrauenswürdig sind wenn jeder das Programm erst einmal kompilieren muss. Auch wenn nichts verändert wurde besteht ein Unterschied zwischen en Kompilern und somit bekommt man auch immer unterschiedliche result. Vor allem wenn es bei einem im Debugger läuft und bei anderen nicht.

Gut das du das Ansprichst! Wir dürften allgemein das Problem haben das wir:
a.) Für unterschiedlichen Betriebssstemen compilerte Programme haben
b.) Das wir die Ergebnisse erst dann beurteilen können wenn sie alle von ein und der geleichen Programm version kommen. Bei den DLLs müssen wir halt darauf aufpassen das keine DLL zwecks Fehlerkorrektur ausgetauscht wurde, bei einer Exe das es die richtige ist.

Punkt a könnte eher ein Feature werden da wir die Möglichkeit haben neben Hardware auch das Betriebssystem zu vergleichen. Bei Punkt B müssen wir es halt so machen das wir wenn das Projekt fertig ist eine Version für jedes Betriebssystem rausgeben die dann die "sichern" Daten sammelt.

@ Lossy Ex: Wenn wir eine Exe machen dann soll die natürlich auch Modular aufgebaut sein.

Zitat:
Schnittstelle: Ich denke mal man sollte die nicht anhand von 5 Modulen aufbauen. Man sollte sich schon überlegen was alles passieren kann. Dabei darf es ruhig ein wenig utopisch werden. Und dann versucht man einen Mittelweg zu finden. Dabei genügen aber Anwendungsfälle und keine konkreten konzepte. Außerdem würde ich die Schnitstelle erweiterbar gestalten. Also man macht in der DLL eine Methode die eine Schnittstellenversion (Bitset oder sonst etwas) zurückgibt. In dieser Version ist dann kodiert welche Schnittstellen alle unterstützt werden. Und anhand von der Version lädt man dann 3 Methoden und in Version + 1 ist halt noch eine zusätzliche hinzugekommen. Das prinzip könnte man auch mit dem von OpenGL Vergleichen in der die Version ein Text ist. Also der Extensionstring. Aber so komplex muss es ja gar nicht werden. Und somit würde man sehr einfach ein system erhalten was im Zweifelsfalle dann später noch erweiterbar wäre.


Schreib das doch ins Wiki :wink: ! Ansonsten geht das hier unter...
Zitat:
Bei der Rückgabe der Werte würde ich keine komplexen Strukturen zurückgeben sondern es modular gestalten. Also wenn man die Möglichkeit hat Integer, Floats, Texte und evtl Bilder in eine Baumstruktur einzuordnen sollte das für so ziemlich alle Anwendungsfälle ausreichen.

Ja eine Baumstruktur die solche Werte erlaubt dürfte reichen, das können wir ja mal als Maximum festsetzen ;).

Am besten wäre ein Format welches von einer Vergleichsanwendung eingelesen und ausgewertet werden kann. Also bei den Beispielen die ich ins Wiki gestellt habe, könnte man vorallem als Diagramm sehr gut darstellen. Das Format sollte natürlich so gehalten werden das es noch Möglichkeiten zur Erweiterung gibt.

MfG
Flo

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


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 3 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.110s | 15 Queries | GZIP : On ]