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

Aktuelle Zeit: Fr Nov 27, 2020 06:03

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



Ein neues Thema erstellen Auf das Thema antworten  [ 86 Beiträge ]  Gehe zu Seite Vorherige  1, 2, 3, 4, 5, 6  Nächste

Habt ihr Lust auf so ein Projekt ?
Kein Interesse 6%  6%  [ 1 ]
Nur anschauen 35%  35%  [ 6 ]
Ich möchte einen Raum erstellen 24%  24%  [ 4 ]
Ich möchte beim Framework helfen 18%  18%  [ 3 ]
Ich möchte helfen und einen Raum erstellen 18%  18%  [ 3 ]
Abstimmungen insgesamt : 17
Autor Nachricht
 Betreff des Beitrags:
BeitragVerfasst: Mo Feb 25, 2008 21:21 
Offline
DGL Member
Benutzeravatar

Registriert: So Feb 06, 2005 17:29
Beiträge: 187
Programmiersprache: C, C++
Hmm ich bin jetzt ein wenig desillusioniert, wenn das so schwer ist ein "einfaches" Framework bzw. wie ich jetzt gelernt hab wohl eher Starter auf die Beine zu kriegen :(
Ich hatte gehofft, dass es wirklich reicht allein eine Drawmethode auszulagern (vielleicht noch Keyevents fuer Interaktion), an Sound haette ich jetzt gar nicht mal gedacht. Ein Modelloader waere vielleicht noch nuetzlich gewesen, aber ansonsten einfach Beschraenkung auf simple OpenGL Sachen (mehr kann ich ja auch nicht :lol: )

Eine Kapselung wie Tak meint entspricht nicht dem was ich zu Beginn erwartet hatte, aber wenns nicht anders geht, muss man sich ueberlegen ob man es halt so macht, oder ganz sein laesst.

_________________
Flummi: Projektseite und Projektthread


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Feb 26, 2008 13:30 
Offline
DGL Member

Registriert: Mi Okt 16, 2002 15:06
Beiträge: 1012
Habe jetzt erst diesen thread entdeckt, keine ahnung welcher stand momentan ist, aber ich habe definitiv interesse daran mitzuhelfen.

Ich hatte mal vor nicht so langer zeit ein Progrämmchen geschrieben, welches eigentlich im grunde fast das ist was hier besprochen wird.
Nur sollte das als Benchmark dienen... hat aber funktioniert, zumindest bis OpenGL 1.1 standard -.-

Die Anwendung war folgendermassen aufgebaut:

Code:
  1.  
  2. benchmark.exe
  3.     data\
  4.         modules\
  5.             fillrate.bmp (Screenshot für die Benchmark liste)
  6.             fillrate.dll (Benchmark dll um die fillrate zu testen)
  7.             poly.bmp (Screenshot für die Benchmark liste)
  8.             poly.dll (Benchmark dll um polygon komplexität zu testen)
  9.  


Jede dll hatte die OpenGL commands über die Standard Delphi "OpenGL.pas" benutzt.
Das hatte wunderbar funktioniert, da ich den initialierungsvorgang über die Hauptapplication laufen hab lassen.

Aber hatte den nachteil, das ich max. OpenGL version 1.0 benutzen konnte und selbst texturen procs nachträglich laden hätte müssen.
Sprich shader wären so ohne weiteres nicht möglich gewesen :(

Ich habe das ganze noch, wer interesse hat dem ich das ganze gern erklären im gegebenfalls auch posten.


Hier ist auf jedenfall nen stückchen code der library:

Code:
  1.  
  2. library simple;
  3.  
  4. uses
  5.   Windows,
  6.   OpenGL;
  7.  
  8. const
  9.   cName = 'Simple Hello World';
  10.  
  11.   cDescCount = 4;
  12.   cDescs : array [0..cDescCount-1] of String = (
  13.   'Simple polygon with colors',
  14.   'by Finalspace',
  15.   'made with delphi',
  16.   'www.delphigl.com'
  17.   );
  18.  
  19. var
  20.   Durchlauf : Int64;
  21.   Freq      : Int64;
  22.   FrameTime : Double;
  23.  
  24. procedure GetName(var _Name : PChar); stdcall;
  25. begin
  26.   _Name := PChar(cName);
  27. end;
  28.  
  29. procedure GetDesriptionCount(var _DescCount : Integer); stdcall;
  30. begin
  31.   _DescCount := cDescCount;
  32. end;
  33.  
  34. procedure GetDesription(_DescIndex : Integer; var _Desc : PChar); stdcall;
  35. begin
  36.   _Desc := PChar(cDescs[_DescIndex]);
  37. end;
  38.  
  39. procedure Init(_Datapath : PChar); stdcall;
  40. begin
  41.   // OpenGL Standard Setup
  42.   glEnable(GL_DEPTH_TEST);
  43.   glDepthFunc(GL_LESS);
  44.   glDisable(GL_BLEND);
  45.   glBlendFunc(GL_ONE, GL_ONE);
  46.   glLineWidth(1.0);
  47.   glDisable(GL_LINE_SMOOTH);
  48.   glEnable(GL_TEXTURE_2D);
  49.   glClearColor(0,0,0,0);
  50.   glCullFace(GL_CCW);
  51.   glDisable(GL_CULL_FACE);
  52.  
  53.   Durchlauf := GetTickCount + 5000;
  54.   QueryPerformanceFrequency(Freq);
  55.  
  56.   FrameTime := 0;
  57. end;
  58.  
  59. procedure Kill; stdcall;
  60. begin
  61. end;
  62.  
  63. function Render(_Canceled : Boolean) : Boolean; stdcall;
  64. var
  65.   StartZ,
  66.   EndZ : Int64;
  67. begin
  68.   QueryPerformanceCounter(StartZ);
  69.  
  70.   // In die Modelansichtsmatrix wechseln
  71.   glMatrixMode(GL_MODELVIEW);
  72.   // Identitätsmatrix laden
  73.   glLoadIdentity;
  74.  
  75.   // Farb- und Tiefenpuffer löschen
  76.   glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT);
  77.   glLoadIdentity;
  78.  
  79.   glTranslatef(0,0,-4);
  80.  
  81.   glBegin(GL_POLYGON);
  82.     glColor3f(1,0,0); glVertex3f(-1.5, -1, 0);
  83.     glColor3f(0,1,0); glVertex3f(1.5, -1, 0);
  84.     glColor3f(0,0,1); glVertex3f(0.0, 1, 0);
  85.   glEnd;
  86.  
  87.   QueryPerformanceCounter(EndZ);
  88.  
  89.   FrameTime := (EndZ-StartZ)/Freq;
  90.  
  91.   Result := (not _Canceled) and (GetTickCount < Durchlauf);
  92. end;
  93.  
  94. exports
  95.   GetName name 'GetName',
  96.   GetDesriptionCount name 'GetDesriptionCount',
  97.   GetDesription name 'GetDesription',
  98.   Init name 'Init',
  99.   Kill name 'Kill',
  100.   Render name 'Render';
  101.  
  102. begin
  103. end.
  104.  
  105.  





Und eine idee hab ich da noch, wenn das nicht schon angesprochen wurde.
Im dem uralt game Serious Sam 1, da gab es eine genial einfache techdemo.

Man hat 2 grosse Pyramiden gehabt, wo per strasse verbunden waren, in jeder pyramide gabs räume und in jedem raum war immer eine andere technik demonstriert. In dem einen wurde Blending demonistriert, in dem anderen Lightmapping und Schatten, usw.



Es wäre überaus genial wenn das ähnlich machen kann, grosse pyramide (Haus, Halle, Raumschiff) mit vielen räumen wo jeder raum halt sone dll ist ;)
Das einzige prob wo ich da sehe, wie man das mit dem GL > 1.0 Einbinden macht, das die hauptapplikation und die dll´s auf die gleichen probs zugreifen.

