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

Aktuelle Zeit: Do Jul 18, 2019 00:02

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



Ein neues Thema erstellen Auf das Thema antworten  [ 35 Beiträge ]  Gehe zu Seite 1, 2, 3  Nächste
Autor Nachricht
 Betreff des Beitrags: OpenParty
BeitragVerfasst: Sa Apr 11, 2009 23:19 
Offline
DGL Member
Benutzeravatar

Registriert: Di Sep 20, 2005 13:18
Beiträge: 1054
Wohnort: Dresden
Programmiersprache: C, C++, Pascal, OPL
Hallo,

eigentlich wollte ich warten bis man wenigstens irgendwas sehen kann, aber irgendwie kitzelt es mir in den Fingern, aber für das Programmieren bin ich gerade zu müde, aber tippen geht noch ganz gut, deshalb möchte ich mein aktuelles Projekt kurz vorstellen.

Ich weiß nicht, ob es alle von euch kennen (in der letzten Zeit habe ich sogar die Erfahrung gemacht, dass es kaum jemand kennt - erstaunlicherweise): Mario Party. Meiner Meinung nach ein wahnsinnig geiles und lustiges Spiel. Nun denke ich natürlich nicht wirklich an Mario Party ranzukommen. Die Liebe für Details, die Fülle an Minispielen und die lustigen Karten sind echt eine Klasse für sich (meiner Meinung nach). Aber zumindest dient es als Inspiration und Ideengeber.

Nun für die, die Mario Party nicht kennen, möchte ich erklären, was MEIN Spiel können soll (nicht was Mario Party ist): Es soll eine der "bekannten" Minispielsammlungen sein. Nur dass es dazu etwas "Hintergrundspiel" gibt. Es gibt ein Spielbrett, wo man Charaktere drauf bewegt, wie bei Mensch ärger dich nicht. JA, es wird gewürfelt. ^^ Mein Avatar stellt so einen Charakter dar. Warum ich ihn SEHR einfach halte, erkläre ich später. Die Spielbretter sind dabei nicht wirklich eben. Es wird mehr von Plattform zu Plattform gehüpft. So ein Brettspiel dürfte ja einfach zu verstehen sein. ^^ Am Ende einer jeden Runde folgt dann ein Minispiel.

Nun zu der technischen Umsetzung. Die Minispiele werden über Module realisiert. Unter Linux nutze ich dazu shared libraries und lade diese zur Laufzeit mit "dl" nach. Deshalb schreibe ich die Module auch in C. Aber theoretisch sollte das auch mit Free Pascal gehen, das habe ich vor mir mal anzuschauen. Unter Windows möchte ich dlls nutzen - habe bisher nichts dazu geschrieben, aber ich kenne die nötigen Funktionen und stelle es mir relativ simpel vor. ;-) Keine Ahnung, ob MacOS auch ".so"s nutzt. Da ich SDL und OpenGL nutze, müsste es auch dahin portierbar sein. Die Bibliotheken sollen 6 Funktionen bereistellen:

- eine Funktion für die Rückgabe der Größe der benötigten Daten. Der Speicher wird von dem Spiel allokiert und der Bibliothek dann gestellt.

- eine Funktion für die Initialisierung der Daten. Sie bekommt einen Pointer auf den allokierten Speicher.

- eine Funktion wird die Berechnungen. Sie bekommt einen Pointer zu den Daten und wird in einer Schleife ausgeführt bis etwas anders als 0 zurückgegeben wird. Wichtig: Diese Funktion wird als extrathread ausgeführt: Es dürfen also KEINE OpenGL-Funktionen ausgeführt werden. Diese müssen in der nächsten Funktion ausgeführt werden.

- eine Funktion für die Grafik. Hier wird gezeichnet. Das Flippen macht das Spiel für einem. Deshalb keine FlipBufferFunktion aufrufen. Auch diese Funktion bekommt einen Pointer. Jedoch auf eine KOPIE der Daten. Der Grund ist, dass die Berechnungen und die Grafik parallel ablaufen. Doof, wenn etwas gezeichnet wird und sich "auf einmal" mitten in der Szene etwas ändert.

- eine Funktion für einen Reset der Daten nach dem Spiel. Auch hier gibt es einen Pointer auf die Daten.

- eine Funktion, die allgemeine Informationen zurückgeben sollte: Anzahl der Spieler, Schwierigkeitsgrad, etc.

Das ist schon alles. Die Minispiele sollten darauf achten nach der Resetfunktion schön wieder aufzuräumen und OpenGL so zu lassen, wie es ist. Man kann es, gerade weil es ja eine State Machine ist, schön durcheinander bringen. :roll:

Das "Brett" ansich wird durch eine XML-Datei repräsentiert. Hier mal ein Beispiel für so eine:
Code:
  1. <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  2. <openparty>
  3.   <objects>
  4.     <object name="feld" filename="feld.3dm" texture="feld.png"/>
  5.   </objects>
  6.   <design>
  7.     <skybox texture="skybox.png">
  8.       <position x="1.000" y="1.000" z="1.000"/>
  9.       <size x="1.000" y="1.000" z="1.000"/>
  10.     </skybox>
  11.     <set object="feld" type="blue" endfunction="blaues Feld">
  12.       <position x="1.000" y="1.000" z="1.000"/>
  13.       <rotation x="1.000" y="1.000" z="1.000"/>
  14.       <scale x="1.000" y="1.000" z="1.000"/>
  15.       <cameraposition x="1.000" y="1.000" z="1.000"/>
  16.       <camerarotation x="1.000" y="1.000" z="1.000"/>
  17.     </set>
  18.   </design>
  19.   <texts>
  20.     <text name="text1" language="german">
  21.       Hey, Pippi Langstrumpf
  22.     </text>
  23.     <text name="text1" language="chinese">
  24.       Hey, Pippi Langstlumpf
  25.     </text>
  26.   </texts>
  27.   <scripts>
  28.     <function name="blaues Feld">
  29.       setmoney(aktivplayer(),add(getmoney(aktivplayer()),3))
  30.       textbox({text1})
  31.     </function>
  32.   </scripts>
  33. </openparty>


Der erste Teil zeigt die verwendenten Modelle. Ich erstelle sie mit Wings3d, exportiere sie als rwx-Datei und lade sie dann in mein eigenes Format. Alle Modelle normiere ich auf 1. Aber das nur am Rande. Der zweite Teil zeigt das, was man sieht jedes SET-Objekt ist ein sichtbares Vorkommen eines Objektes. Das KANN ein Spielfeld sein oder nur Hintergrundgedöns. :-) skybox gibt die skybox an - sehr einfallsreich, ich weiß. :-P Zwischen den Text-Tags stehen Texte. Jeder hat einen Namen und kann in beliebigen Sprachen verfasst werden. Und zum Schluss noch <Script>. Hier werden in function-Tags Funktionen definiert. Die Scriptsprache ist eine eigene von mir erdachte mit gewissen Kriterien, die ich hatte, aber dazu später mehr, der kleine Ausblick muss reichen.

Im Moment bin ich bei einem Editor für Level, der "krüppelt" aber vor sich hin, weil man vieles machen muss, ohne dass man einen richtigen Erfolg sieht - sowas hasse ich. Aber im Endeffekt müsste es sehr einfach sein Spielbretter und Minispiele selbst zu erstellen. Und nun noch schnell was zur Grafik: Sie wird mit Absicht sehr simpel gehalten. Ich möchte, dass der Spieler sich in den Minispielen wiederkennen. Das bedeutet auch, dass IHR Charakter die Spiele mitspielt. Eine Kugel zu animieren ist das einfachste und für ein Minispiel schnell gemacht. ;-) Zur Steuerung: Wie bei einem Konsolenspiel soll die Steuerung über Gamepads erfolgen. Jeder Spieler besitzt dabei ein (mindestens virtuell) ein Gamepad mit zwei Steuerkreuzen und vier Buttons. In der Realität wird es aber auch möglich sein mit der Tastatur zu spielen. ;-) Übrigens habe ich einige einfache Bibliotheken u.A. für das Laden von meinen Modellen geschrieben, die der Minispieleprogrammierer auch gerne nutzen kann. Auch geplant ist eine Pakaetmanagerfunktion ähnlich wie bei Debiansystemen (apt-get, synaptic, aptitude, usw.), dass man sich Minispiele, Spielbretter, Minispielzusammenstellungen runterladen kann ingame. Von zwei Minispielen genutzte Dateien müssen so z.B. auch nur einmal existieren.

Zur Planung: Ich habe zum ersten mal ein Spiel von Anfang bis Ende wirklich GEPLANT und durchdacht. Das soll nicht bedeuten, dass ich noch Änderungen vornehme. Im Gegenteil: Die Skriptsprache so ist ziemlich jung. Bis vor einer Woche war ein Skriptassembler mein Favorit. :-P
Ich habe mir mit Xmind eine Mindmap erstellt. Hier gebe ich mal einen kurzen Einblick in meine Planungen. Sie ist noch etwas veraltet und meine neusten Ideen und Konzepte müssen noch rein und sie zeigt auch noch die alte Skriptsprache und keine XML Datei, aber ich denke das Prinzip ist klar.
Bild
Wenn ich mit meinem Editor ein wenig weiter bin, kann ich auch erste Bilder außer meinem Avatar anbieten. ;-)

