Please don't double post and please don't create more than one user profile.
Your other thread has been locked.
Anyhoo...
If you imagine your ball as a projectile, a projectile need's to know what direction and how fast it is travelling, a ball is just the same and in 2D, you only have to worry about 2 axis, and on a screen, you only have to use the most basic collision. Say your ball uses the variables BallX# and BallY# to store it's location, and BallSX# and BallSY# to store it's movement speed.
This code...
BallSX#=sin(rnd(360))
BallSY#=sin(rnd(360))
BallX#=320
BallY#=240
Would set the variables you need, a random X and Y speed, variating between -1 and 1 which is perfect because it's already a sorta standard speed vector.
Now, you can move your ball by simply adding the X speed to the X position, and doing the same for the Y axis too...
Inc BallX#,BallSX#
Inc BallZ#,BallSY#
Collision now, for your example at least, is real straightforward. Say our ball is on a 16x16 bitmap, and you want to simply paste that image on the screen, you'd just paste at the BallX#,BallY# location, subtracting 8 on each axis to line the ball up with it's centre, but as it's bouncing on the screen, you can use the screen as your collision zone.
Like:
If BallX#<8 and BallSX#<0 then BallSX#=0.0-BallSX#
If BallX#>Screen Width()-8 and BallSX#>0 then BallSX#=0.0-BallSX#
If BallY#<8 and BallSY#<0 then BallSY#=0.0-BallSY#
If BallY#>Screen Height()-8 and BallSY#>0 then BallSY#=0.0-BallSY#
That would ensure that the ball stays in the collision box, 8 pixels inside the edges of the screen so that the ball can never leave the screen.
If you increase the BallYS# variable slightly every loop, you'd have nice smooth gravity as well. Once you get the code in, you'll see how easy it is to mess around with the code, best way to learn IMO.
Van-B
Muhahahahaha.