PS: Schade das man nicht mehr abstimmen kann :(


Dateianhänge:
Dateikommentar: Screenshot des Benchmark tools (Unfertig)
dgl_benchmark_shotx.JPG
dgl_benchmark_shotx.JPG [ 35.95 KiB | 5921-mal betrachtet ]
Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Feb 26, 2008 14:05 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Mär 09, 2005 15:54
Beiträge: 372
Wohnort: München
Programmiersprache: Delphi, C#, FPC
Ich bins nochmal, wie Finalspace und ich bereits erwähnten, gab es in Serious Sam 1 eine Techdemo. Für alle, die das Game gerade nicht zur Hand haben oder es sich nicht eben installieren wollen, hab ich schnell ein 49sec-Video zur Inspiration erstellt.

Download gibts hier:
http://www.godlikesoft.de/images/external/Serious%20Sam%20Tech%20Demo.zip (5.5 MB) (tested with VLC)

_________________
Aktuelles Projekt: Gael - Development Blog
Website: LightBlackSoft.com


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Feb 26, 2008 16:06 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2576
Wohnort: Berlin
Programmiersprache: C/C++, C#
Bei Unreal3 haben die die Techdemo von Sam1 auch aufgegriffen und ein Weg mit allen besonderheiten gespickt.
Ich denke, man sollte die Räume und den Gang nicht gegenseitig einsehbar machen, vieleicht ein Portal, Beamplatform oder eine Tür, die man beim anklicken in den Raum gelangt. Wichtig ist auch zu beachten, dass ich und Oc2k1 z.B. c/c++ verwenden und man dabei die unterschiedlichen Header beachten sollte.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Feb 26, 2008 16:24 
Offline
DGL Member

Registriert: Mi Okt 16, 2002 15:06
Beiträge: 1012
TAK2004 hat geschrieben:
Bei Unreal3 haben die die Techdemo von Sam1 auch aufgegriffen und ein Weg mit allen besonderheiten gespickt.
Ich denke, man sollte die Räume und den Gang nicht gegenseitig einsehbar machen, vieleicht ein Portal, Beamplatform oder eine Tür, die man beim anklicken in den Raum gelangt. Wichtig ist auch zu beachten, dass ich und Oc2k1 z.B. c/c++ verwenden und man dabei die unterschiedlichen Header beachten sollte.


Jo, seh ich genauso... einfach ne simple tür könnte helfen ;)

