5 ms·

Don't represent a ball's velocity with an angle and speed. Use a 2D vector instead. To bounce left/right: vel.x = -vel.x To bounce up/down: vel.y = -ve

Don't represent a ball's velocity with an angle and speed. Use a 2D vector instead. To bounce left/right: vel.x = -vel.x To bounce up/down: vel.y = -vel.y This representation also generalizes to 3D. You'll have a lot of trouble trying to represent a 3D heading with angles, whereas using a 3D velocity vector is straightforward. (In 3D space, using angles to represent orientation can also suffer from gimbal lock whenever you try to rotate the orientation.)

javajosh 12y ago
This is true, but only for this special case where walls are strictly horizontal or verticle. In the more general case an angle, magnitude representation would be fine.
- jerguismi 12y ago
  Wouldn't it make more sense to model also the walls as vectors? Then you mostly need vector-to-vector intersection etc, fairly standard mathematical stuff. If the maze is not standard but can be anything, the walls can be stored in a quadtree or some similar efficient structure.
  - javajosh 12y ago
    >Wouldn't it make more sense to model also the walls as vectors? Yes. That's why r,theta representation makes more sense computationally because reflection across a normal is just adding and subtracting two angles. Of course, you pay heavily for using only this representation on every tick() during merely linear motion, because in the end our displays are cartesian, and you'll have to convert r,theta to x,y. The solution, of course, is to maintain both representations and use whichever one is faster - a classic space-for-time trade-off.
    - sillysaurus3 12y ago
      Not really. That kind of code complexity is simply not worth the tradeoff. You'll waste a bunch of time fixing bugs in your dual representation codebase. It's always better to do the simplest thing first, and then optimize if and only if it turns out to be necessary. In this case, the simplest and most effective way is to use strictly vector representation, because it will result in the lowest complexity codebase. Modern computers are monstrously fast. So fast that it's hard to imagine just how fast they are. The more time you spend thinking about optimizations before they're necessary, the more time you're not spending on implementing features. If it's just for fun, though, go for it. A learning exercise is always nice.
- spuz 12y ago
  I've used both and using vectors for the position and velocity of both the ball and the wall is very much easier for modelling collisions at arbitrary angles in both 2D and 3D. Working out the new angle and magnitude of a ball bouncing off a wall at an arbitrary angle is a nightmare in comparison. Using vectors and vector math also works well when modelling more complex collisions (i.e. solving the problem of balls flying through walls at high velocity) and other physical phenomenon like friction and gravity.
- IanCal 12y ago
  Really? I'd have thought using vectors would be much simpler. The reflection R of an incident vector I hitting a wall with normal N is 2(N.I)N - I

javajosh 12y ago

This is true, but only for this special case where walls are strictly horizontal or verticle. In the more general case an angle, magnitude representation would be fine.

jerguismi 12y ago
Wouldn't it make more sense to model also the walls as vectors? Then you mostly need vector-to-vector intersection etc, fairly standard mathematical stuff. If the maze is not standard but can be anything, the walls can be stored in a quadtree or some similar efficient structure.
- javajosh 12y ago
  >Wouldn't it make more sense to model also the walls as vectors? Yes. That's why r,theta representation makes more sense computationally because reflection across a normal is just adding and subtracting two angles. Of course, you pay heavily for using only this representation on every tick() during merely linear motion, because in the end our displays are cartesian, and you'll have to convert r,theta to x,y. The solution, of course, is to maintain both representations and use whichever one is faster - a classic space-for-time trade-off.
  - sillysaurus3 12y ago
    Not really. That kind of code complexity is simply not worth the tradeoff. You'll waste a bunch of time fixing bugs in your dual representation codebase. It's always better to do the simplest thing first, and then optimize if and only if it turns out to be necessary. In this case, the simplest and most effective way is to use strictly vector representation, because it will result in the lowest complexity codebase. Modern computers are monstrously fast. So fast that it's hard to imagine just how fast they are. The more time you spend thinking about optimizations before they're necessary, the more time you're not spending on implementing features. If it's just for fun, though, go for it. A learning exercise is always nice.
spuz 12y ago
I've used both and using vectors for the position and velocity of both the ball and the wall is very much easier for modelling collisions at arbitrary angles in both 2D and 3D. Working out the new angle and magnitude of a ball bouncing off a wall at an arbitrary angle is a nightmare in comparison. Using vectors and vector math also works well when modelling more complex collisions (i.e. solving the problem of balls flying through walls at high velocity) and other physical phenomenon like friction and gravity.
IanCal 12y ago
Really? I'd have thought using vectors would be much simpler. The reflection R of an incident vector I hitting a wall with normal N is 2(N.I)N - I