Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht Das deutsche QBasic- und FreeBASIC-Forum
Für euch erreichbar unter qb-forum.de, fb-forum.de und freebasic-forum.de!
 
FAQFAQ   SuchenSuchen   MitgliederlisteMitgliederliste   BenutzergruppenBenutzergruppen  RegistrierenRegistrieren
ProfilProfil   Einloggen, um private Nachrichten zu lesenEinloggen, um private Nachrichten zu lesen   LoginLogin
Zur Begleitseite des Forums / Chat / Impressum
Aktueller Forenpartner:

Gfx Spielereien
Gehe zu Seite Zurück  1, 2, 3, 4, 5, 6  Weiter
 
Neues Thema eröffnen   Neue Antwort erstellen    Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht -> Projektvorstellungen
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen  
Autor Nachricht
Elor



Anmeldungsdatum: 12.07.2013
Beiträge: 205
Wohnort: Konstanz

BeitragVerfasst am: 16.08.2016, 11:59    Titel: Antworten mit Zitat

Jojo hat Folgendes geschrieben:

Ich hoffe dass du daraus mehr gelernt hast als nur immer eine gerade Screen-Breite zu wählen.

So, dass hat mir jetzt keine ruhe gelassen. Die Screen-Breite ist gar nicht das Problem, die Arbeitet fehlerfrei! Die Screen-Pitch entspricht immer genau der ScreenWidth* Bpp, egal ob die Auflösung gerade oder ungerade ist. Der Fehler liegt ja darin, dass die ImageCreate-Funktion die Pitch auf ein vielfaches von 16 (bei 64bit Systemen) erweitert. Bei allem Respekt, was soll den daa? Die Pitch muss durch gar nichts teilbar sein, weder du 16, 32 noch durch sonst irgend was. Diese Erweiterung spielt nur beim speichern und laden der BITMAP eine rolle. Beim Speichern einer BITMAP muss die Pitch ggf. auf ein vielfaches von 4 erweitert werden. Beim laden dieser BITMAP muss diese Erweiterung wieder heraus genommen werden. Ich hab das mal mit einer selbst gebastelten Funktion ausprobiert, ohne diese Erweiterung, es Funktioniert mit jeder Auflösung und auf jedem BS fehlerfrei. Ich bin mir also ziemlich sicher das es an der ImageCreate Function liegt.
Das wäre jetzt aber wahrscheinlich ein anders Thema oder?
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Jojo
alter Rang


Anmeldungsdatum: 12.02.2005
Beiträge: 9736
Wohnort: Neben der Festplatte

BeitragVerfasst am: 16.08.2016, 13:10    Titel: Antworten mit Zitat

Zitat:
Die Screen-Pitch entspricht immer genau der ScreenWidth* Bpp, egal ob die Auflösung gerade oder ungerade ist. Der Fehler liegt ja darin, dass die ImageCreate-Funktion die Pitch auf ein vielfaches von 16 (bei 64bit Systemen) erweitert. Bei allem Respekt, was soll den daa?

Das hab ich ja schon erklärt: Der Pitch-Wert wird typischerweise so gewählt, dass die Grafikpuffer möglichst schnell verarbeitet werden können. Der Screen-Pitch kommt dabei ggf. vom Betriebssystem selbst, aber der ImageCreate-Pitch kommt von FreeBASIC. FreeBASIC kann intern vermutlich den SSE-Befehlssatz deiner x86-CPU benutzen, um Bildpuffer rasend schnell zu kopieren, und dazu müssen die kopierenden Daten an einer Adresse liegen, die durch 16 teilbar ist. Ist dies nicht der Fall, crasht das Programm oder aber es wird sehr viel langsamer (auf modernen CPUs ist dieser Entschleunigungseffekt allerdings kaum noch zu merken, als SSE noch neu war, war das noch schlimmer).
Vermutlich hast du noch die Vorstellung, dass das ignorieren des Pitch-Wertes irgendwie schneller wäre, weil du die ganzen Prüfungen weglassen kannst und einfach Pixel direkt hintereinander in einen Bildpuffer kloppen kannst, aber die Realität ist eine andere: Durch den Pitch von 16 wird das Kopieren von Bildpuffern beschleunigt.