LG Ziz

PS: Achja, ich hieß vorher Cyberpuer und hatte sone Explosion als Avatar also nicht wundern.

_________________
Denn wer nur schweigt, weil er Konflikte scheut, der macht Sachen, die er hinterher bereut.
Und das ist verkehrt, denn es ist nicht so schwer, jeden Tag zu tun als ob's der letzte wär’.
Und du schaust mich an und fragst ob ich das kann.
Und ich denk, ich werd' mich ändern irgendwann.

_________________Farin Urlaub - Bewegungslos


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Apr 14, 2009 18:22 
Offline
DGL Member
Benutzeravatar

Registriert: Di Sep 20, 2005 13:18
Beiträge: 1054
Wohnort: Dresden
Programmiersprache: C, C++, Pascal, OPL
Hach, irgendwie kommt man immer doch langsamer vorwärts als man eigentlich hofft. Zum einen sind es sone piepeinfachen Sachen (XML-Auslesen/-Schreiben), die einen aufhalten, wo man aber DIREKT nichts sehen kann und schon gar keinen Screenshots zeigen und zum anderen will ja auch die Freundin versorgt und der Haushalt gemacht werden. <_< (Und nebenbei wird auch studiert, aber das ist nun wirklich nicht so wichtig wie ein Spuel zu programmieren ^^)

Aber bald dürfte etwas zu sehen sein - die wichtigsten theoretischen Grundlagen sind gelegt und der erste Teil der XMl-Datei (Objects-Tag) kann auch schon gespeichert werden. :-D

Ich dachte mir, stelle ich mal kurz meine kleine, feine (und an manchen Stellen etwas hässliche) Skriptsprache vor: Die Open Party Language:

Die Definition von Funktionen erfolgt direkt in der XML-Datei, wie erwähnt, alles, was dann in den Function-Tags liegt, ist die Funktion. Die Main-Funktion wird am Anfang ausgeführt und vielleicht auch immer wieder, wenn sie terminiert, das überleg ich mir noch. :-) Da die Skriptsprache keinen DIREKTEN OpenGL-Einfluss hat, sondern maximal Objektpositionen, Rotationen, usw. ändern kann, kann sie auch super als Extrathread laufen. :-)

Natürlich bedarf es eigener Variablen. Diese müssen deklariert werden, das kann jedoch überall im Skript erfolgen mit folgenden Anweisungen:
Code:
  1. define_global_number(name)
  2. define_global_float(name)
  3. define_global_bool(name)
  4. define_local_number(name)
  5. define_local_float(name)
  6. define_local_bool(name)

Ich denke die Funktionen sind weitesgehend selbsterklärend.
Das benutzen einer Variable wird nun mit
Code:
  1. [variablenname]

praktiziert.
Wie man siehst gibt es bisher keinen Datentyp für Strings. Wie ich das genau löse, muss ich mir noch überlegen. Es wird in der XML-Datei einen Extrapart für Texte geben, wobei einem Textnamen verschiedene Texte verschiedener Sprachen zugewiesen werden kann. Ich denke, ich werde an dieser Stelle "Stringsvariablen" definieren, die nicht innerhalb eines Skripts, sondern nur innerhalb des Texts-Part definiert werdne können und über {textname} angesprochen werden können. So kann man auch schön unterscheiden. :-) Variablennamen können übrigens (fast) beliebige Zeichen enthalten - auch Leerzeichen!

Weiterhin bedarf es natürlich "Grundfunktionen". Ausdrücke, wie
Code:
  1. [var]=5+3*sin([var2])

wird es erstmal NICHT geben. Ich hab sowas zwar auch schon gelöst, aber im Moment ist es einfach zu viel Arbeit für zu wenig Erfolg. :-P Deshalb werde solche Dinge erstmal funktional rekursiv gelöst. D.h., der Ausdruck oben (abgesehen davon, dass ich nciht weiß, ob ich sin überhaupt mit einbaue) würde so aussehen:
Code:
  1. set([var],add(5,mul(3,sin([var2]))))

Meiner Meinung nach alles eine Frage der gewohntheit. :-D Es wird "add", "sub", "mul", "div" und "mod" geben.

Natürlich kann man auch selbst erstellte Funktionen nutzen. Mit
Code:
  1. exec(Funktionname)

Wie man sieht, kann man weder etwas zurückgeben, noch übergeben - aber wofür gibts dann die globalen Variablen? Ich denke, ich bau noch eine Funktion "isdefined(variablename)" ein, damit man zur Not etwas "nachdeklarieren" kann.

Booleanausdrücke werden auch durch Funktionen realsiert.
Funktionen, wie "bigger", "smaller" oder "equal" nehmen zwei Number- oder Floatausdrücke entgegen und liefern einen passenden Boolwert zurück. Btw. werden bei Übergabe von Floatausdrücken und Numberausdrücken die Numberausdürcke automatisch zu Floats und wenn man mit "set" einer Numbervariablen einen Floatwert zuweisen will, wird gerundet.
"or" "not" und "and" sind auch Funktionen, die zwei Boolwerte entgegen nehmen und einen entsprechenden Boolwert zurückgeben. Bei falscher Paramaterübergabe wird bei Werten GRÖßER Null "True" angenommen und bei Werten KLEINERGLEICH Null "False".

Es gibt nur eine Schleifen-Art:

Code:
  1. while (boolausdruck) do
  2. ...
  3. end

Ich denke, die Funktionsweise ist klar. Auch die IF-Anweisungen sind simpel:
Code:
  1. if (boolausdruck) then
  2. ...
  3. end
oder mit else
Code:
  1. if (boolausdruck) then
  2. ...
  3. else
  4. ...
  5. end


Noch ein paar Extrainfos. Groß- und Kleinschreibung ist bei den "normalen" Funktionaliäten unwichtig - nur Variablennamen und Funktionsnamen sind case sensitive.

Meine Aufrufe enden nicht mit ";". Das Ende eines Aufrufs lässt sich so schon ganz gut ermitteln. :-) Solange ich keinen Funktion "endxxx" bennen, komme ich auch nicht durcheinander. Man könnte dann sogar
Code:
  1. while(bollausdruck)doif(bollausdruck)thenexec("test")elseexec("test")end
schreiben und es würde funktionieren. ;-) Weil etwas anderes sieht der Interpreter im Endeffekt nicht.
Kommentare kann man übrigens mit \Kommentar\ einleiten. Das "/" hebe ich mir für eventuelle spätere bessere Implementierungen von der Division auf. ;-)

Zu guter letzt noch zur Erklärung zur Anbindung an das Spiel. Im Moment kann ja nur munter gerechnet, geschleift und verglichen werden. Es wird viele Skriptintere Funktionen für das Spielverhalten geben, wie z.B. "getplayermoney" oder "setplayermoney" mit ein bzw. zwei Parameter oder "getobjectposition", mit drei Parameter, die dann beschrieben werden bzw. das Gegenstück "setobjectposition". Auch werden die Funktionen nicht sofort ausgeführt. Wenn z.B.
Code:
  1. setplayermoney([spielernummer],add(getplayermoney([spielernummer],5)))
aufgerufen wird, kommt einen kleine Animation und erst an deren Ende wird das Skript weiter ausgeführt.;-)

Ich denke, das hier gab einen kleinen Ausblick in das Skriptgepläkel, in das man sich stürzen muss, wenn man über ein "normales" "Mensch Ärger dich nicht!" hinaus will. Natürlich wird es Leveleditorintern eine Möglichkeit geben Standardskripte direkt zuzuweisen. ;-)

So long
LG Ziz

_________________
Denn wer nur schweigt, weil er Konflikte scheut, der macht Sachen, die er hinterher bereut.
Und das ist verkehrt, denn es ist nicht so schwer, jeden Tag zu tun als ob's der letzte wär’.
Und du schaust mich an und fragst ob ich das kann.
Und ich denk, ich werd' mich ändern irgendwann.

_________________Farin Urlaub - Bewegungslos


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Apr 24, 2009 06:11 
Offline
DGL Member
Benutzeravatar

Registriert: Di Sep 20, 2005 13:18
Beiträge: 1054
Wohnort: Dresden
Programmiersprache: C, C++, Pascal, OPL
Ich bin wieder mal ein Stückchen weitergekommen. Nachdem ich es auch geschafft habe, ansprechende OpenGL-Leistungen unter Ubuntu 9.04 mit einem Intel-Chipsatz zu erhalten (der Xorg-2.6-intel-Server ist noch ein wenig buggy, WENN AUCH BESSER, aber halt kacke, wenn er abstürzt, nich?), indem ich einen Xorg-2.4-intel-Server aus Fremdquellen installiert habe, habe ich mich weiter an das Auswerten von XML-Dateien gemacht. Ist ja teilweise echt kompliziert und dabei wahrscheinlich nicht sonderlich schnell und man sollte wohl auch auf seine Syntax achten, sonst KANN es Probleme geben.
Sowas:
Code:
  1. <tag>
  2.   <tag>
  3.   ...
  4.   </tag
  5. </tag>
sollte man z.B. vermeiden. Für meinen Datentyp kommt sowas auch nicht in Frage, deshalb habe ich eine Unterstützung nicht eingebaut. Es wäre zwar möglich (ohne die Grundstrukur meiner XML-Bilbiothek zu ändern), aber dann müsste ich wieder irgendwelche Zeichenketten suchen und mitzählen, wie oft nun geschlossen oder geöffnet wurde und das nimmt ja alles wieder Zeit, nich? ;-)