Die Header werden dann halt auch für c/c++ sein, also sollte man es nicht gross Objekt orientiert basteln, sondern eher prozedural.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Feb 27, 2008 02:02 
Offline
DGL Member
Benutzeravatar

Registriert: Di Dez 03, 2002 22:12
Beiträge: 2097
Wohnort: Vancouver, BC, Canada
Programmiersprache: C++
Hi,

also... ich finde nach wie vor, mit einem simplen glPushAttribs und evtl ein paar extra-würsten ist es völlig getan.
Denn, was mich daran faszinieren würde wäre, dass ich im grunde ein stink normales OpenGL programm schreibe und das später einfach in den flur gepackt wird.. ich hab keine lust engine-spezifische sachen zu beachten, sondern einfach coden als wäre es nen normales programm.

Als alternative zu glPushAttribs würde mir noch einfallen einfach immer einen zweiten Offscreen-Rendering-Context für die räume zu erstellen. Die räume rendern dann in ihren eigenen Context und das MainProgramm nutzt nurnoch die fertigen Bilder.

Aya


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Feb 27, 2008 09:17 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 05, 2002 10:35
Beiträge: 4234
Wohnort: Dortmund
Also das mit den Attributen. Ich muss ehrlich gestehen, dass ich da keinen zu großen Aufwand treiben würde, denn um es perfekt und sicher hinzubekommen muss man einen imensen Aufwand treiben. Zu mal es mit Sicherheit immer irgendwo Lücken geben wird. Es genügt doch eigentlich wenn man sagt. Alles was gesetzt wurde muss auch wieder zurückgesetzt werden! Da die einzelnen Räume ja auch Texturen erstellen können müssen diese auch irgendwann wieder gelöscht werden. Das Gleiche gilt für Shader, VBO, FBO etc etc etc. Also muss jeder Raum eine Methode zum Initialisieren und zum Deinitialisieren bereit stellen. Das ist etwas wo ich die Verantwortung ganz klar beim Ersteller des Raumes sehe. Denn Texturen VBOs muss jeder Raum selber wieder frei geben. Das funktioniert über Push und PopAttribs nicht und würde sonst nur sinnlos den Speicher zufressen

Und falls sich da jemand nicht dran hält wird man das schnell feststellen, denn dann wird höchstwahrscheinlich die Lobby nach dem Verlassen eines Raumen nicht mehr so aussehen wie zuvor. Außerdem sind die Quellen der meisten ja Räume vermutlich ja auch öffentlich und wenn jemand etwas sieht wird er sicherlich so nett sein und es dann sagen. ;)