Deswegen: Immer den Pitch-Wert berücksichtigen, egal ob er in deinen Experimenten immer 4, 16, 42 oder 1337 zu sein scheint. Sonst wird das Programm irgendwann mal garantiert explodieren.
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
Elor



Anmeldungsdatum: 12.07.2013
Beiträge: 205
Wohnort: Konstanz

BeitragVerfasst am: 16.08.2016, 15:29    Titel: Antworten mit Zitat

@Jojo… ich bin davon überzeugt, dass du da einem Irrtum unterliegst. Ich möchte mal ein einfaches Beispiel zeigen und wäre dann auf deine Erklärung gespannt.
Code:

Dim Image As FB.IMAGE Ptr
ScreenRes (640, 480, 32)
Image= ImageCreate (640, 480, 0, 32)

Lässt man sich nun die breite, Höhe und Pitches von Screen und Image ausgeben, sind beide gleich.
Machen wir mal folgendes:
Code:

Dim Image As FB.IMAGE Ptr
ScreenRes (630, 480, 32)
Image= ImageCreate (630, 480, 0, 32)

Wenn man sich diese Pitch-Werte ausgeben lässt, stimmt die Screen-Pitch. Die Image-Pitch jedoch hält stur an der 640iger breite fest. Das geht bis auf eine Breite von 625 (64Bit System) so, erst ab einer breite von 624 passt sich die Image-Pitch wieder der Screen-Pitch an usw. Erkläre mir Bitte was diese 15,16 Toten Pixel am ende einer Zeile zu suchen haben. Es geht hier um eine BITMAP deren Zeilen nur beim Speichern auf ein vielfaches von 4 erweitert werden muss, nicht aber im Speicher.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
nemored



Anmeldungsdatum: 22.02.2007
Beiträge: 4594
Wohnort: ~/

BeitragVerfasst am: 16.08.2016, 17:44    Titel: Antworten mit Zitat

Zitat:
Erkläre mir Bitte was diese 15,16 Toten Pixel am ende einer Zeile zu suchen haben

Das hat er jetzt schon zweimal getan. Interne (Bild-)Speicherdaten werden eben nicht nur zum (Festplatten)speichern und laden verwendet, sondern können z. B. auch in einen anderen Speicher kopiert werden.
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Jojo
alter Rang


Anmeldungsdatum: 12.02.2005
Beiträge: 9736
Wohnort: Neben der Festplatte

BeitragVerfasst am: 16.08.2016, 18:04    Titel: Antworten mit Zitat

Wie nemored schon schrieb, hab ich genau das erklärt:
Die interne Repräsentation eines FB-Bildpuffers, der mit ImageCreate erstellt wird, muss sich an keine Bildschirmgrößen, Bitmap-Formate oder sonstwas halten, sondern orientiert sich daran, dass das Kopieren der Bildpuffer möglichst schnell abläuft.
Um es noch deutlicher zu machen, hier mal ein bisschen Pseudocode wie der PUT-Befehl von FB intern ungefähr aussehen könnte:
Code:

' Unoptimiert
imageRow = image[0] ' pointer auf ersten Pixel
screenRow = screen[...] 'pointer auf ersten zu adressierenden pixel im Screen
for y = 0 to imgHeight
  for x = 0 to imgWidth
    screenRow[x] = imageRow[x] ' ein einziger pixel wird kopiert
  next
  imageRow += imgWidth
  screenRow += screenWidth
next