Aber XML funzt nun und das Laden und Speichern einer Skysphere und der Objekte funzt schonmal:
Code:
  1. <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  2. <openparty>
  3.   <skysphere texture="skysphere.png">
  4.     <position x="0.000" y="0.000" z="0.000"/>
  5.     <size r="10.0"/>
  6.   </skysphere>
  7.   <objects>
  8.     <object name="stonelevel_blau" filename="stonelevel_blau.3dm" texture="stonelevel.png"/>
  9.     <object name="stonelevel_rot" filename="stonelevel_rot.3dm" texture="stonelevel.png"/>
  10.     <object name="stonelevel_frage" filename="stonelevel_frage.3dm" texture="stonelevel.png"/>
  11.     <object name="stonelevel_duell" filename="stonelevel_duell.3dm" texture="stonelevel.png"/>
  12.     <object name="stonelevel_luck" filename="stonelevel_luck.3dm" texture="stonelevel.png"/>
  13.     <object name="stonelevel_stern" filename="stonelevel_stern.3dm" texture="stonelevel.png"/>
  14.     <object name="stonelevel_start" filename="stonelevel_start.3dm" texture="stonelevel.png"/>
  15.   </objects>
  16. </openparty>

So sieht die XML-Datei bisher aus. Die Angabe "position" bei skysphere wird noch ignoriert, muss mir überlegen, ob ich es überhaupt zulasse sie vom Mittelpunkt wegzubewegen. Eher kommt noch eine Option hin, ob sie mitbewegt wird (wie es ja bei einem "echten" Himmel scheint) oder ob sie star bleibt. Auch wird es später (=wenn ich Lust habe ein derartiges Level zu erstellen :-P) auch die Möglichkeit geben eine skybox zu wählen - spart u.U. 0,001% Rechenzeit (^^), aber u.U. für Innenräume ganz interessant. Z.B. ein Spielfeld, dass in einer Lagerhalle sein soll. ;-)

Ich kann auch schon einen ersten Screenshot zeigen. Wie gesagt, kann man ja schon Objekte laden und im Moment bin ich soweit, dass man sich die Objekte anzeigen lassen kann, um sie dann irgendwohin einzufügen:
Anhang 2
Das Objekt bewegt sich eigentlich auch etwas, habe es so "belichtet", dass man es gut sieht. ;-) Mit [Tab] wird man dann das nächste Auswählen können. Hier zeigt sich wieder die Faulheit des Programmierers: Da es eine einfach verkettete Liste ist, kann man nur in eine Richtung springen. :-P Dieses zu sehende Objekt soll übrigens ein "Duell" hervorrufen, wenn man genau darauf landet. In diesem Fall sucht man sich einen Spieler aus und legt den Einsatz fest. Dann heißt es alles oder nichts für beide. ;-)
Auf dem anderen Screen sieht man, wie so ein Spiellbrett bisher aussieht. Es besteht genau genommen nur aus der Skysphere. ^^
Anhang 1

Außerdem habe ich wieder eine XMind-Map für euch. Sie ist nun komplett überarbeitet und alles, was da steht, ist bisher angedacht so umzusetzen:
Bild

Ich hoffe, ihr langweilt euch nicht zu sehr mit meinen Ergüssen. Bald dürfte das erste Spielbrett erstell- un zeigbar sein. Dann gehts an die Texteinbindung und zuletzt an's Scripten. ;-)

LG Ziz


Dateianhänge:
Dateikommentar: erste Ansicht des leveldesigners mit Skysphere
op_screen2.jpg
op_screen2.jpg [ 20.74 KiB | 13341-mal betrachtet ]
Dateikommentar: Auswahl-"menü" eines einzufügenden Objektes
op_screen1.jpg
op_screen1.jpg [ 17.67 KiB | 13341-mal betrachtet ]

_________________
Denn wer nur schweigt, weil er Konflikte scheut, der macht Sachen, die er hinterher bereut.
Und das ist verkehrt, denn es ist nicht so schwer, jeden Tag zu tun als ob's der letzte wär’.
Und du schaust mich an und fragst ob ich das kann.
Und ich denk, ich werd' mich ändern irgendwann.

_________________Farin Urlaub - Bewegungslos
Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Apr 30, 2009 08:46 
Offline
DGL Member
Benutzeravatar

Registriert: Di Sep 20, 2005 13:18
Beiträge: 1054
Wohnort: Dresden
Programmiersprache: C, C++, Pascal, OPL
Guten morgen,

ich habe mich gestern und heute (langweiligen Vorlesungen sei dank) nochmal an das Spiel gesetzt und bin bei dem Editor weitergekommen. Mittlerweile kann man die elementaren Sachen speichern und laden. Mir fiel irgendwann auf, dass ich garnicht geregelt habe, was mit Licht passiert - ein Hoch auf XML! Ich konnte gar nicht so schnell kucken, da war es eingebaut. Was fehlt nun noch, eh ich mal was RICHTIGES zeigen kann, was man "Spiel" und nicht "Leveleditor" nennen kann?

- Festlegung einer Reihenfolge
- weicher Übergang zwischen Steinen (in Vorraussicht auf das fertige Spiel)
- springender Spielcharakter als eine Art "Vorschau"
- Textverwaltung in XML-Datei
- Scriptverwaltung

Wenn ich diese (kleinen) Hürden habe, müsste ich mit dem "richtigen" Spiel beginnen können.

Mir fiel übrigens auch auf, dass ich sowas wie Items noch garnicht betrachtet habe. Aber das lass ich erstmal ganz außen vor und bau es dann ein, wenns soweit ist - habe ich schon erwähnt, wie BEGEISTERT ich von XML bin? ^^

Und hier noch ein Screenshot. Die spätere Level werden natürlich NICHT Eben und kreisförmig (LANGWEILIG!) und auch die Skysphere muss anders werden. <_<

Bild

Bevor jemand fragt: Die FPS hängen mit meiner mageren Hardware zusammen.:-P

Danke, dass ihr mein Projekt (zumindest scheinbar) verfolgt. Ich hoffe, ich kann irgendwann was zum Spielen anbieten. :-)
LG Ziz

_________________
Denn wer nur schweigt, weil er Konflikte scheut, der macht Sachen, die er hinterher bereut.
Und das ist verkehrt, denn es ist nicht so schwer, jeden Tag zu tun als ob's der letzte wär’.
Und du schaust mich an und fragst ob ich das kann.
Und ich denk, ich werd' mich ändern irgendwann.

_________________Farin Urlaub - Bewegungslos


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Mai 01, 2009 22:37 
Offline
DGL Member
Benutzeravatar

Registriert: Di Sep 20, 2005 13:18
Beiträge: 1054
Wohnort: Dresden
Programmiersprache: C, C++, Pascal, OPL
Hallo,

Um einen Eindruck zu geben, wie es UNGEFÄHR Aussehen wird, wenn man erstmal von a) nach b) hüpft im endgültigen Spiel, habe ich dieses kleine Youtubevideo erstellt. Qualität ist echt scheiße (das liegt nichtmal an der Kamera, die hat die 640x480 Pixle gut abgefilmt), sondern a YT. Aber egal, hauptsache, man sieht, was gemeint ist. Man sieht auch schön, wie man mit den simplen OpenGL-Lichtern schon schöne Effekte erzeugen kann. Hier sind 4 Lichter an vier "Enden des Kreises" platziert in weiß, blau, rot und grün. Aber hier erstmal der Link:
http://www.youtube.com/watch?v=EZstL5A0MKg

Um mich selbst zu zitieren:
Zitat:
- Festlegung einer Reihenfolge
- weicher Übergang zwischen Steinen (in Vorraussicht auf das fertige Spiel)
- springender Spielcharakter als eine Art "Vorschau"
- Textverwaltung in XML-Datei
- Scriptverwaltung

Die ersten drei Sachen sind somit abgearbeitet. ;-) Die Reihenfolge lege ich (BOAR, bin ich einfallsreich) mit Zahlen fest. Jedes "Set" hat nun eine eindeutige Nummer. Für ein simples von a) nach b) Gehüpfe u.U. nicht relevant aber spätestens, wenn WEICHEN ins Spiel kommen, wird es eng. Hier muss per Script ein Nachfolger auswählbar sein => eindeutige Bezeichnung notwendig => Nummer. ;-)

Nun mache ich mich an die Textausgabe/speicherung. Ein Text wird in der XML-Datei nun wohl so aussehen:

Code:
  1.   <texts>
  2.     <text name="text1">
  3.       <german>Dies ist ein Text in deutscher Sprache</german>
  4.       <english>This is the same text in English luanguage</english>
  5.       <latin>Ego stultus sum...</latin>
  6.     </text>
  7.     ...
  8.   </texts>


Im Script ruft man dann nur "text({text1})" (oder ähnlich) auf und schon wird das Text ausgegeben. Die gewählte Sprache wird eine eingestellte sein oder Englisch (oder was halt da ist, wenn nur Koreanisch existiert, dann halt das). Wobei ich überlege, ob man "Präferenzen" angeben kann: Erst deutsch, dann Englisch, dann Finnisch oder so...

