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

Aktuelle Zeit: Fr Nov 27, 2020 06:43

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



Ein neues Thema erstellen Auf das Thema antworten  [ 92 Beiträge ]  Gehe zu Seite 1, 2, 3, 4, 5 ... 7  Nächste
Autor Nachricht
 Betreff des Beitrags: [Benchmark] Planung
BeitragVerfasst: So Mär 27, 2005 19:36 
Offline
DGL Member
Benutzeravatar

Registriert: Do Jun 19, 2003 10:44
Beiträge: 991
Wohnort: Karlsfeld (nahe München)
Die DGL Gemeinschaft hat zwar eine ganze Menge schon zu bieten (z.B.: Tutorials, Wiki, News, Forum). Vor schon etwas länger Zeit kamm die Idee eines Community Projektes auf. Eine Disskusion ergab das wohl ein Benchmark Programm die beste Lösung sei. Ein Benchmark Programm bietet normalerweise die verschiedensten Test-Möglichkeiten die alle im weitesten Sinne voneinander unabhängig sind.

Das Projekt ließe sich also somit relativ leicht auf mehere Personen aufspalten, und auch noch im nachhinein erweitern.

Um das ganze mal in Gang zu bekommen, sollten wir uns zunächsteinmal folgende Fragen klären:

  1. Wie erreichen wir die Erweiterbarkeit

    a) Units/Quelltext Abschnitte
    Es gibt eine oder mehrere Haupt Units die gewisse Baisis Klassen oder Funktionen bieten. Diese Units werden dann als Grundlage für die Units der verschiedenen Module benutzt.
    Vorteile:
    * Basis Ressourcen wie zum Beispiel die DGLOpenGL.pas können gemeinsam verwendet werden.
    * evt. kann das Projekt Platform unabhängig werden.(Hier bitte ich diejenigen die sich damit auskennen sich mal zu melden)
    Nachteile:
    * Eine Erweiterung des Projektes erfordert ein erneutes Compilern.
    * Mehere Programmiersprachen sind nicht möglich

    b) Bibliotheken
    Hier stellt sich die Frage ob man wenn man dll verwendet nicht das Programm auf Windows beschränkt
    Vor und Nachteile verhalten sich genau andersrum.

    Staus: Hier hat sich gerade noch eine andere Möglichkeit aufgetan
  2. Welche Programmiersprache? (mehere?)
    Ich persönlich würde gerne einzelne Teile in C++ programmieren, da das in bezug auf Punkt 1a nicht mit Delphi vereinbar ist würde ich für eine reine Delphi Anwendung vorschlagen.

    Staus: Delphi(FPC compatibel) oder Delphi.net

  3. Welche Plattformen solen unterstützt werden?
  4. Wie wird der Quelltext ausgetauscht?
    a.) Download von einem Projekt Thread auf DelphiGL.com
    b.) Download von einer extra dafür erstellten Seite die auch eine Upload Funktion bietet.
    c.) CVS (Hierbei habe ich keine Erfahrung)
    d.) FTP

    Staus: Erstmal: Windows, Linux
  5. Unter welcher Lizenz soll das Programm stehen?
    Um die richtige Lizenz zu finden sollten wir folgende Fragen klären
    a.) Soll es ein OpenSource Projekt werden?
    b.) Wollen wir den Quelltext komerziellen Projekten zu verfügung stellen?

    Ich währe dafür das wir ein OpenSource Projekt machen und den Quelltext unter die GPL stellen. Hierbei wird zwar die Verwendung des Quelltextes auf OpenSource Projekte begrenzt, allerdings wird hierbei eine kommerzielle Nutzung der Ergebnisse des Programmes nicht ausgeschlossen. (Wir sollten das halt so wie bei Blender machen.)

    Staus: Noch nicht besprochen
  6. Wer würde was machen?
    Diese Frage sollte erst nach 1,2 und 3 angegangen werden. Zur Diskusion dürften hierbei Hauptprogramm, die einzelnen Module und nicht zuletzt aber eine vernünftige Dokumentation und Verwaltung sein(z.B. Eine eigene Website).

    Staus: Wird später diskutiert