Engine: Man kann mit einer Engine nicht alle Anwendungsfälle abdecken. Und außerdem liegt dann der Lerneffekt nur bei den Leuten die das Framework erstellen. Denn alle Anderen wissen anschließend nur wie man erfolgreich diese Engine benutzt. Aber mit OpenGL hatten sie doch dann nichts zu tun.

Man kann und sollte den Entwicklern aber durchaus unter die Arme greifen. Also so etwas wie Texturen oder Modelle laden. Wenn man dort bereits Funktionalitäten zur Verfügung stellt, dann muss nicht jeder Raum so etwas selber implementieren, denn Texturen wird vermutlich mal jeder Raum benutzen. Falls man etwas anderes braucht kann man es immer noch selber einbauen. Also da sehe ich das Ideal eigentlich irgendwo in der Mitte. Das Framework sollte unterstützen und nicht dominieren. Denn dann ist es eine Arbeitserleichterung für Raumersteller. Nicht zu komplex und frustrierend für die Frameworker (ein halbfertiges Framework ist nur etwas für die Tonne). Und keine vollkommen abstrakte Schicht mit der man sonst nichts weiter anfangen kann.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Feb 27, 2008 10:51 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Jan 31, 2005 11:02
Beiträge: 432
Wohnort: Rheinlandpfalz
So wie Lossy sehe ich das auch.
Jeder Raumhersteller ist verantwortlich, die OpenGL-States so wieder zurückzusetzen, wie er sie bekommen hat.

So Sachen wie Texturen laden etc. könnte ich mir vorstellen, dass man das über das Framework laufen lässt.
Das Framework hat dann halt einen Texture-Loader (z.B die glBitmap), und man kann über einen Callback seine Texturen laden lassen, bzw. bekommt dann Indices auf diese zurück, und kann sie dann in seinem Raum einfach binden (evtl kann man dafür auch noch nen Callback machen).

Bzgl Models:
Ich denke es wird schwierig sein, das Model-laden in das Framework zu integrieren, da man sich dann auf ein Format/Loader einigen müsste, und man nicht mehr flexibel genug wäre...

Mit Sound ist das ne andere Sache. FMod kann man ja im Framework laufen lassen, und dann, ähnlich wie für die Texturen, den Räume Zugriff darauf geben.

_________________
http://texelviews.delphigl.com


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Feb 27, 2008 14:05 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
MatReno hat geschrieben:
So wie Lossy sehe ich das auch.
Jeder Raumhersteller ist verantwortlich, die OpenGL-States so wieder zurückzusetzen, wie er sie bekommen hat.

So würde ich das nicht sagen. Ich würde es eher so formulieren, dass man alles wieder ausschalten muss, was man eingeschaltet hat, sodass man davon ausgehen kann, dass alles ausgeschaltet ist, wenn man anfängt zu rendern. Das gilt dann auch für den Lobby-Renderer des Frameworks: Alles sollte auf aus sein, auch der Depth Test (wobei man sich darüber sicherlich streiten kann).

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Feb 27, 2008 15:43 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Jan 31, 2005 11:02
Beiträge: 432
Wohnort: Rheinlandpfalz
Lord Horazont hat geschrieben:
MatReno hat geschrieben:
So wie Lossy sehe ich das auch.
Jeder Raumhersteller ist verantwortlich, die OpenGL-States so wieder zurückzusetzen, wie er sie bekommen hat.


So würde ich das nicht sagen. Ich würde es eher so formulieren, dass man alles wieder ausschalten muss, was man eingeschaltet hat, sodass man davon ausgehen kann, dass alles ausgeschaltet ist, wenn man anfängt zu rendern. Das gilt dann auch für den Lobby-Renderer des Frameworks: Alles sollte auf aus sein, auch der Depth Test (wobei man sich darüber sicherlich streiten kann).


Das ist ja im Prinzip das selbe... man muss sich nur entscheiden, was default-mäßig aus ist, und was nicht.

_________________
http://texelviews.delphigl.com


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Feb 28, 2008 17:46 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Okt 03, 2007 14:22
Beiträge: 388
Was soll ich dazu schon sagen: Natürlich soll jeder seine Stats wieder zurücksetzen. Sonst hat ein Raum erstellen nicht mehr viel mit Programmieren zu tun sondern ist wieder Engine-basierend (in meinen Augen ist das zwar schon programmieren, aber viel zu automatisiert, sozusagen LaTeX-OpenGL, wobei ich LaTeX sehr gut finde). Wenn wir so etwas wie glBitmap nehmen, sollten wir uns drum kümmern, dass wir glBitmap auch mindestens bei Linux zum Laufen bekommen.

