Physics and Math (not advanced)

[arthurprs]

I simply can't make this thing work!!!!!

http://pastebin.com/f29c5c3f8
( code is more than 100 lines and i don't like to be warned by admins and mods =P )

Compiled project + source
http://www.thehardwaresxtreme.com/ny...urprs/test.zip

[savage]

Hi arthur,
Could you please mention exactly what is not working. Otherwise it's like a treasure hunt.

[WILL]

I think that we have all been in this state with a project before. I know I have many many times. Still patience and expressing the problem clearly and in detail to others is always the best solution rather than a rushed panic.

( code is more than 100 lines and i don't like to be warned by admins and mods =P )

Do I really need to say it? :roll:

[AthenaOfDelphi]

I've just had a quick look and unless my eyes deceived me, in the example exe, the balls collide and the one on the left starts going back (to the left), but the one on the right continues on its path instead of rebounding (something to do with... it going faster? momentum being retained that probably shouldn't be?)

The net result is that on the next collision calculation cycle, they are still in collision and thus, they are accelerated... in the same direction they are already traveling (to the left)... so instead of parting and going in opposite directions, they accelerate together and result in the whirl of pixels you're getting.

Thats what appears to be happening to me. I could be wrong but I don't have the time to brush off my physics and mechanical maths to go into it any further.

Hope it helps.

[arthurprs]

I've just had a quick look and unless my eyes deceived me, in the example exe, the balls collide and the one on the left starts going back (to the left), but the one on the right continues on its path instead of rebounding (something to do with... it going faster? momentum being retained that probably shouldn't be?)

The net result is that on the next collision calculation cycle, they are still in collision and thus, they are accelerated... in the same direction they are already traveling (to the left)... so instead of parting and going in opposite directions, they accelerate together and result in the whirl of pixels you're getting.

Thats what appears to be happening to me. I could be wrong but I don't have the time to brush off my physics and mechanical maths to go into it any further.

Hope it helps.

Yeah the balls don't collide right, they go to same direction =/ and the code appers to be right

[arthurprs]

I think that we have all been in this state with a project before. I know I have many many times. Still patience and expressing the problem clearly and in detail to others is always the best solution rather than a rushed panic.