Naja, so long
Ziz

PS: So, habe noch ein wenig rumgewerkelt. Laden und Speichern von Text geht nun. Jetzt muss man ihn nurnoch anzeigen können - aber nicht mehr heute. Heute tat es nurnoch Lorem ipsum. ;-)
Bild
Aber alles in allesm sollen so später einmal die Textausgaben aussehen. :-D Gute Nacht. Ziz

_________________
Denn wer nur schweigt, weil er Konflikte scheut, der macht Sachen, die er hinterher bereut.
Und das ist verkehrt, denn es ist nicht so schwer, jeden Tag zu tun als ob's der letzte wär’.
Und du schaust mich an und fragst ob ich das kann.
Und ich denk, ich werd' mich ändern irgendwann.

_________________Farin Urlaub - Bewegungslos


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Mai 06, 2009 18:57 
Offline
DGL Member
Benutzeravatar

Registriert: Di Sep 20, 2005 13:18
Beiträge: 1054
Wohnort: Dresden
Programmiersprache: C, C++, Pascal, OPL
Abend,

einiges hat sich getan. Soviel, dass man es garnicht sieht. :lol:
Das Laden von Texten geht nun einwandfrei, auch in beliebig vielen Sprachen, ich hab ein paar Speicherprobleme beseitigt (müssten theoretisch sogar alle sein ;-) ), jedes "Set" kann nun neben einer Nummer noch einen Namen haben, man kann an die Spielfigur ran/rauszoomen und die Anzeige von den Charakterwerten eingebaut. BISHER brauch man die zwar nicht, aber ich möchte die Skriptsprache nun doch schon in den Editor einbauen und eine Art Simulationsmodus in den nächsten Tagen auf die Beine stellen als würde man wirklich würfeln. Man gibt an, was man gerne Würfeln würde. :lol: Dann kann man gleich die beiden Triggerfunktionen testen, die aufgerufen werden, wenn die Figur ÜBER das Feld läuft oder da sogar stehen bleibt. :-) Ich habe auch einen Screenshot. Ich habe mich nun entschieden, dass man Münzen und Smaragden sammeln muss. Wer die meisten Smaragden am Ende hat (man kann sie kaufen, erduellieren, erspielen, in einem Glücksspiel gewinnen oder finden), gewinnt. Bei Gleichstand entscheiden die Münzen. Neben den hier zu sehenden Charaktersymbolen oben kommen dann noch bis zu 3 Items. Übrigens werden es nie mehr Symbole werden, weil das Spiel ja für maximal 8 Leute sein soll. ;-)
Bild
LG Ziz

Edit: Achja, ich habe auch das Skyspherebild geändert. Gegen eines, wo ich auch die Rechte habe, es nach Belieben weiterzugeben (Ist ein von der Nasa fotografierter Nebel ^^)

_________________
Denn wer nur schweigt, weil er Konflikte scheut, der macht Sachen, die er hinterher bereut.
Und das ist verkehrt, denn es ist nicht so schwer, jeden Tag zu tun als ob's der letzte wär’.
Und du schaust mich an und fragst ob ich das kann.
Und ich denk, ich werd' mich ändern irgendwann.

_________________Farin Urlaub - Bewegungslos


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mo Mai 11, 2009 13:24 
Offline
DGL Member
Benutzeravatar

Registriert: Di Sep 20, 2005 13:18
Beiträge: 1054
Wohnort: Dresden
Programmiersprache: C, C++, Pascal, OPL
Hallo,

wirklich viel ist nicht passiert, aber ehe es sich aufstaut und ich nicht weiß, wo ich beginnen soll, mache ich es hier lieber in kleinen Happen.

Ich habe Kleinigkeiten eingebaut und alle Voraussetzungen für die Implementierung der Skriptsprache gesetzt. So existiert nun schon jeder Spieler in der Theorie bzw. falls ein Skript sein Geld "umdisponieren" möchte. :-P
Ich zeige am besten mal einen Screenshot, wie es bisher aussieht. Ich habe auch mal die Schriftanzeige geändert, dass sie gut lesbar ist und die Gesichter entfernt. Es wirkte doch ZU überladen. Der aktive Spieler ist dabei leicht hervorgehoben. Die Münzen/Smaragde drehen sich.
Bild
Ich habe mich außerdem entscheiden, dass es in meiner Skriptsprache nur EINEN Datentyp geben wird: float. Ich denke, das reicht, da es nur wenig Berechnungen geben soll und somit kein zu großer Overhead entsteht, wenn man ganzzahlig mit Floats arbeitet.

Und, achja, ich habe einen Würfel eingebaut. Aber den muss man animiert sehen, den poste ich später mal. Sieht auf jedenfall lustig aus. :lol:

So long,
LG Ziz

Edit: So, habe den Würfel verschönert und ein Video gemacht. Viel Spaß beim Anschauen :-D
http://www.youtube.com/watch?v=yFkc3t0Ti10

_________________
Denn wer nur schweigt, weil er Konflikte scheut, der macht Sachen, die er hinterher bereut.
Und das ist verkehrt, denn es ist nicht so schwer, jeden Tag zu tun als ob's der letzte wär’.
Und du schaust mich an und fragst ob ich das kann.
Und ich denk, ich werd' mich ändern irgendwann.

_________________Farin Urlaub - Bewegungslos


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Mai 14, 2009 07:54 
Offline
DGL Member
Benutzeravatar

Registriert: Di Sep 20, 2005 13:18
Beiträge: 1054
Wohnort: Dresden
Programmiersprache: C, C++, Pascal, OPL
Hallo,

zu allererst einmal die Nachfrage, ob alle Mitlesenden den Edit von dem letzten Beitrag mitgekriegt haben. Wenn nicht, hier der Link, der hinzukam: http://www.youtube.com/watch?v=yFkc3t0Ti10

Aber darum ging es mir eigentlich heute nicht. Ich möchte heute einen kurzen Einblick in meine Gedanken geben bezüglich meiner Skriptsprache genauer gesagt, der Auflösung von Termen. Denn da drüber sitz ich gerade und obwohl ich so etwas schon zwei mal gelöst habe, stellt es einen doch immer wieder vor neue Herausforderungen. :lol:

Zu allererst einmal zu den zwei (prinzipiell grob zu unterscheidenden) Verfahren: Rekursiv und Iterativ. Bei den Erklärungen sei die Funktion für das Lösen eines Terms: "solve", welche einen Parameter "Term" (eine Zeichenkette) hat und eine Gleitkommazahl zurückgibt. Auch wenn Rekursion für Anfänger immer voll "boah" wirkt, ist es hier das einleuchtendste Verfahren und ist auch schnell realisiert. Idee: Man sucht von links beginnend nach dem niederwertigsten Rechenzeichen (Also + oder -, dann *, \ oder % (modulo für die Nicht-Cer), dann Klammern/Funktionen usw.), teilt den Term in zwei Hälften auf und wendet das Rechenzeichen auf solve von der linken und solve von der Rechenhälfte an. Ich denke die beiden nächsten Bilder verdeutlichen dies ganz gut:
Bild
Hier wird erstmal nur das Erstellen des rekursiven Baumes gezeigt. Es werden der Rekursionsanfänge aufgezeigt.
Bild
Hier wird nun das "Anwenden" der Rechenzeichen auf die einzelnen zurückgegebenen Werte gezeigt. Ich denke die Farben sind bei beiden Bilder selbsterklärend.

Dieses Verfahren ist cool und hat den Vorteil, dass es schnell und einfach realisierbar ist, ABER auch einen großes Pferdefuß: Rekursion in zu hohem Maße führt zu einem Stackoverflow. Angeblich unter Windows eher als unter Linux. Aber unter beiden früher oder später auf jedenfall. Was nun aber, wenn ich eine große komplizierte Formel mit vielen Klammern und so weiter habe? Dann kommt das zweite Verfahren besser weg. Das Iterative.

Idee hier hinter ist, dass ich von links nach rechts die höherwertigsten Rechenzeichen suche (wie oben also nur umgedrehte Reihenfolge) und einen Teilausdruck des Termes ausrechne. Das mache ich so lange, bis mein Term Atomar ist, also nur aus einer Zahl besteht.
Bild
Hier ist deutlich sichtbar (hoffe ich), dass hier erst Klammern, dann * und / und dann + und - behandelt werden, wohingegen das Vorgehen bei der Rekursion andersrum war. Naja, in Wirklichkeit auch nicht, da Rekursion das "Rückwärts" ja schon in sich drin hat irgendwie, aber das, was wir schreiben als Programmierer, hat in dieser eben jenen Reihenfolge zu erfolgen.

Kurz: Ich werde den iterativen Weg einschlagen, um Terme aufzulösen in meiner Skriptsprache. Nur gibt es dabei ein Problem. Bei der Rekursion brauch ich in dem Sinne keine Zwischenergebnisse. Wenn ich nun aber Iterativ, also in einer Schleife, immer wieder den Term nach hochwertigen Rechenzeichen durchsuche, muss ich die Zwischenergebnisse ja als Ersatz für den Teilterm reinschreiben (Siehe Abbildung, die roten Zahlen). Problem: Der Term ist ein String! Und eine Gleitkommazahl temporär in einen String umzuwandeln ist very unoptiomal und zudem u.U. auch ungenau. Also bringe ich den String zu erst in eine andere Form. Ich analysiere ihn. Dabei erstelle ich eine verkettete Liste. Bei obigen Beispiel sieht diese bei mir dann so aus:
Bild
Nun kann ich in jedem Iterationsschritt zwei Elemente löschen und eines zu einer Zahl "umwandeln" -> bei voller Floatgenauigkeit. :D
Nebenbei lässt sich das Interationsende auch ganz gut ermitteln: Dann gibt es nämlich kein Nachfolgeelement beim ersten Element. ^^

