PureBoard

Verfasst: **09.08.2010 01:19**

Jo, weiß zwar nicht ob das hier repräsentativ ist, aber:

#Size = 100000000
Define Time, Time1, Time2

Define f1.f = 123.456
Define f2.f = 654.321

Time = ElapsedMilliseconds()
For n = 1 To #Size
  newf.f = f1*f2
Next
Time1 = ElapsedMilliseconds()-Time

Define d1.d = 123.456
Define d2.d = 654.321

Time = ElapsedMilliseconds()
For n = 1 To #Size
  newd.d = d1*d2
Next
Time2 = ElapsedMilliseconds()-Time


MessageRequester("Testergebnis", "Time1: "+Str(Time1)+Chr(10)+"Time2: "+Str(Time2))

ergibt bei mir zB:

---------------------------
Testergebnis
---------------------------
Time1: 312
Time2: 1016
---------------------------
OK
---------------------------

also sind bei mir Doubles in diesem Beispiel 3 mal langsammer als Floats ...

@c4s
Jo sry ^^ war auf dem Unicode-Ascii-Trip ^^

Verfasst: **09.08.2010 01:56**

bei mir (Vista x86)

Time1: 407
Time2: 390

bei #size=1000000000
Time1: 3844
Time2: 3938

hab aber auch einen cpu der beides unterstüzt x64/x86

Verfasst: **09.08.2010 20:09**

Windows XP Home SP3 x86 hat geschrieben:#Size = 1000000000
Time1: 2984

Time2: 2875
#Size = 100000000
Time1: 296

Time2: 282

Windows 7 Home Premium x64 hat geschrieben:#Size = 1000000000
Time1: 8814

Time2: 8596
#Size = 100000000
Time1: 890

Time2: 842

Verfasst: **09.08.2010 23:11**

Also doch nicht repräsentativ ^^

zurück zur Physik...

Ich "entschlüssel"gerade folgende Zeilen:

Code: Alles auswählen

         vect(old,particle(i)\p\x,particle(i)\p\y)                 ;Geschwindigkeit wird aus alter und neuer poition berrechnet + beschleunigung(gravitation)
         particle(i)\p\x=2*particle(i)\p\x-particle(i)\oldp\x+particle(i)\a\x*timestep*timestep
         particle(i)\p\y=2*particle(i)\p\y-particle(i)\oldp\y+particle(i)\a\y*timestep*timestep
         vect(particle(i)\oldp,old\x,old\y)

Das stellt ja die Bewegung dar.
Ohne Koordinaten steht da:
Position = 2*Position - AltePosition + Beschleunigung*Teit^2
Ausgeschrieben wäre das:
Position = Beschleunigung*Teit^2 + (Position - AltePosition) + Position
Dort tauchen also Beschleunigungsanteil, Geschwindigkeitsanteil und Ort auf.
Das Problem, was ich gerade habe ist, dass die Gleichung aber:
s = 0.5*a*t^2 + v0*t + s0 lautet.

Das würde bedeuten, dass bei dir der Faktor vor dem Beschleunigungsanteil fehlt!

Ich habe mir diesen Teil genauer angesehen, weil ein ähnliches Problem hatte.
Ich hatte mir n schöne Physik aufgebaut, und dann mal aus Selbstkontrolle die Energie des Systems gemessen.
Bei einem Freifallenden Teilchen also E = Ekin + Epot
Problem war bei mir, das sich die Energie kontinuierlich während des Fallens veränderte, was ja nicht sein darf.
Bei lag der Fehler dann an einer ähnlichen stelle.

Verfasst: **10.08.2010 02:00**

Kleine Anmerkung: Soweit ich mich erinnere soll das ganze doch ein Gemeinschaftsprojekt sein, d.h. du STARGÅTE darst deine Code-Vorschläge auch posten indem du den Original-Code mit Verbesserung postest.
Ich meine mitlerweile weiß ich ja, dass du auch fit auf diesem Gebiet bist und es wäre zu schade, wenn deine Vorschläge nicht in dem "offiziellen Code" wären...

Verfasst: **15.08.2010 14:34**