Code:
'Optimiert mit SSE, 16 Byte Alignment (Pitch)
width16 = (imgWidth + 15) \ 16 ' Bildbreite / 16, aufgerundet
for y = 0 to imgHeight
  for x = 0 to width16
    _mm_storeu_si128(screenRow + x, _mm_load_si128(imageRow + x)) ' 16 byte werden auf einmal kopiert
  next
  imageRow += imgPitch
  screenRow += screenPitch
next

_mm_load_si128 ist ein SSE-Befehl, der in einem Rutsch 16 Bytes von einer Speicheradresse lädt. Diese Adresse muss durch 16 teilbar sein, sonst crasht das Programm. Die optimierte Variante des Codes läuft deswegen nur, wenn der Pitch des Bildes ein Vielfaches 16 ist - dafür ist sie aber auch sehr viel schneller als die unoptimierte Variante. Damit Befehle wie PUT und co. so schnell wie möglich ablaufen können, gibt es also gewisse Anforderungen an das Innenleben eines Bildpuffers, in diesem Fall dass eine Pixelzeile an einer Adresse beginnen muss, die durch 16 teilbar ist, was dadurch erreicht wird, dass jede Pixelzeile als Länge ein Vielfaches von 16 Byte hat. Diese Anfordungen können aus verschiedenen Gründen auf den SCREEN selbst zutreffen oder eben auch nicht (wie in deinem Beispiel). Ich habe mir die Innereien der gfxlib nicht angeschaut und kann deswegen nicht sagen warum sie sich genau so verhält wie du es beobachtest, aber meine Erklärung verdeutlich warum sie manchmal eben Vielfache von 16 haben will und manchmal nicht.

Übrigens: Würde FreeBASIC AVX-Instruktionen statt SSE-Instruktionen verwenden, müsste der Pitch-Wert sogar ein Vielfaches von 32 statt 16 sein (Die Zeilenlänge eines Bildpuffers müsste also ein Vielfaches von 32 sein), dafür wäre das Kopieren des Bildpuffers auf den Bildschirm noch schneller. Für AVX benötigt man aber wesentlich modernere Prozessoren als für SSE.

Wie schon mehrfach erwähnt, sind das Details, über die sich der Programmierer keine Gedanken machen sollte, die er aber auch nicht ignorieren sollte. Man darf sich nicht darauf verlassen, dass der Pitch-Wert in zukünftigen FreeBASIC-Versionen identisch bleibt (siehe SSE -> AVX), und genau deswegen kann man ihn ja auch auslesen - damit man ihn nämlich benutzt. zwinkern
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
Elor



Anmeldungsdatum: 12.07.2013
Beiträge: 205
Wohnort: Konstanz

BeitragVerfasst am: 18.08.2016, 07:47    Titel: Antworten mit Zitat

Ok, wenn FB Bilder so verarbeitet muss ich das einfach auch so akzeptieren.
Ich denke aber trotzdem das man das anders hätte lösen können. Bei dem GDI Beispiel oben muss ich mir um die Pitch ja auch keine Gedanken machen, da hab ich auch direkten zugriff auf jedes Pixel.
Da es unter Windows 10 (32) zwischen der GDI Variante und meinem FB Beispiel keinen unterschied bezüglich der FPS gibt, gehe ich davon aus, dass das GDI die Bilder ebenfalls in die 128bit Register knallt. Könnte es sein, dass das GDI die Erweiterung auf 16 nicht auf jede Zeile anwendet, sondern auf das gesamte Bild? Sinn machen würde es, aber vielleicht unterliege ich hier wieder einem Denkfehler?
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
UEZ



Anmeldungsdatum: 24.06.2016
Beiträge: 129
Wohnort: Opel Stadt

BeitragVerfasst am: 18.08.2016, 21:04    Titel: Antworten mit Zitat