Ich hoffe meine Gedanken und Erklärungen waren einleuchtend und genug mit bunten Bildern untermalt. Danke, dass ihr mir zugehört habt, irgendwie hatte ich das dringende Bedürfnis das alles mal zu Bilde zu fassen. :lol:

LG Ziz

_________________
Denn wer nur schweigt, weil er Konflikte scheut, der macht Sachen, die er hinterher bereut.
Und das ist verkehrt, denn es ist nicht so schwer, jeden Tag zu tun als ob's der letzte wär’.
Und du schaust mich an und fragst ob ich das kann.
Und ich denk, ich werd' mich ändern irgendwann.

_________________Farin Urlaub - Bewegungslos


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: So Mai 17, 2009 15:52 
Offline
DGL Member
Benutzeravatar

Registriert: Di Sep 20, 2005 13:18
Beiträge: 1054
Wohnort: Dresden
Programmiersprache: C, C++, Pascal, OPL
Hallo

Ich habe weiter an meinem Term-Auflöser gearbeitet und, man mag es nicht glauben, er funktioniert. :-D
Folgendes geht nun:
- Addition, Subtraktion
- Multiplikation, Division (Mod fehlt noch, ist aber nicht viel. :-) )
- Klammern
- Variablen (wobei erst nach lokalen, dann nach globalen geschaut wird)
- Funktionen
Bei Funktionen gehen natürlich noch keine Selbstgemachten - die Skriptsprache ansich ist ja noch garnicht realisiert. Aber man kann beliebig viele Parameter übergeben und ein paar Standartfunktionen gibt es schon: Sinus, Cosinus, Tangens, Cotangens, Arkussinus, Arkuscosinus, Arkustangens, Arkuscotangens und Power. Außerdem sind Funktionen ohne Parameter Konstanten. Es gibt sogar schon eine: "pi" :-P

Zur Realisierung. Es gab ja viel hin und her zwischen Rekursion und Iterativ, am Anfang wollte ich nur Iteration machen, dann nur Rekursion: Kurz um: Es ist nun eine Hybride Technik geworden. :lol:
Iterativ wird nach Klammern und Funktionen ohne Klammern und Funktionen in sich gesucht. Wenn eine gefunden wurde, wird sie Rekursiv an sich selbst übergeben. Diese Funktion findet nun natürlich KEINE Klammern und Funktionen, lösst die Punkt- und Strichrechnung iterativ auf, gibt sie zurück, und die erste Instanz der Funktion ersetzt den Klammerausdruck durch den zurückgegebenen Wert und sucht nun ITERATIV nach neuen Klammerausdrücken bis keiner mehr gefunden wird, die Punkt- und Strichrechnung abgearbeitet wird und das Ergebnis zurückgegeben wird.

Zur Geschwindigkeit: Ich habe den Algorhytmus auf einem Intel Centrino bei 630 Mhz getestet. Der erste Testausdruck war "cotangens(arkuscotangens(10))". Natürlich kam stets 10 raus und die Geschwindigkeit betrug ca. 170.000 Berechnungen der Sekunde. Mein zweiter Ausdruck war
"cotangens(arkustangens(10))+2*3/10+(80*3,45-100)/3+25245^0,37". Hier kam 111,81 (gerundet) raus (darf gerne überprüft werden) und es wurden ca. 36500 Berechnungen die Sekunde durchgeführt.

Ich finde die Zeiten garnicht schlecht. Ich werde zwar nicht in JEDER Millisekunde ein Skript ausführen können, aber das getriggerte Ausführen wird nicht gemerkt werden. Und wenn doch hat das Spiel eh nur 0,1 FPS oder weniger. :-P

Ich hatte übrigens auch extrem mit Speicherlecks zu kämpfen, die sind nun aber alle geschlossen. Zum Glück. Scheiß Dinger. Verkettete Listen haben echt ihr Nachteile!

So long, schönen Tag noch, ich mach mich heute vieleicht noch an den Rest der Skriptsprache. Vielleicht gehe ich aber auch einfach mit meiner Freundin spazieren. ^^

LG Ziz

_________________
Denn wer nur schweigt, weil er Konflikte scheut, der macht Sachen, die er hinterher bereut.
Und das ist verkehrt, denn es ist nicht so schwer, jeden Tag zu tun als ob's der letzte wär’.
Und du schaust mich an und fragst ob ich das kann.
Und ich denk, ich werd' mich ändern irgendwann.

_________________Farin Urlaub - Bewegungslos


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Mai 19, 2009 13:43 
Offline
DGL Member
Benutzeravatar

Registriert: Di Sep 20, 2005 13:18
Beiträge: 1054
Wohnort: Dresden
Programmiersprache: C, C++, Pascal, OPL
Willkommen zu meinem ein-dreitägigem Monolog. Falls sich einige Fragen, warum ich so oft was schreibe, das hat zwei Gründe: Zum einen komme ich euch entgegen - ihr müsst weniger auf einmal lesen ^^. Aber vorallem komme ich MIR entgegen: wenn ich 2 Wochen warte, vergesse ich nur was und ihr seid die einzigen mit denen ich über dieses Projekt reden kann. Meine Freundin freut sich nur wenns bunt ist (immerhin, dahingehend treffen meine Spiele ihren Geschmack), meine Schwester ist sowieso stolz auf mich, auch wenns nur ein farbloser Cube ist (große Schwestern sind was tolles ^^) und der Rest meines momentanten Bekanntenkreises (Informatikstudenten) hat eher ein Interesse in Datenbanken, Netzwerke, Datenschutz und Sachen wir Ruby, PHP and so on. Alles sehr tolle Dinge, aber ich kann kaum jemanden mit OpenGL oder den Algorithmen dahinter vollplappern. Deshalb bin ich auch so froh, dass es dieses Forum gibt, wo auch Amateure ein wenig Anklang in ihren Projekten finden. So, aber genug rumgeschleimt, weshalb habe ich denn die letzten zwei Tage zu wenig von den Vorlesungen mitbekommen? Ich habe meine Skriptsprache praktisch vollendet. Nur "praktisch", da ich noch keine einzige Funktion für das Spiel eingebaut habe, aber die SPRACHE ansich steht.

Was kann sie?
- while-Schleife
Code:
  1. while (Boolausdruck)
  2. ...
  3. elihw

- do-Schleife (wie repeat until in Pascal)
Code:
  1. do
  2. ...
  3. od (Boolausdruck)

if-Statement:
Code:
  1. if (Boolausdurck)
  2. ...
  3. else
  4. ...
  5. fi


Variablen werden mit "define" deklariert:
Code:
  1. define(variable)

mit "set" kann man Werte setzen:
Code:
  1. set(variable,[variable]+1)

Erstes Parameter ist die Variable ohne eckige Klammern, dann kommt ein Term, in welchen Variablen durch eckige Klammern gekennzeichnet werden. Btw. sind auch Boolausdrücke nur Terme. Wie ich erwähnte gibt es bei mir nur float. Es funktioniert aber super. Auch wenn es "vielleicht" etwas gewöhnungsbedürftig ist. Funktionen werden mit geschweiften Klammern benützt:
Code:
  1.  
  2. {macheetwas,parameter1,parameter2}
  3. set(a,{sin,{asin,[a]}})
  4.  

die Parameter sind stehts ihrerseits Terme. Es muss nicht zurückgegegen werden. Standardrückgabewert ist 0.
Was gibt es noch zu der Sprache zu Sagen?
Es gibt eine Funktion "show" (OHNE geschweifte Klammern), die ist aber nur temporär zur Textausgabe. Später soll man mit ihr Texte aus der XML-Datei anzeigen können. Im Moment gibt sie nur Dinge auf der Konsole aus - so sehe ich, ob alles überhaupt funzt. Ansonsten habe ich ein paar mathematische selbsterklärende Funktionen eingebaut, aber das schrieb ich imho schon. Hier mal ein Beispielquelltext und die Ausgabe auf dem Terminal:
Code:
  1. define(alex);
  2. define(temp);
  3. set(alex,0);
  4. set(temp,0);
  5. while ([temp]<4)
  6.   set(temp,{power,[alex],2})
  7.   if ({trunc,[temp]}=0)
  8.     show(0)
  9.   else
  10.     if ({trunc,[temp]}=1) Show(1)
  11.       show(1)
  12.     else
  13.       show(Größer_als_1)
  14.     fi
  15.   fi
  16.   set(alex,[alex]+1);
  17. elihw

Ausgabe:
Code:
  1.  
  2. 0
  3. 1
  4. Größer_als_1
  5.  

Man sieht also, es geht.