STARGÅTE hat geschrieben:Das Problem, was ich gerade habe ist, dass die Gleichung aber:s = 0.5*a*t^2 + v0*t + s0 lautet.Das würde bedeuten, dass bei dir der Faktor vor dem Beschleunigungsanteil fehlt!

Jo, da haste prinzipiell Recht, aber da "a" in diesem Fall eine definierte Variable ist (in dem Fall global gravity.vect) und diese einfach nur nicht halbiert ist, hat man einfach nur eine größere Gravitation was man dadurch wieder wett macht, dass man die Gravitationsvariable um die Häfte Initialisiert.

... Hab auch noch nen -wie ich finde- seeehr lustiges Element eingebaut. Hab zwar sonst nicht viel geändert (das mit dem Durchdringen war, so wie ich STARGATEs procedure eingebaut hat, zu rechenintensiv).
Aber jetzt gibt es SCHLEIM!!! Ja genau! Schleim!! Und er Klebt!

Download Source+Testprogramm:
http://www.xup.in/dl,64284439/CircleVerletPhysics.rar/

Nadann viel spaß damit. Der Schleim Effekt liegt in der Attraction() Prozedur.

Verfasst: **15.08.2010 22:39**

Gefällt mir ...

Außerdem änder sich nun die Farbe der Kreise (Blaub keine Krafteinwirkung, Rot Krafteinwirkung?)
Außerdem "zerreißt" nun dieses Seil ...

Das mit der Beschleunigung ist mir nun klar

Jetzt wo das ding schon eigenermaßen "cool" ist, wäre es an der zeit mal die ProzedurNamen irgendwie "schöner" zu machen.
Vielleich mag es nur Tick von mir sein, möglichs alles irgendwie PB-Like aussehen zu lassen, aber ich finds dadurch "angenehmer" zu benutzen.

Ich würde es so ähnlich anlegen wie die "PureBasic - Entity"-Lib ... zusammen mit deren Physik ...
So würde dann die Code-Veränderung aussehen:

Derzeit:

Code: Alles auswählen

;Anfangszeug wird erstellt
CreateParticle(50,400,15,0)
For i=1 To 10
   CreateParticle(50+30*i,400,15,0.5)
   CreateConstraint(particle(count\particle),particle(count\particle-1),1)
Next
Particle(count\particle)\m=0

Nach änderung von
- CreateParticle(...) -> CreateParticle(ParticleNumber, ...)
- CreateConstraint(...) -> CreateConstraint(ConstraintNumber, ...)
würde das ganze so aussehen:

Code: Alles auswählen

;Anfangszeug wird erstellt
For Index = 0 To 10
  CreateParticle(Index, 50+Index*30, 400, 15, 0.5)
