Hello physics

[johnno56]

Just a quick question. When the "ball" is "at rest" on the bottom of the screen, is there a way to prevent the ball from "jittering"? Maybe not the right word... The ball seem to be moving up and down ever so slightly... I'm hoping the problem is with the program. If not then I am left with the obvious conclusion that my already failing eyesight is getting worse... lol

[SierraKen]

Dajan, I hope you don't mind but I took your first code example and made the screen larger, made the circle smaller, filled in the circle, and added a graphical trail to the ball. This is an awesome gravity example, thanks!

Code: QB64: [Select]

1. _TITLE "Bouncy Ball Demo"
2. SCREEN _NEWIMAGE(800, 600, 32)
3. DO
4.     vx = ((x < 5 OR x > 795) * 1.9 + 1) * (vx - _KEYDOWN(ASC("d")) + _KEYDOWN(ASC("a"))) * 0.99
5.     vy = ((y < 5 OR y > 595) * 1.9 + 1) * (vy - _KEYDOWN(ASC("s")) + _KEYDOWN(ASC("w"))) * 0.99 + 10 / 60
6.     x = x + vx - (x < 5) + (x > 795)
7.     y = y + vy - (y < 5) + (y > 595)
8.     CIRCLE (x, y), 5, _RGB32(255, 255, 255)
9.     PAINT (x, y), _RGB32(255, 255, 255)
10.     _DISPLAY
11.     LINE (0, 0)-(800, 600), _RGBA(0, 0, 0, 40), BF
12.     _LIMIT 60
13. LOOP UNTIL _KEYDOWN(27)
14.  

[TempodiBasic]

Hello Dajan
Welcome to the QB64forum
fine basket game!
Well Lalinea join us. :-)

[dajan]

johnno56, good point. This is the result of sparse coding, all boundary conditions are not treated properly in code. Normally, there should be some test for the ball being under the floor and align it with floor then.

SierraKen - be my guest! I put it here firstly to see if others can make it into something interesting. And that trailing fireball is awesome effect indeed. I noticed the firebal leaves the last dark shaded circle unerased, is that indtended?

[SierraKen]

Thanks Dajan! I don't exactly know why the fireball does that, or why that code even does what it does. I've been using it for about half a year now myself and got it from Bplus. It has something to do with making it transparent for using the number 40. You can experiment with different numbers if you wish and read the QB64 Wiki page here, But this page doesn't mention the trailing effect itself.  https://www.qb64.org/wiki/RGBA

[dajan]

Time to add some bit more advanced features. Ball-rim collisions would be nice, but it also means giving up my original code minimalism idea. Never mind, I think it is woth it.
What do you think:

Code: QB64: [Select]

1. SCREEN 12
2. t = TIMER + 90
3. DO
4.     CLS
5.     vx = ((x < 25 OR x > 615) * 1.9 + 1) * (vx + (x < 200 AND y > 250) * _KEYDOWN(ASC("d")) - (y > 250) * _KEYDOWN(ASC("a"))) * 0.987
6.     vy = ((y > 455) * 1.9 + 1) * (vy + (x < 200 AND y > 250) * _KEYDOWN(ASC("s")) - (x < 200 AND y > 250) * _KEYDOWN(ASC("w"))) * 0.987 + 0.327
7.     vd = SQR(vx ^ 2 + vy ^ 2)
8.     rx(1) = 520: ry(1) = 200: rx(2) = 620: ry(2) = 200 'rim position
9.     FOR i = 1 TO 2
10.         dd = SQR((rx(i) - x) ^ 2 + (ry(i) - y) ^ 2)
11.         nx = ((vx * (rx(i) - x) + vy * (ry(i) - y)) * -vx - (vx * (ry(i) - y) - vy * (rx(i) - x)) * -vy) / vd / dd * 0.9
12.         ny = ((vx * (ry(i) - y) - vy * (rx(i) - x)) * -vx + (vx * (rx(i) - x) + vy * (ry(i) - y)) * -vy) / vd / dd * 0.9
13.         vx = (dd < 25) * -nx + (dd >= 25) * -vx
14.         vy = (dd < 25) * -ny + (dd >= 25) * -vy
15.     NEXT i
16.     x = x + vx - (x < 25) * 2 + (x > 615) * 2
17.     y = y + vy + (y > 455) * 2
18.     p = ((p = 0) + 2 * (p <> 0)) * (y > 210 AND y < 240 AND ABS(570 - (x - vx / vy * (y - 200))) < 25) * ((vy < 0) * 2 + 1)
19.     s = s - (p = 1) + (p = -1)
20.     net = -((x > 500 AND x < 620 AND y > 200 AND y < 300) AND (p > 0 OR ABS(net) > 0)) * _ROUND((x - 570) - ((x > 570) * 2 + 1) * (y - 250) * 0.3) * 0.9
21.     PRINT "Time:"; _ROUND(t - TIMER), "Score: "; s
22.     FOR i = 1 TO 20: CIRCLE (x, y), i * 25 / 20, 6: NEXT
23.     DRAW "BM0,250C2R200D230BM520,200C4R119D1L119D1R119D20H20C7M-" + STR$(30 - net) + ",100M-10,-15M-10,15M-10,-15M-10,15M-" + STR$(30 + net) + ",-100"
24.     _DISPLAY
25.     _LIMIT 60
26. LOOP UNTIL _KEYDOWN(27) OR (TIMER > t AND y > 250)
27.  