Elor hat Folgendes geschrieben:
Ok, wenn FB Bilder so verarbeitet muss ich das einfach auch so akzeptieren.
Ich denke aber trotzdem das man das anders hätte lösen können. Bei dem GDI Beispiel oben muss ich mir um die Pitch ja auch keine Gedanken machen, da hab ich auch direkten zugriff auf jedes Pixel.
Da es unter Windows 10 (32) zwischen der GDI Variante und meinem FB Beispiel keinen unterschied bezüglich der FPS gibt, gehe ich davon aus, dass das GDI die Bilder ebenfalls in die 128bit Register knallt. Könnte es sein, dass das GDI die Erweiterung auf 16 nicht auf jede Zeile anwendet, sondern auf das gesamte Bild? Sinn machen würde es, aber vielleicht unterliege ich hier wieder einem Denkfehler?


Ich kompiliere Standard mit fbc -s gui -RR -fpu SSE -vec 2.
Soweit ich aus dem Asm Code sehen kann, werden die Pixel nicht mit MMX Befehlen angesprochen, drumherum ja.

Code:

...
call _MOVEPARTICLES@16
mov eax, dword ptr [ebp-252]
imul eax, 24
add eax, dword ptr [_APARTICLES]
movss xmm0, [eax]
sub esp, 8
movss dword ptr [esp], xmm0
fld dword ptr [esp]
movaps xmm7, xmm0
fistp qword ptr [esp]
fild qword ptr [esp]
fstp dword ptr [esp]
xorps xmm0, xmm0
subss xmm7, [esp]
cmpnless xmm0, xmm7
andps xmm0, xmmword ptr [_Lt_015D]
addss xmm0, [esp]
add esp, 8
mov eax, dword ptr [ebp-252]
imul eax, 24
add eax, dword ptr [_APARTICLES]
movss xmm6, [eax+4]
sub esp, 8
movss dword ptr [esp], xmm6
fld dword ptr [esp]
movaps xmm7, xmm6
fistp qword ptr [esp]
fild qword ptr [esp]
fstp dword ptr [esp]
xorps xmm6, xmm6
subss xmm7, [esp]
cmpnless xmm6, xmm7
andps xmm6, xmmword ptr [_Lt_015D]
addss xmm6, [esp]
add esp, 8
mov eax, dword ptr [_IW]
and eax, 0xFFFF
cvtsi2ss xmm5, eax
mov eax, dword ptr [_IW]
shr eax, 16
cvtsi2ss xmm7, eax
mulss xmm7, dword ptr [_Lt_0153]
addss xmm5, xmm7
mulss xmm6, xmm5
addss xmm0, xmm6
sub esp, 8
movss dword ptr [esp], xmm0
fld dword ptr [esp]
fistp qword ptr [esp]
pop eax
add esp, 4
mov dword ptr [ebp-264], eax
mov eax, dword ptr [ebp-268]
cmp dword ptr [ebp-264], eax
jbe .Lt_013A
mov eax, dword ptr [ebp-268]
mov dword ptr [ebp-264], eax
.Lt_013A:
mov eax, dword ptr [ebp-252]
imul eax, 24
add eax, dword ptr [_APARTICLES]
mov ebx, dword ptr [ebp-264]
sal ebx, 2
mov ecx, dword ptr [ebp-212]
add ecx, ebx
mov ebx, dword ptr [eax+20]
mov dword ptr [ecx], ebx
.Lt_0136:
inc dword ptr [ebp-252]
.Lt_0135:
mov ebx, dword ptr [ebp-296]
cmp dword ptr [ebp-252], ebx
jbe .Lt_0138
...

_________________
Gruß,
UEZ
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Elor



Anmeldungsdatum: 12.07.2013
Beiträge: 205
Wohnort: Konstanz

BeitragVerfasst am: 19.08.2016, 08:34    Titel: Antworten mit Zitat

Ich muss leider zugeben, dass ich schon sehr sehr lange nicht mehr in ASM Programmiert hab. Ob da jetzt jede Zeile intern erweitert wird oder nicht könnte ich jetzt nicht raus lesen. Das ist aber auch nicht mehr so wichtig, FB macht es eben anders. Wenn man zur Bildmanipulation die FB Befehle nimmt, wie in meinem Beispiel oben mit Pset, tritt das Problem erst gar nicht auf.
Ich glaube wir sollten diesen Thementeil beenden und wieder zum eigentlichen Thema zurückkehren.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
UEZ