MfG
Flo

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


Zuletzt geändert von Flo am Di Mär 29, 2005 16:43, insgesamt 11-mal geändert.

Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: So Mär 27, 2005 20:05 
Offline
DGL Member
Benutzeravatar

Registriert: Sa Dez 28, 2002 11:13
Beiträge: 2244
Ich hatte da ja mal vor ca 1,5 Jahren eine Version des Hauptprogramms erstellt, bei dem Module als DLL's jeweils mehrere Tests über Interface exportieren konnten und die Ergebnisse (Text,Bilder) dann nacher in so eine Baumstruktur einfügen konnten. Um einen neuen Test zu erstellen, mußte man nur von so einer Basisklasse ableiten, die sich bereits um die ganze Initialisierung,Zeitmessung,Screenshots usw... gekümmert hat, und ein paar Methoden überschreiben.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: So Mär 27, 2005 22:50 
Offline
DGL Member

Registriert: Do Apr 08, 2004 16:55
Beiträge: 516
Delphi ist mit .net Durchaus Platformunabhängig, kann somit auch verwendet werden!

_________________
Shareholder und Leitender Entwickler bei Pipedream-Games.

Zitat: Siehst du diesen Park da unten? Jeden Tag lernen sich darin Menschen kennen und verlassen einander. Und du hast dein ganzes Leben Zeit darin zu gehen.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: So Mär 27, 2005 22:56 
Offline
DGL Member
Benutzeravatar

Registriert: Sa Dez 28, 2002 11:13
Beiträge: 2244
Ja, die .Net Erweiterung vom Header ist auch schon weit fortgeschritten und es bleibt vorraussichtlich bei dieser einen Datei, so daß man damit dann komfortabler als mit tao und den ganzen Assemblies oder csgl programmieren kann. Ich bin auf jeden Fall auch für .Net . Am liebsten .Net 2.0 aber das geht ja leider (noch) nicht mit Delphi.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mo Mär 28, 2005 00:28 
Offline
Guitar Hero
Benutzeravatar

Registriert: Do Sep 25, 2003 15:56
Beiträge: 7772
Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
.Net ist denk ich keine gute Idee. Schließlich soll der Benchmark nicht auf allen System compilierbar sein, sondern auf möglichst allen Systemen laufen. Und das ist in Sachen .Net leider nicht der Fall. Viele haben kein .Net und werden sich nur für den Benchmark auch kein .Net installieren.

Ich bin dafür das klar zu trennen:

Der Benchmark sollte für die Entwicklungsphase eine Art SDK Form haben. Also aus erweiterbaren Bausteinen bestehen.
Die Kompilierte Anwendung sollte auf möglichst allen Systemen lauffen und ein Ergebnisfile ausspucken, welches man irgendwo auch mal hochladen kann.

Mit der Plattformunabhängigkeit ist das so ne Sache. Wenn man das will, muss man SDL mit ins Boot nehmen. Aber wie wirkt sich SDL auf OpenGL aus (zeitmäßig). Wenn das keine Probleme gibt sollte man SDL verwenden.
Wenn man externe Entwickler für das Projekt begeistern will wird wohl C++ benötigt werden. Find ich aber für uns als Delphi Gemeinde nicht akzeptabel. ;)

Also ich Sage: Delphi Code (FPC Compilierbar) + SDL

Damit läufts überall und das ist das wichtigste um effektiv Testen zu können.

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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mo Mär 28, 2005 09:38 
Offline
DGL Member
Benutzeravatar