Edit: Prevented double score detection and added some mass to ball and rim.

Edit2: If you found rim bounces weird, you were right. Formulas were messed up, now it is correct (I hope).

Edit3: Made code even shorter removing 13 unnecesery lines

[Qbee]

Time to add some bit more advanced features. Ball-rim collisions would be nice, but it also means giving up my original code minimalism idea. Never mind, I think it is woth it.
What do you think:

Was fun :)

I added "a$ = INKEY$" as last line to make a screenshot: 10 Points isn't bad, or ?

[dajan]

10 is not bad at all, I had to beat that :o)
Crucial is not to look at the time at the end.

[DANILIN]

powerful ball

Code: [Select]

'CIRCLE (x, y), 25, 6
FOR i = 1 TO 25: CIRCLE (x, y), i, 6: NEXT

[TempodiBasic]

@Dainilin
Fine ball !

@dajan
it is the first time that I see embed on the same row of code  calculation and control of  conditions.
Is it an ancient tecnique of spaghetti code to shrink dimensions of source code?
Thanks to share

[dajan]

DANILIN - Now, that seems to be a proper ball :o)

TempodiBasic - I guess you can call it that :o) It might have been preferred approach in ancient times, when each byte mattered, but my original idea was a challenge to squeeze entire game to fewest line codes and variables possible.

[TempodiBasic]

Hi Dajan
just to smile
I have tried to use your tecnique on the same row of calculation and valutation of conditions...
but I have got no good results, my ball stucked when it touched every edge ...
sigh! So I tryed to add IF THEN to see if I have made a bad control of conditions.... but nothing...
So next step I go to trace value of variable on the screen, (for a so little program I don't disturb vWatch) and i see that variables never pass trough the edges!.... Sigh!
then one of mine criticist neuron said me that I have forgotten to test the condition of equality so when variables gained the edge they are not more changed by routine and never went trough the edges so they never have been corrected! And so they stucked the ball.
Naturally I have tried to use condition in calculation and not to simulate physics so don't search for bouncing or gravity effects.
It has been a test to use this tecnique of shrinking.

This is the basic concept

Code: QB64: [Select]

1. SCREEN 12
2. xC = 100: yC = 100: rC = 20: cC = 6
3.  
4. DO
5.     CLS
6.     CIRCLE (xC, yC), rC, cC: PAINT STEP(0, 0), cC, cC
7.     a$ = INKEY$
8.     yC = yC - 5 * (yC >= 20 AND yC <= 460) * (a$ = "W" OR a$ = "w") + 5 * (yC >= 20 AND yC <= 460) * (a$ = "S" OR a$ = "s") - 10 * (yC < 20) + 10 * (yC > 460)
9.     xC = xC + 5 * (xC >= 20 AND xC <= 620) * (a$ = "D" OR a$ = "d") - 5 * (xC >= 20 AND xC < 620) * (a$ = "A" OR a$ = "a") + 10 * (xC > 620) - 10 * (xC < 20)
10.     _DISPLAY
11.     _LIMIT 30
12. LOOP UNTIL a$ = CHR$(27)
13.  

Thanks to share the idea

[dajan]

TempodiBasic, nice one, i see you're getting there :o)
Btw, why did you go with 10 * (...) for boundary correction, 5 * (...) works better there for me. Also INKEY$ has limits for only 1 movement at cycle, you cant go diagonal this way.

Edit: You can delete a lot of this code and it still works:

Code: QB64: [Select]

1. SCREEN 12
2. xC = 100: yC = 100: rC = 20: cC = 6
3. DO
4.     CLS
5.     CIRCLE (xC, yC), rC, cC: PAINT STEP(0, 0), cC, cC
6.     a$ = INKEY$
7.     yC = yC + 5 * (a$ = "W" OR a$ = "w") - 5 * (a$ = "S" OR a$ = "s") - 5 * (yC < 20) + 5 * (yC > 460)
8.     xC = xC - 5 * (a$ = "D" OR a$ = "d") + 5 * (a$ = "A" OR a$ = "a") + 5 * (xC > 620) - 5 * (xC < 20)
9.     _DISPLAY
10.     _LIMIT 30
11. LOOP UNTIL a$ = CHR$(27)
12.  

[TempodiBasic]

I agree with all your feedback
1.
 to manage more keys  (key combo) better QB64 keywords _KEYHIT or _KEYDOWN than old QB45 methods INKEY$ or INP
2.
 10 has been a test for correction that I forgot there :-)
Thanks