Anmeldungsdatum: 24.06.2016
Beiträge: 129
Wohnort: Opel Stadt

BeitragVerfasst am: 12.10.2016, 09:52    Titel: GDI Particle Repulsion Grid Antworten mit Zitat

Und noch'ne weitere Spielerei für Windows:

GDI Particle Repulsion Grid.


Download: http://pastebin.com/NqQmF0Ym. Einfach die Maus über das Bild bewegen...


Apropos DL, kann ich hier keine Dateien hochladen?

Edit: Das Ganze mit Sound!
_________________
Gruß,
UEZ


Zuletzt bearbeitet von UEZ am 03.10.2018, 20:25, insgesamt 3-mal bearbeitet
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
nemored



Anmeldungsdatum: 22.02.2007
Beiträge: 4594
Wohnort: ~/

BeitragVerfasst am: 12.10.2016, 21:27    Titel: Antworten mit Zitat

Zitat:
Apropos DL, kann ich hier keine Dateien hochladen?

Hier im Forum nicht, aber z. B. im Portal. Es gibt ja schon sehr alte Pläne, Portal und Forum zu verschmelzen, aber ich rechne da ehrlich gesagt nicht mehr in näherer Zeit damit ...
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
UEZ



Anmeldungsdatum: 24.06.2016
Beiträge: 129
Wohnort: Opel Stadt

BeitragVerfasst am: 27.02.2017, 21:13    Titel: Antworten mit Zitat

Und die nächste bzw. erste Spielerei für 2017 -> Rotierende Erde (physikalisch nicht korrekte Simulation!)



Download: Rotating Earth Res v1.7 build 2017-03-19

Ich weiß - GDI+ ist nicht besonders performant, aber was soll's... happy
_________________
Gruß,
UEZ


Zuletzt bearbeitet von UEZ am 19.03.2017, 18:28, insgesamt 2-mal bearbeitet
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Elor



Anmeldungsdatum: 12.07.2013
Beiträge: 205
Wohnort: Konstanz

BeitragVerfasst am: 02.03.2017, 12:21    Titel: Antworten mit Zitat

Zitat:
Ich weiß - GDI+ ist nicht besonders performant, aber was soll's...
Aber sie dreht sich...

Unter Windows10/64 lässt sich das Programm nicht Kompilieren, da gibt es eine menge Fehlermeldungen und zwar in denn Dateien winnt.bi, winerror.bi und winuser.bi.
Die Meldungen lauten überwiegend →
Symbol defined inside namespace cannot be removed… und
Duplicated definition in Declare function _rotl cdecl …

Hat das noch jemand beobachtet?
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
UEZ



Anmeldungsdatum: 24.06.2016
Beiträge: 129
Wohnort: Opel Stadt

BeitragVerfasst am: 02.03.2017, 17:46    Titel: Antworten mit Zitat

Elor hat Folgendes geschrieben:
Zitat:
Ich weiß - GDI+ ist nicht besonders performant, aber was soll's...
Aber sie dreht sich...

Da bin ich beruhigt. zwinkern

Zitat:

Unter Windows10/64 lässt sich das Programm nicht Kompilieren, da gibt es eine menge Fehlermeldungen und zwar in denn Dateien winnt.bi, winerror.bi und winuser.bi.
Die Meldungen lauten überwiegend →
Symbol defined inside namespace cannot be removed… und
Duplicated definition in Declare function _rotl cdecl …

Hat das noch jemand beobachtet?


Ich programmiere hauptsächlich unter Win10 x64 und kann die Fehler nicht bestätigen. Die Exe in dem Archiv ist unter Win10 x64 als x86 erstellt.
_________________
Gruß,
UEZ


