Program Speeding Up

[gitoxa]

When the amount of balls is increased, for some reason it speeds up, and I can't quite figure it out.

Just edit this to test it.

code:

const NUMBALLS := <number>

Also, if you have any suggestions on the Get_Velocity procedure, you can say them too. Yay laziness!

[gitoxa]

Any ideas, anyone? Still haven't figured out the speed problem.

[DemonWasp]

The problem lies in your main loop (right at the bottom of your program). You have the following:

Turing:

loop     for Ball : 1 .. NUMBALLS         Draw_Borders (BORTHICK, BORCOLOUR)         Draw_Circles (CircleX, CircleY, RADIUS, CIRCLECOLOUR)         New_Vel_And_Position (CircleX, CircleY, VelUp, VelSide)         Check_Boundries (CircleX, CircleY, VelUp, VelSide)         if CircleY (Ball) = BORTHICK + RADIUS and VelSide (Ball) = 0 then             if Motionless (Ball) > 0 then %Been motionless for more than one iteration in a row                 Motionless (Ball) := 2             else                 Motionless (Ball) := 1 %This is to set to check to see if next time it's still on the ground             end if         else             Motionless (Ball) := 0 %Means it's not on the ground         end if     end for     if Check_Still (Motionless) then         Get_Velocity (CircleX, CircleY, VelSide, VelUp)     end if     View.Update     delay (22)     cls end loop

But go look closely at each of Draw_Borders, Draw_Circles, New_Vel_and_Position, and Check_Boundaries. Each of those methods does everything in a for Ball: 1 to NUMBALLS loop.

So each time you went through the loop-endloop pictured, you were doing NUMBALLS iterations of the draw, draw, new velocities/positions, and check boundries methods - so the larger number of balls means your program does more between delays (so we see it moving faster).

To solve the problem, just move the method calls outside the for loop, as follows:

Turing:

loop     Draw_Borders (BORTHICK, BORCOLOUR)     Draw_Circles (CircleX, CircleY, RADIUS, CIRCLECOLOUR)     New_Vel_And_Position (CircleX, CircleY, VelUp, VelSide)     Check_Boundries (CircleX, CircleY, VelUp, VelSide)     for Ball : 1 .. NUMBALLS         if CircleY (Ball) = BORTHICK + RADIUS and VelSide (Ball) = 0 then             if Motionless (Ball) > 0 then %Been motionless for more than one iteration in a row                 Motionless (Ball) := 2             else                 Motionless (Ball) := 1 %This is to set to check to see if next time it's still on the ground             end if         else             Motionless (Ball) := 0 %Means it's not on the ground         end if     end for     if Check_Still (Motionless) then         Get_Velocity (CircleX, CircleY, VelSide, VelUp)     end if     View.Update     delay (22)     cls end loop

I've checked, and that seems to solve the problem completely. Cool program, by the way.

Nitpick: it's "Boundaries". Yes, I'm a spelling meanie.

[riveryu]

If you are worrying anything to be too fast I think you can use Time.DelaySinceLast (time in ms), it makes sure the loop runs at the same speed no matter how fast the computer is. Fast machines will spend little time in the loop and longer waiting to return from Time.DelaySinceLast. Slower machines will take longer to execute the loop and will consequently wait less time before returning from Time.DelaySinceLast. F10 Turing help is actually helpful.

[DemonWasp]

That's a cool system call, but it actually wouldn't have solved this problem. As per my explanation above, he was actually running the physics simulation code NUMBALLS times for every delay (or Time.DelaySinceLast() ). It may have made the timing more consistent, but it wouldn't have solved the problem.

[gitoxa]

Thanks a lot DemonWasp. +Karma