( code is more than 100 lines and i don't like to be warned by admins and mods =P )

Do I really need to say it? :roll:

Im on this for more than 3 months :cry:


Sorry,
but it's nothing wrong.. to say that

sorry my bad english =(

[arthurprs]

Remade but don't finded the solution and don't find the problem on the source

[arthurprs]

I've just had a quick look and unless my eyes deceived me, in the example exe, the balls collide and the one on the left starts going back (to the left), but the one on the right continues on its path instead of rebounding (something to do with... it going faster? momentum being retained that probably shouldn't be?)

The net result is that on the next collision calculation cycle, they are still in collision and thus, they are accelerated... in the same direction they are already traveling (to the left)... so instead of parting and going in opposite directions, they accelerate together and result in the whirl of pixels you're getting.

Thats what appears to be happening to me. I could be wrong but I don't have the time to brush off my physics and mechanical maths to go into it any further.

Hope it helps.

ohhh now that i read that u saw the problem :shock:

and i think that's the problem too,
but don't know how solve the problem

[Robert Kosek]

Hello,

Your problem is in procedure Tform1.colision; because you loop through the balls twice. You might have more than one problem, but this is the one I really see.

You only have two balls, and you know this, so why do you check the collision of the balls twice in nested for-loops? If ball 1 collided with ball 2, obviously ball 2 collided with 1! Yet, you loop through and check again. This is where the strange behavior comes in. To use a for loop with this sort of thing, you'll have to "register" collisions to avoid, uh, collision collisions.... How to make that less wacky and more understandable? Ah, prevent duplicate collisions. Sorry, for a second there I got stuck between cars in my train of thought.

[pascal]procedure Tform1.colision;
var
n, i: Integer;
dist: single;
colided: Boolean;
begin
colided := False;

for n := 0 to 1 do
begin // n = currentball

ball[n].v2x := 0;
ball[n].v2y := 0;

// wall hit
//x
if (ball[n].x <0>= Form1.ClientWidth) then
begin
ball[n].vx := -ball[n].vx;
// todo: atrito 10%
end;
//y
if (ball[n].y <0>= Form1.ClientHeight) then
begin
ball[n].vy := -ball[n].vy;
// todo: atrito 10%
end;

// other balls hit
for i := 0 to 1 do // i = other ball
if i <> n then
begin
dist := distance(ball[i].cx, ball[i].cy, ball[n].cx, ball[n].cy);
if dist < (ball[i].raio + ball[n].raio) then
begin
colided := True;
form1.Caption := 'colidiu bola : ' + IntToStr(n) + ' , ' + IntToStr(i) + ' na distancia de ' + FloatToStr(dist) + ' ' + FloatToStr(ball[n].vx) + ' ' + FloatToStr(ball[n].vy) + ' ' + FloatToStr(ball[i].vx) + ' ' + FloatToStr(ball[i].vy);
ball[n].v2x := ball[n].v2x + ball[i].vx;
ball[n].v2y := ball[n].v2y + ball[i].vy;
end;
end;
end;

for n := 0 to 1 do
begin
if colided then
buffer.Canvas.TextOut(30,100,('ball n¬? ' + IntToStr(n) + ' ,v2x:' + FloatToStr(ball[n].v2x) + ' ,v2y:' + FloatToStr(ball[n].v2y)));
ball[n].vx := ball[n].vx + ball[n].v2x;
ball[n].vy := ball[n].vy + ball[n].v2y;
ball[n].Refresh;
end;
end;[/pascal]

I won't tell you how to write your code because I think you are trying to learn by doing so. But, you have two choices: the first is to hardcode this system into only two collisions; the second is to make a basic physics system that avoids duplicate collisions. I recommend the first in your case, but it is your choice.

If you follow my recommendation you should remove all for loops except the ending ball update code. Just check if ball 1 and 2 collided (once) and then calculate the reflection vectors.

Edit: Oh fine, I thought of the exact line away from the computer for two seconds, and I know how it is to stumble around for something like that. Here's your problem, and solution; check the first if statement.

  // other balls hit
    for i := 0 to 1 do // i = other ball
      if &#40;i <> n&#41; and &#40;not colided&#41; then // But don't colide twice.
      begin
        dist &#58;= distance&#40;ball&#91;i&#93;.cx, ball&#91;i&#93;.cy, ball&#91;n&#93;.cx, ball&#91;n&#93;.cy&#41;;
        if dist < &#40;ball&#91;i&#93;.raio + ball&#91;n&#93;.raio&#41; then
        begin
          colided &#58;= True;
          form1.Caption &#58;= 'colidiu bola &#58; ' + IntToStr&#40;n&#41; + ' , ' + IntToStr&#40;i&#41; + ' na distancia de ' + FloatToStr&#40;dist&#41; + ' ' + FloatToStr&#40;ball&#91;n&#93;.vx&#41; + ' ' + FloatToStr&#40;ball&#91;n&#93;.vy&#41; + ' ' + FloatToStr&#40;ball&#91;i&#93;.vx&#41; + ' ' + FloatToStr&#40;ball&#91;i&#93;.vy&#41;;
          ball&#91;n&#93;.v2x &#58;= ball&#91;n&#93;.v2x + ball&#91;i&#93;.vx;
          ball&#91;n&#93;.v2y &#58;= ball&#91;n&#93;.v2y + ball&#91;i&#93;.vy;
        end;
      end;

[arthurprs]

Hello,

Your problem is in procedure Tform1.colision; because you loop through the balls twice. You might have more than one problem, but this is the one I really see.

You only have two balls, and you know this, so why do you check the collision of the balls twice in nested for-loops? If ball 1 collided with ball 2, obviously ball 2 collided with 1! Yet, you loop through and check again. This is where the strange behavior comes in. To use a for loop with this sort of thing, you'll have to "register" collisions to avoid, uh, collision collisions.... How to make that less wacky and more understandable? Ah, prevent duplicate collisions. Sorry, for a second there I got stuck between cars in my train of thought.
...

Thx for the help! ;]

i will try what u say, but just one thing, i think the loop is necessary because the original source have 4 balls (you can see the dynamic array), isn't it ?


*from brazil so sorry my english