• Content count

  • Joined

  • Last visited

Community Reputation

869 Good

About Vorpy

  • Rank
  1. It looks like you aren't looking up the pixels in the masks correctly. Instead of spriteOneVect[s1XAP*s1YAP], something like spriteOneVect[s1XAP+sprite1width*s1YAP]
  2. Constraints

    How is the velocity of the top ball affected by the constraint?
  3. a* on 3d enviroment

    fps is not a linear measure of performance. A drop from 1000 to 500 fps is approximately the same as a drop from 500 to 333 fps, or 111 to 100 fps, or 60 to 56 fps. In each of these examples, the difference in run time is about 1 millisecond. Using your numbers: 1400 fps = .7 ms 520 fps = 1.9 ms 140 fps = 7 ms That 900 fps you're losing is caused by approximately 1.2 ms of processing. If you made your algorithm 4 times faster, you would get approximately 1000 fps. Except that the 1400 fps number was from debug mode, so it doesn't really mean anything... So anyway...it's better to time your code than use your fps counter. And measuring performance in debug mode is meaningless. Complex but highly optimizable code, like STL containers, will tend to run very slowly in debug mode but very quickly in release mode.
  4. a* on 3d enviroment

    If you haven't already implemented a simpler algorithm, like Dijkstra's algorithm, I'd recommend doing that first. A* is a complex algorithm so it can really help to have a good understanding of the more basic algorithms. You might also want to look into the fringe search algorithm. It's simpler than A* and can perform almost as well (or better); in fact, it will probably perform better than your current A* implementation because A* requires a bunch of optimizations to perform well. One big A* optimization is to avoid scanning the open and closed lists to determine if a node is on them. You can keep track of which list the node is on within the node itself (only takes a few bits of memory per node, just be sure to clear this out between searches).
  5. Bathymetry Projection

    It doesn't matter if the projection is expensive, since you only need to do it once. Store the results somewhere.
  6. Menger Sponge Intersection

    Treat the sponge like an octtree, except that instead of dividing each cell 8 ways it is divided 27 ways. For a given ray intersecting a non-empty cell, do the collision against its 27 children and recursively process the non-emtpy children it hits in the order that it hits them until you find the first intersection with a non-empty leaf cell. Each recursive step returns a boolean indicating if a non-emtpy cell was hit, and if so, the location and normal of the hit. Now you just need to perform the intersections between the ray and the grid of 27 cells efficiently.
  7. You have one extra degree of freedom. If you had a third point, or a desired second derivative, or a desired slope at some point, there would be one solution instead of infinitely many. As it currently stands, a straight line could go through your two points (second derivative of 0).
  8. What is your question? Remember that once you have the camera transform, you use its inverse when rendering in order to draw things relative to the camera.
  9. Gimbal Lock

    I think your rotation will be something like 90/90/45 Edit: Actually, are you applying each of the transformations in world space, or in the local space? The transformation you want could also be something like 90/45/90...try different combinations like that to see what works.
  10. [Havok] applyLinearImpulse Question

    It looks like you are adding the position of the rigid body to the torque and linear impulse. When the object is at the origin this has no effect, but as soon as you move away from the origin this will create erroneous torques and impulses. Since the linear impulse make the object move down the negative z axis, this negative z value is being added to the torque, making the body rotate. You only want to apply the rotation of the rigid body to the torque and linear impulse, not the entire transformation.
  11. The closest games usually get to this is storing the movement from the animation alongside the animation itself. Then as the animation is played, the movement is also applied to the object. If the animation has the character moving forward .1 meters in a frame, when that frame is played the character is moved that distance.
  12. Zeroing out the velocity when hitting the wall is fine, but since the key is still being held down, they should get their velocity back in the next frame. Just adding velocity once when the key is pressed isn't enough if you're going to clear it later. You need to apply acceleration or set the velocity as long as the key is down.
  13. Each square has 3 possible values and there are nine squares. There are 3^9 or 19683 permutations. Many of these are not reachable in an actual game (for example, boards where both X and O have 3 in a row). Since the number isn't that high, you could probably just make a table of that size and you'll just have entries that are never visited. Or use a hash table/map/associative container of your choice. You can encode the entire state of a tic tac toe board into a 16 bit integer. A simple way to do this is to assign empty, X, and O the values 0, 1, and 2 (in any order you'd like), then set an accumulator to 0. For each space in the board, multiply the accumulated value by 3 and add the value of that space. Or even encode the entire board into a 32 bit integer by simply using 2 independent bits to store the state of each square. There are far fewer possible states if you account for symmetry. With symmetry, there are only 3 states after the first move (corner, side, and center). But if the goal here is to find weaknesses in an imperfect player, then you wouldn't want to exploit symmetry because the imperfect player may have asymmetric weaknesses.
  14. The state is the entire state of the board, not the state of an individual square. There is only one starting state, which is the empty board. There are 9 valid moves from this state.
  15. A normal does not have a "reference point". It is just a direction. It looks like you're adding the first vertex of the triangle to the normal when you compute the normal, and then subtracting it later. It shouldn't be added in the first place. The dot product should be between the triangle's normal and the direction the camera is facing. The direction from the camera to the first vertex of the triangle is not meaningful here.