1. I have a "ball" at
x = 10
y = 15

next tick it's
x = 15
y = 20

How do I figure out what y position the ball will be at x = 30?

I can make it into a vector .. but then what?
JavaScript / NodeJs.

2. Assuming constant velocity? Or gravity being 9.8 m/s^2 down the y-axis?

If just constant, you want the derivative of the function, i.e. the gradient of the line, which is first found by solving the simultaneous equation for those two known points.

y = xa + b.
15 = 10a + b. 20 = 15a + b.

15 - 10a = b = 20 - 15a.
-10a = 5 - 15a.
0 = 5-5a.
5a = 5.
a = 1.

15 = 10(1) + b.
b = 15 - 10(1).
b = 5.

20 = 15(1) + 5. Checks out.
y = 30(1) + 5 = 35.

Another way might be to say take the second position from the first to define movement per tick, then divide the distance to target x by movement-in-x-per-tick, to give ticks it'll take. Then just add that many movement-in-x-per-tick by that tick count.

E.g. 15-10 is 5. That's x per tick.
30-15 is 15 change in x total. /5 x-per-tick is 3 ticks.

20-15 is also 5 y per tick.
3x5 is 15 change in y after 3 ticks. 20+15 puts y at 35.

_____________

Velocity does not matter, as I don't care when it's at point y.
No gravity.
It's a bot for a pong game.

Ok, I know the current position and the last position.
Code:
```    var currentPoint = {x: gameData.ball.position.x, y: gameData.ball.position.y}

var diff = {
x: currentPoint.x - oldPoint.x,
y: currentPoint.y - oldPoint.y
}```
And I know the X where I want to intercept the ball.

Code:
`var paddlex = gameData.paddles[socket.id].position.x;`
I would need to figure out at what rate is y rising for every x, right?

Code:
`var yrate = diff.y / diff.x;`
As we know target X and current X I know the distance:

Code:
`var bla = yrate * (paddlex - currentPoint.x)`
Is bla now the difference between current y and target y?
currentPoint + bla would be estimated target y?

4. Ah, nice. Implementet it your way and it works \o/

Code:
```function foo () {
var currentPoint = {x: gameData.ball.position.x, y: gameData.ball.position.y}

var diff = {
x: currentPoint.x - oldPoint.x,
y: currentPoint.y - oldPoint.y
}

var xchange = targetx - currentPoint.x;
var xticks = xchange / diff.x;

var ychange = xticks * diff.y;

console.log("estimatey: " + currentPoint.y + bla);

oldPoint = currentPoint;
return currentPoint.y + ychange;
}```
Neato.
I appreciate it

5. Just don't forget to test/case for zero difference (div 0 error), or negative difference from moving in the opposite direction.

6. Originally Posted by Daneel Trevize
Just don't forget to test/case for zero difference (div 0 error), or negative difference from moving in the opposite direction.
I think I will put the paddle in the middle when the ball is moving away from me.
There is also the case on how it bounces off the wall .. but that will be too complex for now.

7. A single bounce will simply mirror the ball the distance it would otherwise be past the boundary in one axis that far below it. E.g. start 3 below, moves 5 along and 5 up ignoring bounce, that's 2 over, bounce actually puts it 2 below at the same 5-along horizontal coordinate.
Again, assuming a single bounce/boundary is encountered. iirc. I think this also gives you perfect reflection & momentum conservation, no worries about simulation with collision detection accuracy (i.e. no need to define an area or volume then check the ball one intersects, just a half-plane and a point).

8. Oh shit fam u right ))
That works.
Thank you.

9. Np, I think it holds so long as you're doing regular only-reflecting-paddles pong, and not air-hockey style where the angles could vary & the puck could bounce off opposing sides within 1 tick. Even then it might just be some some modulo of the unbounded height by the table height to determine current direction sign & which side to offset from.

10. Slightly random, but do people have any particular recommendations for books worth buying on the topics of:

General algorithms and data structures (interested in knowing if people still suggest buying Art of Computer Programming: Vol 3).
Parallelism/Concurrency/Multithreading. In general or in C++, Java or Javascript (which afaik would be chiefly Promises?).
WebGL.
Vulkan (I know 1.1 was just released, hoping there's a polished 2nd edition of something recommended to be released soon).
RISC CPUs (MIPS, RISC-V, maybe ARM).

11. Algorithms & Data Structures: I've got a copy of The Algorithm Design Manual at home by Skiena. It's a good book but I don't read it much tbh.

Concurrency: Go makes concurrency easily accessible with channels and goroutines. I recommend playing around with it before looking at Promises, Actors, ListenableFutures etc. As far as books go The Go Programming Language by Kernighan is good. For actors I'd just read the Akka framework docs and start hacking.

12. Originally Posted by Daneel Trevize
Slightly random, but do people have any particular recommendations for books worth buying on the topics of:

General algorithms and data structures (interested in knowing if people still suggest buying Art of Computer Programming: Vol 3).
Parallelism/Concurrency/Multithreading. In general or in C++, Java or Javascript (which afaik would be chiefly Promises?).
WebGL.
Vulkan (I know 1.1 was just released, hoping there's a polished 2nd edition of something recommended to be released soon).
RISC CPUs (MIPS, RISC-V, maybe ARM).
Yeh, Knuth is still the standard. Sedgewicks books are also good.

13. Sedgwick is still the standard in algorithms and data structures. I've never known anyone actually own or read knuth.

14. Originally Posted by elmicker
Sedgwick is still the standard in algorithms and data structures. I've never known anyone actually own or read knuth.
Really? That must be a U.S./U.K. thing, its p much the opposite here.

15. Segdewick is definitely the book of choice at the university I used to work at in the UK. I would recommend it too.

16. Originally Posted by erichkknaar
Originally Posted by elmicker
Sedgwick is still the standard in algorithms and data structures. I've never known anyone actually own or read knuth.
Really? That must be a U.S./U.K. thing, its p much the opposite here.
It's because Knuth is a seriously challenging read. It's a still-incomplete, multi volume reference written in a hypothetical assembly language. It's practically useless for almost all uses. In my experience those who have claimed to have "read taocp" are lying and aiming for nerd cred.

17. Originally Posted by elmicker
Originally Posted by erichkknaar
Originally Posted by elmicker
Sedgwick is still the standard in algorithms and data structures. I've never known anyone actually own or read knuth.
Really? That must be a U.S./U.K. thing, its p much the opposite here.
It's because Knuth is a seriously challenging read. It's a still-incomplete, multi volume reference written in a hypothetical assembly language. It's practically useless for almost all uses. In my experience those who have claimed to have "read taocp" are lying and aiming for nerd cred.
Well, I don’t think vol 5-7 will ever come, but the rest is useful.

Also

hypothetical assembly language.
http://www.gnu.org/software/mdk/mdk.html

18. Right, but if you're going to go to the effort of learning yourself an assembly language to improve your algo chops, you'd almost certainly be better served learning one with practical applications. Given most (good) unis are already teaching arm or x86 in some form, throwing a second assembly language in is deemed to be a waste of time.

19. Originally Posted by elmicker
Right, but if you're going to go to the effort of learning yourself an assembly language to improve your algo chops, you'd almost certainly be better served learning one with practical applications. Given most (good) unis are already teaching arm or x86 in some form, throwing a second assembly language in is deemed to be a waste of time.
Well, I suppose Sedgwick is a much more practical, and much less theoretical. I can see how that would more useful to practitioners, but I will stand by Knuth being more useful to actually teach you the math.

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•