Registriert: Do Jun 19, 2003 10:44
Beiträge: 991
Wohnort: Karlsfeld (nahe München)
Ich halte .net auch nicht für das Richtige.
Und zwar aus folgenden Gründen:
I.) Nicht jeder hat eine Delphi Version zu verfügung die .net unterstützt.
II.) Ich bin mir nicht sicher ob und wieviele .net Geschwindigkeitsverluste/Ergebnisabweichungen es geben könnte.
III.) Mir persönlich ist es unangenehm wenn Mircrosoft da seine Finger mit drinnen hat.(Interssante Diskussionen dazu auf Heise Online)

Ich schließe mich also weitgehend Flasch an, und wäre dafür das wir unser Projekt in Delphi programmieren, es FPC compilbar halten und nicht das .net Framework als Grundlage hernehmen.

Hat hier jemand schon Ansatzweise Erfahrung mit FPC, vielleicht sogar unter Linux?

Den Programm Aufbau stelle ich mir dann so vor.

Das Programm prüft beim Start ob OpenGL vorhanden ist, und präsendiert sich dann als reine OpenGL Anwendung.
Erweiterungen nutzen vorher programmierte Baisis Klassen, welche von OpenGL dann in eine Benutzeroberfläche umgewandelt werden.

In dem wir OpenGL als Oberfläche zum Anzeigen der Daten hernehmen sparren wir uns ein Wechsel vom normalen Fenster zum OpenGL-Vollbildmodus. Besonders die Test kleiner Module lassen sich somit leicht durchführen. Ein ander wichtiger Punkt ist das wir so an keine Delphi, (FPC?) oder Kylix Komponente gebunden sind!

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: Mo Mär 28, 2005 11:42 
Offline
DGL Member
Benutzeravatar

Registriert: Sa Dez 28, 2002 11:13
Beiträge: 2244
Naja bald gibt's ja die Delphi2005 PE Version. Dann hat jeder eine Delphi Version die .Net kann. Es gibt bei MSDN einen Artikel, der genau mit Beispielen die Funktionsweise der des JIT Compilers beschreibt. Dort kann man sehen, dass da Optimierungen durchgeführt werden, die der nomale Delphi Compiler nicht kann.
Das MS die Finger da drinn hat, kann man eigentlich nur als Vorteil sehen, weil sie ja bislang immer alles optimal gelöst haben und den Fortschritt vorran treiben. Man kann ihnen ja viel vorwerfen, einiges zu Recht und vieles zu Unrecht, aber bei .Net nun wirklich nicht. Da wurde jede Menge Quelltext freigegeben, damit diese Projekte auf den anderen Plattformen überhaupt entstehen konnten.
Gerade bei modularen Programmen ist .Net die richtige Wahl, weil das Exportieren von Klassen überhaupt gar kein Problem ist. Dank Reflection kostet es nur wenige Zeilen eine Assembly zu Laden und die Klassen auszulesen. Über die Attribute kann man zusätzliche Informationen an die Klassen, wie z.B. die Beschreibung des Benchmarks, heften. Man könnte die Benchmarkklassen auch teilweise im Quelltext dabeilegen und beim Programmstart kompilieren. Mehrere Programmiersprachen sind auch kein Problem. Das geht natürlich auch mit normalen DLL's, irgendwie und unschön.
Zitat:
Wenn man externe Entwickler für das Projekt begeistern will wird wohl C++ benötigt werden. Find ich aber für uns als Delphi Gemeinde nicht akzeptabel

C++ finde ich auch unschön. Aber zum Glück kann ja unter .Net jeder seine eine oder auch mehrere Lieblingssprachen benutzen. Wer auch unter .Net weiterhin Header Dateien pflegen will, kann das natürlich machen. Dieser ewige Zank um die Sprache ist jedenfalls vorbei.
Wie es mit .Net und SDL aussieht weiß ich nicht. Ich glaube da gibt's bereits eine SDL .Net.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mo Mär 28, 2005 11:50 
Offline
DGL Member
Benutzeravatar