Für die Variablen habe ich mir übrigens eine Baumstruktur überlegt, wo jeder Knoten theoretisch 256 Unterbäume haben kann, wobei die meisten aber NULL sein werden. So kann ich mit minimalen Speicherverbrauch (Ein Array von z.B. 256^4 wäre schon schweinegroß und würde nur variablen bis 4 zeichen zulassen) schnell die variablenwerte finden und setzen, da ich nur "schnell" den Baum entlangwandern muss. Gibt bestimmt bessere Wege, mit Variablen vorher raussuchen, durch Zahlen ersetzen und dann nurnoch in einem Array die Zahl wählen oder so, aber das ist mir zu viel Aufwand bei dem wenig Nutzen. Ich glaube das langsamste bei meiner Methode ist bei Anlagen einer Variable die Baumknoten auf "NULL" zu setzen. :lol:
Meine nächste Ziel wird wohl die Integration der Skriptsprache (mit einem "#include <script.h>" ist es getan ^^) in den Leveldesigner und dann Anpassungen, dass man Scripte in der XML-Datei hinterlegen kann, diese als Trigger- und Endfunction wählen kann, sie ausgeführt werden und es VIELE Funktionen für die Interaktion mit dem Spielbrett gibt.

Außerdem habe ich eine "Kleinigkeit" vergessen: Durchsichtite Objekte. Partikel sind kein Problem, die werden in Zukunft einfach am Ende gezeichntet werden (schön sortiert), aber bei meinen "Sets" habe ich es bisher nicht betrachtet... Werde wohl noch eine Farbe für Sets zulassen (einschließlich Alpha-Kanal) und in einer Vorsortierung alles so anordnen, dass zuerst die Objekte OHNE Alpha kommen von vorne nach hinten und dann die Sachen mit Alpha von hinten nach vorne. So ist es doch am performantesten? Da ich eine feste Anzahl an Sets habe, kann ich einfach ein Array von Pointer erstellen, welches ich stets mit Quicksort neu sortiere.

So, genug davon.
Ich melde mich dann in dem angegeben Intervall wieder.
LG Ziz

Edit: Oh, mir fällt gerade auf, dass ich aus Gewohnheit jeden befehl mit einem Semikolon beendet habe. Das ist garnicht notwendig. Aber Dinge, die meine Skriptsprache nicht kennt, werden einfach "übersprungen. So kann man theoretisch auch Kommentare setzen, nur sollte man dabei nicht Schlüsselwörter benutzen. Schon wenn man schreibt:
Code:
  1. set(a,0) Hier setze ich a auf Null

sucht er hinter dem "set" von "setze" nach öffnenden Klammern. :-D

_________________
Denn wer nur schweigt, weil er Konflikte scheut, der macht Sachen, die er hinterher bereut.
Und das ist verkehrt, denn es ist nicht so schwer, jeden Tag zu tun als ob's der letzte wär’.
Und du schaust mich an und fragst ob ich das kann.
Und ich denk, ich werd' mich ändern irgendwann.

_________________Farin Urlaub - Bewegungslos


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Mai 22, 2009 09:45 
Offline
DGL Member
Benutzeravatar

Registriert: Di Sep 20, 2005 13:18
Beiträge: 1054
Wohnort: Dresden
Programmiersprache: C, C++, Pascal, OPL
3 Tage sind vergangen. Was habe ich getan? Gestern war ich Pfandflaschen im Wert von 8€ sammeln. Aber ich glaube, das gehört hier nicht rein. :P
Ich habe gar nicht so viel geschafft. Objekte werden nun, wie angesprochen, vorsortiert. Die Szene wird dabei zwar nicht schneller - aber auch nicht langsamer. Zumindest nicht im Moment. Vielleicht gibt es ja noch ein paar Geschwindigkeitszuwachse, wenn ich mehr render. Im Moment ist es ja nur ein Kreis von der Seite, wo sich die Objekte nur minimal überlagern.
Ansonsten fiel Flash ein Fehler in meinem Bsp-Skript einen Beitrag weiter oben auf. Das "Show(1)" hinter dem einen if-Statement muss weg. Zum einen wäre es zuviel und zum anderen wird es aufgrund der Casesensitivität garnicht behandelt. Wie gesagt, alles, was meine Sprache nicht kennt, wird übersprungen.
Ich denke, ich werde sowas aber in Zukunft umgehen, indem ich meine Skriptsprache scheinbar caseinsensitive machen. Warum scheinbar? Die Sprache bleibt, wie sie ist, ABER beim Laden eines Skriptes aus der XML-Datei wird einfach jeder große Buchstabe klein gemacht. Da dies nur einmal beim Laden des Spielbrettes geschieht, gibt es auch keine Geschwindigkeitseinbuße in der Ausführung.
Außerdem habe ich, ich weiß nicht, ob ich es schon erwähnt habe, eine Neue "Art" von sets eingeführt: "ghosts". Sie werden mit <set type="ghost" ... > eingeführt, besitzen kein Bezug zu einem Objekt und dienen nur der Kapselung von Positions-, Rotations-, Skalierungs- und Kameradaten.
So kann man später z.B. mit
Code:
  1. {switchposition,[nr_eines_set],[nr_eines_ghost],500}
eine Animation hervorrufen, wo ghost die Positionsdaten von set bekommt und umgekehrt, und zwar in einer 500 Millisekunden langen Animation. Ob der Aufruf später nun genau SO aussieht und genau SO funktioniert, steht noch nicht fest. Ist auch unwahrscheinlich - warum, zeig ich, wenn ich an der Stelle der Implementation von diesen Dingen bin. Aber ich hoffe der Sinn von "ghost"-Objekten ist klar. Denn niemand will 3 (nur Position) oder gar 9 (noch mit Kameraposition und -rotation) Werte "von Hand" "frei Schnauze" eingeben. Das wäre so ein Rumgefrickel bis es klappt...

So long
Have a nice day
Ziz

_________________
Denn wer nur schweigt, weil er Konflikte scheut, der macht Sachen, die er hinterher bereut.
Und das ist verkehrt, denn es ist nicht so schwer, jeden Tag zu tun als ob's der letzte wär’.
Und du schaust mich an und fragst ob ich das kann.
Und ich denk, ich werd' mich ändern irgendwann.

_________________Farin Urlaub - Bewegungslos


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Sa Mai 23, 2009 23:58 
Offline
DGL Member
Benutzeravatar

Registriert: Di Sep 20, 2005 13:18
Beiträge: 1054
Wohnort: Dresden
Programmiersprache: C, C++, Pascal, OPL
Hallo,

dieser Beitrag wird das letzte sein, was ich heute mache, denn ich bin todmüde - mag aber trotzdem noch schnell erzählen, was ich gemacht habe. Ich bin wieder da, wo ich schon mal war. Klingt nach Rückschritt. Ist es aber nur im Ansatz. Ich bin gerade dabei die Skriptsprache neu zu implementieren und auch gut dabei. Grund ist eine Umstellung. Zwei Dinge wurden kritisiert. Nummer 1 war die Sache mit dem "Show(1)" an der falschen Stelle. Ich habe dies mal zu einer Kritik, dass case sensibilität nicht toll ist, umgedeutet. ^^ Zweitens wurden Funktionsaufrufe ala {func,1} als sehr unschön betrachtet. Beide Kritiken haben recht. Was ist nun neu? Mein erster Gedanke war einen Parser zu schreiben, der z.B. aus:
Code:
  1. SeT(vAr,sin(5))

Code:
  1. set(var,{sin,5})

macht. Wäre auch nicht das Probleme, nur könnte ich den String nicht direkt verändern, denn der String wäre im zweiten Fall ein Zeichen länger und zum anderen, könnte ich doch bei einem Vorparser gleich noch was ganz anderes machen. Bei uns in der Vorlesung nannte man das "lexikalische Analyse" (oder so ähnlich). D.h., das was ich bisher nur mit Termen gemacht habe, mache ich nun mit dem ganzen String und erstelle einen verkettete Liste, die das Programm darstellt. Vorteil ist, dass ich Sprungmarken von while, do, if, else, usw. schon vorspeichern kann. So muss ich sie nicht zur Laufzeit suchen. Allgemein geht das iterieren in der Liste schneller als in einer Zeichenkette. Es gibt also nur Vorteile. Bin da auch schon ziemlich weit. Die Liste wird richtig erstellt und kann auch schon ausgeführt werden - nur, dass ich bisher nur Funktionsaufrufe (im Stil {func,var1,var2,...,varn}) implementiert habe. Aber die Schleifen sind nun ja SO simpel zu machen. Das "komplizierteste" wird nun wohl in den lexikalischen Analyse anderwertig beschriebene Funktionen zu erkennen. Aber ein wirklich Probleme sollte auch das nicht werden.

LG Ziz

_________________
Denn wer nur schweigt, weil er Konflikte scheut, der macht Sachen, die er hinterher bereut.
Und das ist verkehrt, denn es ist nicht so schwer, jeden Tag zu tun als ob's der letzte wär’.
Und du schaust mich an und fragst ob ich das kann.
Und ich denk, ich werd' mich ändern irgendwann.

_________________Farin Urlaub - Bewegungslos


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: So Jun 14, 2009 01:02 
Offline
DGL Member
Benutzeravatar

Registriert: Di Sep 20, 2005 13:18
Beiträge: 1054
Wohnort: Dresden
Programmiersprache: C, C++, Pascal, OPL
Hallo,