_________________
Meine Musik: spiker-music.net


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Feb 28, 2008 19:32 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 05, 2002 10:35
Beiträge: 4234
Wohnort: Dortmund
Nils hat geschrieben:
Wenn wir so etwas wie glBitmap nehmen, sollten wir uns drum kümmern, dass wir glBitmap auch mindestens bei Linux zum Laufen bekommen.

Das steht groß auf meiner Liste. Bin bisher nur noch nicht dazu gekommen es fertig zu stellen. Ich habe schon einen recht weitreichenden Support für SDL und Linux eingebaut. Allerdings alles noch nicht wirklich gut getestet bzw gibt es noch einige Stellen die noch komplett auskommentiert sind. Aber so etwas wie die Unit JPEG und Graphics sind optional bzw konfigurierbar.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Feb 29, 2008 10:32 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Jan 31, 2005 11:02
Beiträge: 432
Wohnort: Rheinlandpfalz
Lossy hat geschrieben:
Das steht groß auf meiner Liste. Bin bisher nur noch nicht dazu gekommen es fertig zu stellen.

Das freut mich! Dann gibt es keine Argumente mehr gegen glBitmap. :P

_________________
http://texelviews.delphigl.com


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Feb 29, 2008 11:02 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 05, 2002 10:35
Beiträge: 4234
Wohnort: Dortmund
Na ja. Aktuell sind da noch reichlich Baustellen. Und bevor ich mich da intensiv drum kümmern kann/werde muss ich erst die Fonts richtig veröffentlichen. Ich kann euch aber den aktuellen Stand als Developerversion zur Verfügung stellen. Damit sollten sehr viel von den typischen Sachen aber schon gehen. Also das bitte nicht zu euphorisch sehen. ;)


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Feb 29, 2008 18:04 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2576
Wohnort: Berlin
Programmiersprache: C/C++, C#
Mit den Stats finde ich, ist eine gute Lösung.
FMod direkt einzubinden und den Plugins zur verfügung zu stellen halte ich auch als brauchbare Lösung.
Ein Datenformat für Models mit zuliefern finde ich allerdings falsch.
Gerade bei Datenformaten gehen die Meinungen extrem auseinander, jeder hat andere ansprüche oder sogar eigene Formate mit bestimmten Features, da sollte man den pluginschreiber die Klinke in die Hand drücken.

Zum Thema Physik, wir sollten definitiv auf eine Fertige Lösung ala Newton, Ode, Bullet, Havok verzichten, denn erstens hab ich teilweise schlechte Erfahrungen mit der Kompatibilität gemacht(32bit/64bit,windows/linux) und dann kann es auch im Konflikt mit der Physikalischen Implementierung von z.B. Partikel oder ähnlichem, in einem Plugin stehen.
Wenn man sagt, im Gang soll Newton oder ähnliches genutzt werden und im Plugin kann man dann selber entscheiden ist auch keine Lösung, da sich sonnst das Verhalten des Akteurs verändern kann(reibung, laggs,geschwindigkeit,...).
Eine Routine zur erkennung von Kollision zwischen Spieler und Umwelt, Strahl und Umwelt, sowie eine einfache Reaktion auf Kollision sollte reichen.
So könnte man dann z.B. bei Kollisionen auf bestimmte Objekte die Reaktion erweitern.

Eine weitere Lösung, vieleicht auch die bessere wäre eine Kamerapfad im Raum(vom plugin festgelegt) und laufen im Gang(eine fertige Physiklösung oder eine eigene, die beim raum betreten abgeschalten wird). Aussehen könnte dann sowas wie folgt. Kamera startet und fliegt zu einem bestimmten Punkt und wartet, der User kann nun in alle Richtungen gucken und auch interagieren(wenn was verfügbar ist) und dann fährt die Kamera zum nächsten Punkt.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 86 Beiträge ]  Gehe zu Seite Vorherige  1, 2, 3, 4, 5, 6  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.082s | 20 Queries | GZIP : On ]