Zuletzt bearbeitet von UEZ am 03.03.2017, 11:29, insgesamt einmal bearbeitet
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
nemored



Anmeldungsdatum: 22.02.2007
Beiträge: 4594
Wohnort: ~/

BeitragVerfasst am: 02.03.2017, 20:40    Titel: Antworten mit Zitat

Elor, hast du die aktuellen Bibliotheken (.bi-Datei passend zur Version der DLL und der .dll.a)?

Unter Linux kann ich es ja leider nicht compilieren, und mit Wine ist die Geschwindigkeit sehr gedrosselt, aber sie bewegt sich. happy
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Elor



Anmeldungsdatum: 12.07.2013
Beiträge: 205
Wohnort: Konstanz

BeitragVerfasst am: 03.03.2017, 11:04    Titel: Antworten mit Zitat

nemored hat Folgendes geschrieben:
Elor, hast du die aktuellen Bibliotheken (.bi-Datei passend zur Version der DLL und der .dll.a)?
Davon gehe ich eigentlich aus, es ist der momentan aktuelle 64Bit Compiler und auf Windows 10/32 funktioniert es fehlerfrei. Leider hab ich heute nicht so viel zeit, werde mir morgen mal die 32-und 64 Bit Bi‘s anschauen.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Elor



Anmeldungsdatum: 12.07.2013
Beiträge: 205
Wohnort: Konstanz

BeitragVerfasst am: 06.03.2017, 12:37    Titel: Antworten mit Zitat

UEZ hat Folgendes geschrieben:
Ich programmiere hauptsächlich unter Win10 x64 und kann die Fehler nicht bestätigen. Die Exe in dem Archiv ist unter Win10 x64 als x86 erstellt.

Du hast aber auch den 32Bit Compiler verwendet, ich den 64Bit, ist also ein Problem mit dem FBC x86_64.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
UEZ



Anmeldungsdatum: 24.06.2016
Beiträge: 129
Wohnort: Opel Stadt

BeitragVerfasst am: 06.03.2017, 15:20    Titel: Antworten mit Zitat

Ich bekomme auch die FM, wenn ich die x64 FB Version verwende.
_________________
Gruß,
UEZ
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
UEZ



Anmeldungsdatum: 24.06.2016
Beiträge: 129
Wohnort: Opel Stadt

BeitragVerfasst am: 19.03.2017, 02:20    Titel: Antworten mit Zitat

Kleines Update zu Rotierende Erde weiter oben.

Die Bilder sind jetzt als Ressourcen eingebunden.
_________________
Gruß,
UEZ
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Elor



Anmeldungsdatum: 12.07.2013
Beiträge: 205
Wohnort: Konstanz

BeitragVerfasst am: 20.03.2017, 10:44    Titel: Antworten mit Zitat

Das Programm lässt sich fehlerfrei kompilieren und ausführen aber zusehen bekommt man nicht‘s, seltsam. Deine exe funktioniert allerdings.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
UEZ



Anmeldungsdatum: 24.06.2016
Beiträge: 129
Wohnort: Opel Stadt

BeitragVerfasst am: 20.03.2017, 20:41    Titel: Antworten mit Zitat

Elor hat Folgendes geschrieben:
Das Programm lässt sich fehlerfrei kompilieren und ausführen aber zusehen bekommt man nicht‘s, seltsam. Deine exe funktioniert allerdings.


Hmmm, echt seltsam. Hört sich an, als ob die .rc Datei nicht ausgeführt wird.

Hat jemand die gleichen Probleme?
_________________
Gruß,
UEZ
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Beiträge der letzten Zeit anzeigen:   
Neues Thema eröffnen   Neue Antwort erstellen    Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht -> Projektvorstellungen Alle Zeiten sind GMT + 1 Stunde
Gehe zu Seite Zurück  1, 2, 3, 4, 5, 6  Weiter
Seite 2 von 6

 
Gehe zu:  
Du kannst keine Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum nicht antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.

 Impressum :: Datenschutz