ich habe mich lange (sind echt DREI Wochen vergangen?) nicht mehr gemeldet und das aus verschiedensten Gründen. Zum einen will ich niemanden nerven. Zum anderen ist aber auch nicht so übermäßig viel passiert. Viel Arbeit ging in ABENDfüllendes Suchen von kleinen Fehlern verloren. Was habe ich nun aber in den drei Wochen geschafft? Meine Skriptsprache, die sich ja ständig wandelt und wo ich gerne mal Arbeit von Tagen übern Haufen werfe, ist soweit fertig. Alles ist schön in einem Block von Token. Zudem habe ich mir eine Halb iterative, halb rekursive Auflösung von Termen überlegt. Sie funktioniert folgendermaßen. Wir bewegen uns auf einer indizierten Liste. Ich beginnen einfachheitshalber bei 1. Die Liste sehe folgendermaßen aus:
[10,+,7,*,3,/,8,*,(,3,+,5,),+,1]
Ich denke, es ist ersichtlich, dass dies der Ausdruck 10+7*3/8*(3+5)+1 darstellt.
Die Funktion für das Lösen des Termes sei "solveterm". Ich brauche vier Hilfsvariablen:
Summe wird mit "0" initialisiert und speichert die Aufsummierung.
Produkt wird auch mit "0" initialisiert und speichert die Zwischenprodukte.
lastrz speichert das letzte Rechenzeichen. Es ist '+', damit es neutral beginnt. ;-)
wert speichert den letzten ausgelesenen Wert. Der sei 0, ist aber eigentlich egal...
Der Grundgedanke ist, dass bei einem Rechenzeichen gerechnet wird, je nach den Werten von Summe, Produkt und lastvz und bei "allem anderen" wird wert gesetzt.
Los gehts!
1. [10]: wert:=10 (Ich denke das ist logisch)
2. [+]: Als letztes Rechenzeichen kam Strichrechnung, damit wird summe:=summe+wert (=10) gerechnet. lastrz sei (das neue) '+'
3. [7]: wert:=7
4. [*]: Als letztes Rechenzeichen kam Strichrechnung, damit wird produkt:=wert (=7), lastrz sei '*'
5. [3]: wert:=3
6. [/]: Als letztes Rechenzeichen kam Punktrechnung, damit wird produkt:=produkt*wert (=21), lastrz sei '/'
7. [8]: wert:=8
6. [*]: Als letztes Rechenzeichen kam Punktrechnung, damit wird produkt:=produkt*wert (=2,625), lastrz sei '/'
7. [(]: wert:=solveterm von 7 bis Ende (also 11), wird machen bei 12 weiter (wert=8)
12. [+]: Als letztes Rechenzeichen kam Punktrechnung, damit wird summe:=summe+produkt*wert (=10+2,625*8=31), lastrz sei '+'
13. [1]: wert:=1

Zu letzt wird nochmal "so getan", als ob noch ein Plus käme: summe:=summe+wert (=32)
Ich hoffe, ich habe mich nicht verrechnet und ich hoffe der rekursive Aufruf ist klar (bei Funktionen wird genauso verfahren), aber es ging ja nur ums Prinzip. Hauptsache es funktioniert und ist schnell: Und beides trifft zu! Bei einem Minus muss natürlich getrickst werden, aber das ist nicht weiter schlimm und auch logisch. ;-) Zudem musste ich mir erstmal ein Modulo für Floats überlegen :-D (Wen interessiert: x%y=(x/y-trunc(x/y))*y)

Außerdem habe ich meine Sckriptsprache um "Kleinigkeiten" erweitert. Ohne Stack gehen Funktionsaufrufe z.B. nicht, fiel mir irgendwann dann doch auf, Variablen sind eh ALLE Floats, also müssen sie nicht deklariert werden, bei der ersten Benutzung, stehen sie (mit dem Wert 0) zur Verfügung und so weiter. Außerdem optimiere ich dahingehend, dass jede öffnende Klammer z.B. "weiß", wo ihre schließende ist. So spare ich mir viel iterieren, auch wenn die Analyse mich viele besagte Nächte gekostet hat. Es scheint nun aber alles soweit zu funktionieren. Auch habe ich mir Gedanken um die Anwendung der Sprache gemacht. Man soll ja z.B. zwei Objekte gleichzeitig bewegen können, deshalb macht die Sprache prinzipiell NICHTS, erst wenn "sync" aufgerufen wird, pausiert das Skript und grafische Bewegungen werden gezeigt. Nach dem ENDE der Bewegungen wird ein Skript weiter ausgeführt bis "return". Außerdem wird man im Skript wohl auch Partikel erzeugen und steuern können. Genauso können in der XML-Datei Partikel schon definiert werden und ihre Berechnungsfunktion. Z.B. für Wolken, Vögel oder ein Flugzeug, das vorbeifliegt oder so ähnlich. Dabei bekommt die Berechnungsfunktion relativ viele Informationen über den Stack und meine Partikelengine kann den dann direkt auslesen. Wenn ich die Reihenfolge wie in der Partikelengine wähle, kann ich auch das böse, veraltete memcpy nehmen.

Was habe ich noch gemacht? Ich habe zwar leider kein Video davon, aber ich habe, wie schon angedeutet, eine, wie ich finde, recht performante, simple Partikelengine gebastelt. Sie kann Sprites oder auch eigene Zeichenfunktionen nutzen. Klein aber praktisch. ^^ Außerdem habe ich vieles überdacht, meine MindMaps aktualisiert und mit Joysticks rumgespielt. Meine "Hauptengine" (die sich um ALLES kümmert ^^ (windowmanagment, programmschleifen, events, xml, partikel, texturen, modells, etc.)) erkennt nun beim Start des Programmes alle Joysticks und bindet sie mir einfach ein, dass ich dahingehend nichts mehr machen muss. :-)

Zudem habe ich mir über das Leveldesignen nochmal überdacht. Mein Leveldesigner (von dem ich immer Videos zeige) ist wahnsinnig unpraktisch, um damit wirklich Level zu erstellen. Für Details reicht er, aber das Erstellen stinkt. Also habe ich mir gedacht, dass ich mir ein Bild nehme, wie das hier z.B.: Bild (zoomt ran, sonst sieht man garnichts ^^), und mit den Punkten so ein Level definiere. Damit ein Punkt als Set erkannt wird, muss er einen Grün-Wert von 0 haben. Die x-Koordinate wird zur X-Koordinate des Sets (natürlich anders skaliert. ;-) ), die y-Koordinate zur Z-Koordinate, der rot-Wert zur Y-Koordinate (128 ist 0.0000) und der blau-Wert gibt die Nummer an. Dauert zwar auch einen Moment so etwas in Gimp zu erstellen, geht aber UM LÄNGEN (Faktor 100 oder so ^^) schneller als es im leveldesigner "von Hand" zu machen. Außerdem habe ich mir noch ein paar Gedanken zum "Würfellauf" gemacht, wie man in dem Video sieht, dass auch das fertig aus dem Bild erzeugte Level zeigt.

So, ich hoffe, ich habe nichts vergessen, was noch spannendes in den letzten 3 Wochen passiert ist. Zumindest nichts, was mit Open Party zu tun hat ^^.

Morgen mache ich mich (vielleicht, aber wahrscheinlich) an die Planungen für ein erstes richtiges Spielbrett, wo ich mich dann mit der Scriptsprache zum ersten mal richtig Austoben kann. Wobei das wohl auch länger dauern wird. Was auch immer ich wähle (ich bin noch unschlüssig, aber die Ideen sind da), es braucht Modelle. Und woher nehmen, wenn nicht raubmordkopieren? ^^ Also werde ich morgen wohl auch noch ein paar Modelle erstellen. Ich hoffe, ich kann dann bald ein komplettes Spielbrett mit allem drum und dran zeigen.

Hier nun noch der versprochene Youtube-Link: http://www.youtube.com/watch?v=3fOGfIvoOok
Die Farben sind leider total daneben . Und zu dunkel. Achtet auf die Animationen und ignoriert den Rest. ^^

Ach und eine Sache noch.! Ich probiere gerade den neuen Kernel 2.6.30 aus. Er brachte bei mir ca. 50% mehr Grafikleistung in OpenGL!!!

LG Ziz

Edit: Weil die Qualität wirklich SEHR schlecht ist von dem Video, habe ich es nochmal gefilmt (bei mir Licht) und hochgeladen. Ein WENIG besser ist es, auch wenn es stockt, weil ich noch ein paar andere Sachen im Hintergrund laufen hatte...
http://www.youtube.com/watch?v=SRd3FIBbNGo

_________________
Denn wer nur schweigt, weil er Konflikte scheut, der macht Sachen, die er hinterher bereut.
Und das ist verkehrt, denn es ist nicht so schwer, jeden Tag zu tun als ob's der letzte wär’.
Und du schaust mich an und fragst ob ich das kann.
Und ich denk, ich werd' mich ändern irgendwann.

_________________Farin Urlaub - Bewegungslos


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Jul 03, 2009 19:51 
Offline
DGL Member
Benutzeravatar

Registriert: Di Sep 20, 2005 13:18
Beiträge: 1054
Wohnort: Dresden
Programmiersprache: C, C++, Pascal, OPL
Hallo,