Registriert: Sa Jan 04, 2003 21:23
Beiträge: 674
Wohnort: Köln
LarsMiddendorf hat geschrieben:
Wie es mit .Net und SDL aussieht weiß ich nicht. Ich glaube da gibt's bereits eine SDL .Net.

ist das überhaupt nötig, oder nimmt einem Mono bereits vielleicht ab? :-/

_________________
. . .


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mo Mär 28, 2005 12:14 
Offline
Fels i.d. Brandung
Benutzeravatar

Registriert: Sa Mai 04, 2002 19:48
Beiträge: 3812
Wohnort: Tespe (nahe Hamburg)
Also... das .NET plattformunabhängig sei, kann ich absolut nicht nachvollziehen. Mono leistet wahre Wunder, aber sobald jemand die VCL und damit die Windows-API verwendet sieht es zappen duster aus unter Linux. Will man daher vollends plattformunabhägig sein, so muss wohl SDL her halten. Hier könnte man das gleiche Argument wie mit .NET aufbringen, allerdings habe ich hier keine Probleme dem User zu sagen, dass er es sich gefälligst runter laden soll 8)
Ich habe bereits ein wenig Erfahrung mit SDL & FPC unter Linux gesammelt. Ist an sich nicht schwer das ganze so hinzumoddeln, dass es dann auf beiden Systemen läuft. Momentan haben wir noch das Problem, dass unsere Header unter Linux streiken, allerdings sitzt dort momentan ein Däne dran (fragt nicht :)). Er hofft, dass er es in den nächsten Wochen in den Griff bekommt. Danach können wir endlich beide Welten miteinander verbinden. Fakt ist jedoch, dass wir durch die Plattformunabhägigkeit den Tribut einer GUI zahlen müssen. Allerdings bastelte Delphic da ja auch IMAO etwas, vielleicht könnte man das recyln?
Was die Verwendung von DLLs angeht. Nun unter Linux gibt es ja ein Gegenstück (.so) ich habe allerdings keine Ahnung in wiefern man die beiden aneinander angleicht bzw. ob eine DLL mit fpc unter Linux kompiliert automatisch eine .so ergibt. Das gäbe es wohl noch einmal zu prüfen.

3. Plattformen: Sofern man sich für plattformübergreifend entscheidet, bleibt wohl nur zu sagen: soviele wie möglich. Auf der Basis von OpenGL, SDL und FPC sähe es da jedoch bereits schon ziemlich super aus. Die wichtigsten Unix-Derivanten wären dabei, sowie der MAC. Offiziell würden wir wohl wenn nur mit Bannern von Windows und Linux in der Schlachtziehen.

4. Wichtiger finde ich hier erst einmal die Frage nach der verwendeten Lizenz ;)
Da gerade am Anfang jemand den Überblick behalten sollte, würde ich den Austausch via FTP oder einer Webseite empfehlen. Nachdem ein Review vom Leiter gemacht wurde wird es dann zur Codebase eingefügt. Ob CVS hier Sinn macht? Sicher... allerdings wird meine Frage nach CVS immer mit "was ist das" beantwortet und wir hätten CVS wenn nur via SF oder meiner lahmen Krücke zu Hause im Angebot und die Frage wäre, ob wir nicht einige Windows-Nutzer ausschließen würden, denen CVS ein Fremdwort ist.

Des Weiteren fällt mir nur ein: Es wurde in früheren Gesprächen angedacht eine Datenbank anzubinden um Ergebnisse zu sammeln und anzubieten. Ich habe im Rahmen eines anderen Projektes bereits mit Linux recht erfolgreich HTTP-Abfragen realisiert. Die Windows-Lösung scheiterte nur an einer DNS-Auflösung mit der ich mich nicht weiter beschäftigte. Eine Lösung in diese Richtung ist daher möglich und sollte relativ leicht einfügbar sein.