Next
SetParticleMass(0, 0)
SetParticleMass(10, 0)
For Index = 0 To 9
  CreateConstraint(#PB_Any, Index, Index+1, 1)
Next

Die Nummerierung geht halt wie in PB entweder Direkt oder per Any und Rückgabe.
Sachen die "unwichtig sind" kann man einfach per Any erstellen.

Die Elemente der Physik in einem Array zu lagern ist in bezug aufs ansprechen sicherlich geeignet,
wenn ich mir jedoch so einige Sachen in bezug auf Hinzufügen und löschen angucke (DeleteParticle), macht es relativ viel arbeit das Array nicht zu "durchlöchern" (wenn du verstehst was ich damit meine)
(Wie ich das sehe, wird derzeit die komplette Particle-Sammlung verschoben wann man das erste elemente löscht)

Ich finde eine LinkedList ist hier in jedemfall besser geeignet.
Normale abarbeitung der Elemente geht genau so gut mit ForEach.
Und wenns um Schachtlungen geht wie:

Code: Alles auswählen

      For i=1 To count\particle
         For j=1 To count\particle
            If particle(i)\id<>particle(j)\id
               If ProcessCollision(particle(i),particle(j))  ;jedes Object wir mit jedem auf Collision überprüft
               EndIf
            EndIf
         Next
      Next

Funktioniert das mit LinkedList:

Code: Alles auswählen

      ForEach Particle()
         *Particle.Particle = @Particle() ; äußere Liste sichern
         ForEach Particle()
            If Particle()\id<>*Particle\id
               If ProcessCollision(Particle(),*Particle)  ;jedes Object wir mit jedem auf Collision überprüft
               EndIf
            EndIf
         Next
         ChangeCurrentElement(Particle(), *Particle)
      Next

Ich habe derzeit leider keine Zeit es selber zu machen.
Um den Ratschlag von c4s trotzdem nachzukommen, würde ich die genannten Sachen selber am Wochenende umsetzen.
Bis dahin kannst du mir ja sagen ob es oke wäre wenn ich es umschreibe, und wir dann mit dem umgeschriebenen arbeiten, oder du es gar selber machen willst.

Verfasst: **16.08.2010 22:44**

^^danke, wär mir echt ganz lieb, wenn du das machen könntest, da bei mir jetzt 13tes Schuljahr angefangen hat und jetzt ABI angesagt ist (Hab ja auch noch ne Hand voll andere Projekte momentan laufen). Außerdem freut es mich zu höhren das so ein kompetenter Programmierer (*schleim*) bei diesem Projekt mitarbeitet.

Das mit den LinkedList hab ich auch mal probiert, aber irgendiwe hab ich was falsch gemacht und es wollte einfach nichmehr funktionieren (funktionieren die Pointer überhaupt richtig, wenn sie auf LinkedList Elemente zeigen?).
Kann man außerdem auch generell LinkedLists in einer Struktur einstrukturieren (geh ja mit arrays auch).
Und wenn man ja ein Element aus der Liste löscht, werden ja auch die ListenElemente durchgewechselt und die Pointer stimmen nicht mehr, oder?

Aber wenn du all diese Probleme lösen kannst, wär mir das sehr Recht und ich könnt ne Menge draus lernen.

Verfasst: **16.08.2010 22:57**

>> "wär mir echt ganz lieb, wenn du das machen könntest"
geht klar ...

>> "funktionieren die Pointer überhaupt richtig, wenn sie auf LinkedList Elemente zeigen?"
Sicher ...

>> "Kann man außerdem auch generell LinkedLists in einer Struktur einstrukturieren "
Seit 4.50 ja.

>> "Und wenn man ja ein Element aus der Liste löscht, werden ja auch die ListenElemente durchgewechselt und die Pointer stimmen nicht mehr, oder?"
Nein, nein. Eine LinkedList besteht aus einer Sammlung von (Strukturierten-)-Variablen die "irgendwo" im Speicher stehen.
Einmal erstellt, ändert sich der Aufenthaltsort (im Speicher) eines Elemente nicht mehr, dass ist ja das gute

Um die Liste beisammen zuhalten, hat jedes Element ein Vorgängerund Nachfolger.

Verfasst: **19.08.2010 13:46**

Hallo Leute,

die Ideen hier sind schön ausgearbeitet. Was mit im Moment nur auffällt ist das ein Kreis beim fallen irgendwie unnatürlich wirkt, als wenn sich die Beschleunigung nicht kontinuierlich erhöht wird. Weiter werden die Kreise (wenn Sie einen Inhalt hätten) nicht gedreht. Habt Ihr denn schon die Physikfunktionnen für drehende Objekten vorbereitet?

Da ich gerade auch an 2D/3D Physikfunktionen arbeite werde ich versuchen meine Erkenntnisse hier einzubringen. Mein Schwerpunkt wird sein das sich farbige Sprites auch physikalisch korrekt drehen sollten ( Soweit zur Theorie bzw. mein Zielwunsch)

Gruß Michael

PureBoard

Circle Physic Engine Userlib

Re: Circle Physic Engine Userlib

Re: Circle Physic Engine Userlib

Re: Circle Physic Engine Userlib

Re: Circle Physic Engine Userlib

Re: Circle Physic Engine Userlib

Re: Circle Physic Engine Userlib

Re: Circle Physic Engine Userlib

Re: Circle Physic Engine Userlib

Re: Circle Physic Engine Userlib

Re: Circle Physic Engine Userlib