einige kennen mich vielleicht aus Filmen wie "Och ne, nicht schon wieder der Monolog zu Open Party" oder "WTF? Der hat nen Award bekommen? LOL!". Kurz gesagt: Ich habe (für meine Verhältnisse) länger nichts geschrieben und möchte mich nun mal wieder zu Wort melden. ;-) Erstmal danke für den Award, ich hoffe, dass mein Projekttagebuch hier niemanden aufn Keks ging, zur Not kann man ja weglesen (komplementär zu "weghören").

Zu allererst habe ich ein kleines Youtubevideo für euch.
http://www.youtube.com/watch?v=mn1tC15tiWo

Ich habe ein neues Programm geschrieben, dass einmal eine "typische Spielsituation" nachstellen soll. Natürlich gab es (sehr) viel Copy und Paste, aber mein Code ist von Anfang an sauber(er), einige Dinge löse ich nun anders (ich hoffe besser) und einiges flog raus. Im Prinzip alles, was mit einem Leveleditor zu tun hat. Mein Aufräumaktion hat auch zur Folge, dass aus 6 Quellcode-Dateien z.B. 11 wurden und ich probiert habe vieles in Gruppen einzuordnen.

Mein leveldesigner hatte noch insgesamt 2500 Zeilen Code (Bibliotheken, die ich selbst erstellt habe und nutze nicht mitgerechnet) und mein neues Testprogramm nun nurnoch 1800 Zeilen und dabei habe ich noch einiges hinzugefügt (vorallem grafischer Natur).

Ich bin echt positiv überrascht, dass ich direkt meinen Bildschirm abfilmen kann (mit gtk-recordmydesktop) mit kaum Geschwindigkeitseinbußen. Damit bleiben euch in Zukunft abgefilmte eeePCs erspart. ^^ Ich denke, das Video ist größtenteils selbsterklärend. Was NICHT selbsterklärend ist, ist was jetzt noch kommt. Die Verbindung von meinem Spiel mit meiner Scriptsprache. Das wird eine ganze Menge Arbeit einnehmen. Wenn das geglückt ist, kümmer ich mich um den "Anfang" des Spieles. Also, wo jeder Spieler seinen Controller einstellt, die Anzahl der (CPU-)Spieler eingestellt wird usw. Und DANN bau ich ein paar (3 bis 5) Minispiele ein. Dann dürft ihr auch Testen. Ich hoffe das alles noch in diesem 3. Quartal zu schaffen. Aber wahrscheinlich wird meiner Zeit eingeschränkter sein als mir lieb ist. :-/ Aber es müsste machbar sein. Ich verspreche auch mich mehr zurückzuhalten was News angeht. :-D

LG Ziz

_________________
Denn wer nur schweigt, weil er Konflikte scheut, der macht Sachen, die er hinterher bereut.
Und das ist verkehrt, denn es ist nicht so schwer, jeden Tag zu tun als ob's der letzte wär’.
Und du schaust mich an und fragst ob ich das kann.
Und ich denk, ich werd' mich ändern irgendwann.

_________________Farin Urlaub - Bewegungslos


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Jul 31, 2009 22:45 
Offline
DGL Member
Benutzeravatar

Registriert: Di Sep 20, 2005 13:18
Beiträge: 1054
Wohnort: Dresden
Programmiersprache: C, C++, Pascal, OPL
Hallo,

es ist schon wieder einige Zeit vergangen und ich habe mich gerade durchgelesen, wo ich stehengeblieben bin. Ich kann nicht glauben seit dem nichts geschrieben zu haben. :-D Ihr wahrscheinlich auch nicht... ^^ Ich konnte die letzten Wochen leider nicht so programmieren, wie ich gerne gewollt hätte, da ich Prüfungen hatte und auch noch habe. 5 hinter mir, 2 noch vor mir. Das schönste zum Schluss. Aber Abends nach 23:00 kann ich eh nicht mehr lernen und durch die Prüfung knall ich so oder so, da kann ich noch schnell ein Video aufnehmen und mal wieder schreiben.
Erstmal das soweit wenig aussagende Video:
http://www.youtube.com/watch?v=yqGvuN4wBk8
Dem geschulten Auge fällt auf, dass die FPS runter gegangen sind, aber es trotzdem flüssiger läuft. Ersteres hängt damit zusammen, dass der Boden nun kein 1x1-Quad mehr ist, sondern ein 32x32-Netz mit ein wenig Gelände. Also 1023 neue Quads, wenn man so will. Schande auf mein Haupt: Bisher fehlen Optmierungen wie Oct-Tree. Ich denke, den schau ich mir als nächstes mal an, ist auch eine gelunge Abwechslung. Flüssiger läuft es, weil meine "tolle" Idee, Berechnung und Grafik gleichzeitig zu machen, mir auf die Füße gefallen ist. Ich habe vergessen ein paar WICHTIGE Daten nur in Kopie an die Grafikfunktion zu schicken. So gab es nur eine Kopie eine Pointers - sehr sinnig. Denn auch bei 60 fps hat es gestockt. O_o
Ich habe abermals meine gesammte Ablaufroutine (also "Fade In" -> "Auswahl" -> "Würfeln" -> "Sprung hoch" -> "Sprung runter" -> "Trigger bei Verlassen eines Feldes" -> "nächstes Feld" -> "Trigger beim Betreten eines Feldes" -> "Item" -> Back to "Trigger bei Verlassen eines Feldes", wenn Würfelanzahl nicht 0 ist, sonst -> "Fade Out" -> "nächster Spieler" -> Back to "Fade In") überarbeitet und einfacher gestaltet. Nun ist es in sich schön logisch und ich kann später Items oder andere mir noch unbekannte Hirngespinste einbauen.
Außerdem klappt nun die Scriptausführung. Es gab direkt in der Engine ein paar schwerwiegende Fehler und ich paar in meiner Errinnerung. So wunderte ich mich, dass
Code:
  1.  
  2. if ([a]>5 & [a]<10)
  3. ...
  4. fi
  5.  

nicht richtig wollte. Grund war einfach: Relationszeichen und logische Operationen sind gleichwertig. Er hat also erst [a]>5 errechnet (das sei 1, also True), dann 1 & [a] (da [a] scheinbar größer als 5 ist, muss [a] positiv sein, damit sollte das hier auch gelten), dann 1<10, was ja auch True, also 1 ist. Wenn [a] nun aber 100 wäre, wäre der Gesamtausdruck trotzdem True/1. Hier ist es also wichtig zu Klammern:
Code:
  1.  
  2. if (([a]>5) & ([a]<10))
  3. ...
  4. fi
  5.  

BAM und wieder ein wertvoller Nachmittag weggewesen -_-
Man sieht auch schon den zu sammelnden Smaragd/Diamant (ich muss mich noch für ein Wort entscheiden, was klein cooler?) in dem Video. Nur als der rote Spieler ihn erreicht, passiert garnichts mehr. Das stimmt auch so. ^^ Ich nutze Funktionen, die noch nicht existieren => ungünstig. An der Stelle soll nun eine Textbox kommen mit etwas Text und mit (A) kauft man den Stern für 20 Münzen, mit (B) verzichtet man dankend. ;-) Achja, apropro Münzen, es gibt eine -3 und +3 Animation. =^.^=

Einen schönen Abend noch, bis demnächst. Ich denke, ich werde nach den Prüfungen (Mittwoch ist die letzte, wünscht mir Glück, da kann ichs gebrauchen, für die am Montag bedarf es eines Wunders) die Textausgabe fertig stellen und mich danach an das Geskripte für ein paar Ereignisse machen, Minispiele einbauen und dann kann ich ja schon bald was zu downloaden anbieten - nach nur (mindestens) 4 Monaten. <_< Übrigens werde ich in dem einen Minispiel vielleicht Selektion brauchen, aber mal schauen, wahrscheinlich bietet sich da eher ein Pythagoras an, wird wohl intern 2D laufen...

LG Ziz

Nachtrag: Habe mal testweise statt einer 1024x1024-Textur eine 512x512 und niedriger genommen. Kleiner als 512x512 bringt keine Extraperformance, aber 512x512 ca. 80% mehr. Ich denke, ich weiß, wo meine nächste Aufgabe liegt: Ich veränder meine "Texturladefunktion" um einen Parameter, der einen Runterrechnungsfaktor angibt (ganzzahlig positiv: 2,4,8 etc.).
Außerdem habe ich "mal schnell" Frustum Culling eingebaut. Bringt leider keine Geschwindigkeitszuwachse. Aber auch keine Einbußen, also bleibt es drin. ;-) Ich denke auch, dass bei ca. 200 Objekten ein Octtree wenig bringt.

Nachtrag 2: So, habe ein Runterskalieren der Textur beim Laden eingebaut, es funzt auch und lässt die fps wachsen. :-)

_________________
Denn wer nur schweigt, weil er Konflikte scheut, der macht Sachen, die er hinterher bereut.
Und das ist verkehrt, denn es ist nicht so schwer, jeden Tag zu tun als ob's der letzte wär’.
Und du schaust mich an und fragst ob ich das kann.
Und ich denk, ich werd' mich ändern irgendwann.

_________________Farin Urlaub - Bewegungslos


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 35 Beiträge ]  Gehe zu Seite 1, 2, 3  Nächste
Foren-Übersicht » Sonstiges » 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.106s | 20 Queries | GZIP : On ]