Jump to content
  • Advertisement

alvaro

Member
  • Content Count

    7960
  • Joined

  • Last visited

  • Days Won

    3

alvaro last won the day on September 20

alvaro had the most liked content!

Community Reputation

21384 Excellent

4 Followers

About alvaro

  • Rank
    Legend

Personal Information

  • Role
    Programmer
  • Interests
    Programming

Recent Profile Visitors

43582 profile views
  1. My understanding of behavior trees is that you define a whole bunch of functions in your game code that return a boolean. These can be functions that get information about the situation (Is there an enemy nearby? Do I have ammo? Is my health above 60%?) or functions that actually do something and return whether they succeeded (Move to take cover. Shoot at the weakest enemy within range. Say "Halt!"). A behavior tree is then an expression that joins these functions with the equivalent of the operators || and && from C. The strength of this paradigm is that it's impossible for the game designer to go crazy with the complexity of the behaviors. If you need to define a whole bunch of variables in a blackboard, perhaps this very simple architecture is not a good fit for your task.
  2. If you think those algorithms "don't work perfect", you must have some idea in mind of what you want them to do. Since you are not giving us any details or examples of what you want, we are likely to produce algorithms with the same problems than the ones you are finding on the web. You've been around these forums long enough that you should know how to ask questions by now.
  3. It can be made as accurate as needed. If I remember correctly, there is a factor of O(log(1/epsilon)) in computation time if you require errors of order epsilon.
  4. I completely disagree. The fact that you can't make everybody happy doesn't mean that you shouldn't try to make anybody happy. Names should be picked so they facilitate the process of reading the code. The person reading the code could be you in a few months, so try to make life easier for yourself by using good names.
  5. There is an algorithm called the fast multipole method, which can do this much much faster (it's at least O(n*log(n)), and perhaps even O(n)), but it's tremendously complicated. At some point I understood most of it, but at the time I was only interested in a 1D version of this problem. Maybe I'll give the 3D case a try someday, since it could make for a really cool demo with maybe 1 million particles.
  6. Updating the OP makes it difficult to follow the conversation, so please don't do that. You can just post updated code in another message. Even in the single-threaded scenario, it's probably wrong to update the particle positions as you go. Anyway, I suggest you start with 2 particles, then 3 and see if you can follow the calculations by hand. If you have the working version of the code somewhere else, you can make both versions spit out details of what they are doing so you can track where they diverge. Debugging is an important skill to develop, and this is a good opportunity to do so. Good luck.
  7. I don't have a solution to your problem, but I see a few opportunities for improving your code. pointsx[i] += velx[i] -= fx; pointsy[i] += vely[i] -= fy; That's hard to read. Try to make life easy for the reader. You don't need Math.sqrt() to check if a distance is greater than 1: Just check if the distance squared is greater than 1. You shouldn't use goto where a more descriptive control-flow mechanism exists. In this case it's just a do-while loop. You are mixing the computation of the updated positions and velocities with the details of the representation (aspect, zoom). That is poor taste. A function that is called Compute should not be in the business of doing any part of the rendering, and it should not know anything about how the positions will be mapped to a screen. Oh, maybe I found it: You are updating positions and velocities as part of the parallelized loop, while other threads might be reading from it. There's no guarantee if the other threads are going to read the positions before the update or after the update, or even if they are going to read a valid position at all (maybe they'll get the old x but the new y?). You need to store the new positions and velocities in a separate array and do the updating once the parallelized loop is over.
  8. alvaro

    Quaternion Class Implementation

    A rotation class makes sense to me. If I am a user of the class, I don't care if it's implemented using a quaternion, a 3x3 matrix or something else. Actually, I might even have an attitude class and a separate rotation class, similarly to how you can have a point class and a separate vector class. This is so you can compose rotations, you can apply a rotation to an attitude, but you can't compose attitudes and doing so would result in a compilation error. Or you can just have a quaternion class with a rotate function and be more transparent about how things are implemented. It's a matter of preference.
  9. alvaro

    C++ Game Asteroid

    You are doing it wrong. Why are you using so many pointers? To pick one example, Game::camera_ seems to be a pointer. Why? You can simply use objects --not pointers to objects-- in most places and let the destructors be called automatically. For the few situations where you do need a pointer (say, because you want to have a container of objects derived from a common base class, with polymorphic behavior), you probably want to use something like std::unique_ptr, which again will clean up nicely automatically.
  10. alvaro

    double accuracy in C++

    You can get a thorough answer in the classic 1991 paper "What every computer scientist should know about floating-point arithmetic". If you want just a quick answer to why 1.4 is not an exact double but 1.5 is, the key is that doubles are internally represented in base 2. 1.5 is actually "1.1" in base 2, but 1.4 is "1.011001100110011001100110011001100110011001100110011001100110011001...". Since the binary expansion of 1.4 is infinite and a double keeps only 53 significant bits, some rounding will happen, and in this case that makes the number a bit less than 1.4. So what you are observing is similar to what happens if you write 1/3 to 8 decimal digits. You'll get 0.33333333, which is a bit less than 1/3.
  11. alvaro

    MCTS with a Draw reward

    That seems reasonable. You just need to use an estimate of the expected value of the distribution, and node.rewards/(node.visits+1) is reasonable. A minor matter of naming: I normally call that the "UCB1 formula", not the "UCT formula". UCT is the algorithm resulting from using the UCB1 formula at every node of an expanding tree.
  12. alvaro

    Special Center of Points

    Consider a plane version of this problem, and we'll only try to encapsulate points (i.e., spheres of radius 0). Take three points at the vertices of an equilateral triangle. Draw what the iterative procedure would do on a piece of paper, and you'll notice how the resulting circle is needlessly large. You may want to read the brief description of a few algorithms here: https://en.wikipedia.org/wiki/Bounding_sphere
  13. alvaro

    How close are pointa forming a line

    No, PCA doesn't have any dependence on axes, since what it does can be described without coordinates. Not every least squares method has the problem you describe either. You can use total least squares and again the result won't depend on the choice of coordinates. Another idea would be to compute the area [or volume, or hypervolume, depending on the dimensionality of the problem] of the convex hull of the points, perhaps divided by some normalizing factor (e.g., the hypervolume of a hypersphere with the same diameter as the sample data). [EDIT: Thinking about it a bit more, that is actually a terrible idea: For instance, 3D points that all lie on a plane would pass the test even if they are not on a line.]
  14. alvaro

    How close are pointa forming a line

    What you did sounds very reasonable: Look at what fraction of the variance is explained by the top factor from PCA. The closer to 1 that number is, the closer the points are to forming a line.
  15. alvaro

    Avoid branch instructions

    It's unclear to me that the second and third snippets have fewer branch instructions as the first snippet. In general, write the code as clearly as possible. If the performance is not good enough (as pointed out by a profiler), try to improve the algorithm, try to reduce expensive operations, try to reduce branches and cache misses... but always test to make sure you are actually making the code faster. It helps to look at the assembly output of the compiler to see if your code changes are really having the effect you intended.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!