_________________
"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: Mo Mär 28, 2005 13:42 
Offline
Guitar Hero
Benutzeravatar

Registriert: Do Sep 25, 2003 15:56
Beiträge: 7772
Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Nochmal kurz was zum klarstellen:

Der Benchmark soll die Leistungsdaten von OpenGL auf verschiedenen Systemen Testen. So soll z.B. getestet werden welche Statechanges in OpenGL wirklich Zeit kosten.

@DLLs: Finde ich unnötig. Wieso? Nur die Leute die am Benchmark programmieren benötigen Code. Der kann dann direkt über den Source verteilt werden. Windowsuser die Testen benötigen nur ne fertige Binary. Linuxuser die Testen ebenso. Das verteilen des Sourcecodes ist also eine alleinige Frage für die Programmierer. Wenn wir dann alle schön in Pascal proggen, egal auf welcher Plattform, ist die Bereitstellung des Codes kein Thema mehr. Es gibt dann auf nem Server ne UTypes.pas oder so zum Download, die alle nötigen Basisklassen enthält und darauf kann jeder entwickler dann aufbauen.

Die einzigste Frage ist, ob SDL gegenüber direkt erstellten Fensterhandles langsamer ist. Also: Bremst SDL ansich OpenGL?

Ansonsten:

- Delphicode FPC kompatibel
- SDL
- Ergebnissammlung auf Server
- Verteilung des Code über CVS als *.pas Files
- Verteilung des Programms als Binarys

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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mo Mär 28, 2005 14:00 
Offline
DGL Member
Benutzeravatar

Registriert: Sa Jan 04, 2003 21:23
Beiträge: 674
Wohnort: Köln
es war ja so gedacht, dass jeder User nen eigenen BEnchmark beitragen kann und wir deshalb auf das modulare System mit den DLLs gekommen waren, was ich prinzipiell auch gut finde (wenn das dann mit Linux noch klappt)

mit Leistungseinbußen durch SDL sehe ich keine Probleme, da die a) sehr gering sein dürften wenn überhaupt und die ja jeder hätte und dadurch ein Vergleich noch immer möglich ist.

_________________
. . .


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mo Mär 28, 2005 14:11 
Offline
DGL Member
Benutzeravatar

Registriert: Do Jun 19, 2003 10:44
Beiträge: 991
Wohnort: Karlsfeld (nahe München)
Eigentlich stehen wir nicht vor der Frage .net oder nicht sondern vor einer die damit aber eng zusammen hängt!

Die Frage ist nämlich wie soll unser Projekt aussehen?
1) Ist es wichtig, dass das Projekt, ohne erneutes compilern, erweiterbar ist? JA/NEIN 3 Pkt
2) Dürfen die Ergenisse des Programms unter Windows von anderen Windows-Programmen abweichen?JA/NEIN 2 Pkt
3) Wollen wir weitere Programmiersprachen zulassen(also nicht einheitlich Delphi)? JA/NEIN 3 Pkt
4) Können wir von den Nutzern erwarten das sie sich zusätzlich eine Datei über 23 MB runterläd und installiert? JA/NEIN 3 Pkt


Mit 6 oder mehr Punkten wäre dann .net besser geeignet.

MfG
Flo

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


Zuletzt geändert von Flo am Mo Mär 28, 2005 14:19, insgesamt 1-mal geändert.

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

Registriert: So Dez 19, 2004 00:27
Beiträge: 454
Wohnort: Nürnberg
ich denke, im Vergleich zu 3D Mark 05 (welches nur DX testet) wären 23 MB noch super


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mo Mär 28, 2005 14:31 
Offline
Fels i.d. Brandung
Benutzeravatar

Registriert: Sa Mai 04, 2002 19:48
Beiträge: 3812
Wohnort: Tespe (nahe Hamburg)
Die 23 MB sind dann aber nur reine Windows-Bibliotheken. Allerdings geht deine Rechnung so nicht ganz auf, da sie nur auf Windows abzielt. Mit .NET zahlen wir den Preis der Systemgebundenheit. Zum einen ist Mono in der Linux-Welt um einiges schlechter verbreitet als in der Windows-Welt. Ein auf Mono aufbauender Benchmark hat dort meiner Meinung nach kaum eine überlebenschance. Zudem gibt es IMAO keine vernünftigen SDL-Implementierungen für .NET. Ich glaube das TAO-Team arbeitet inzwischen an einer Implementierung. Würde sich nur Fragen, wie es dann mit der Implementierung unserer Header ausschaut. Zumindest, wenn ich es aufsummiere (und nicht falsch informiert bin, bzw. falsch Einschätze) würde eine .NET Entwicklung langfristig nicht auf anderen Plattformen sinnvoll laufen.
@dlls: Ich denke durchaus, dass der Ansatz von Lars sinnvoll war, nämlich um dem ganzen ein Plugin-ähnliches System zu bieten und nicht dauernd neukompilieren zu müssen, wenn sich die Kernschnittstellen nicht verändert haben.
Die Leistungseinbussen von SDL und auch .NET sollten in jedem Fall sehr stark zu vernachlässigen sein. Niemand wird unseren Benchmark mehr auf einem 486 ausprobieren und zumindest bei SDL den einen Funktionsaufruf darinne bemerken ;-) Es handelt sich ja nur um eine Wrapper-Klasse, die die Befehle direkt an das darunter liegende System weiterreicht und UT2004 (Linux) wirkt nicht sonderlich langsam *g ;)

_________________
"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: Mo Mär 28, 2005 14:40 
Offline
DGL Member
Benutzeravatar

Registriert: Sa Dez 28, 2002 11:13
Beiträge: 2244
Ich habe gelesen, dass dotGNU weitaus besser als Mono sein soll, weil es von MS unterstützt wird. Angeblich soll man dort schon normale Windows Forms Anwendungen unter Linux laufen lassen können. Wenn das so ist, dann hat man bei .Net zusätzlich zu den ganzen anderen Vorteilen auch wirkliche Plattformunabhängigkeit. Auf SDL und eigene GUI mit OpenGL könnte man dann auch verzichten.
Bei den DLL's hat man eben den Vorteil, dass nicht alles zentral geregelt sein muß und die ganze Verwaltung viel einfacher ist. Zusätzliche Module kann man dann ja auch zum Download anbieten. Außerdem wollen ja anscheinend nicht alle Pascal benutzen.
Der Nachteil ist eben die schlechtere Anbindung. Es ist relativ umständlich im Hauptprogramm eine Basisklasse zu deklarieren mit Grundfunktionalität und die DLL's davon ableiten zu lassen. Dann muß man sich z.B. bei strings wieder um die Speicherverwaltung (sharemem oder Ersatz) kümmern und wie das unter Linux aussieht ist sicherlich noch eine ganz andere Sache. Unter .Net hätte man all diese Probleme nicht. Man kann desweiteren extrem leicht Scripte einbinden (c#,c++,js,vbs), die natürlich genau den gleichen Weg wie der Code aus dem normalen Programm nehmen und daher, für einen Benchmark sinnvoll, optimiert und schnell sind. Da so ein einzelner Test wie z.B. Statechanges bei Texturen recht wenig Quelltext hat, aber man sich natürlich jede Menge viele verschiedene Tests ausdneken kann und nicht unbedingt 100 DLL's im Ordner haben möchte, wäre es auch eine schöne Möglichkeit kleine Tests einfach als Quelltext dabeizupacken.


Zuletzt geändert von LarsMiddendorf am Mo Mär 28, 2005 15:04, insgesamt 1-mal geändert.

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 1, 2, 3, 4, 5 ... 7  Nächste
Foren-Übersicht » Sonstiges » Community-Projekte


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast


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