Jump to content
  • Advertisement

Doggan

Member
  • Content Count

    559
  • Joined

  • Last visited

Community Reputation

528 Good

About Doggan

  • Rank
    Advanced Member
  1. You can't do your physics calculations at discrete time intervals using the player's current position, because the player is moving. Performing calculations on only the current position doesn't account for the distance traveled since the last physics update. This is the problem you are currently having. If you know the player's position, and the speed he is traveling, you know the exact path the player will travel for a certain time interval. Using this information, you can easily create a 'swept volume' of the player's path, and use this for your collision. Since you are in 2D, the easiest to implement would be a swept circle. When you perform the swept circle test, you will get the point at which the player intersects with the world geometry. You can then use this information to place the player so that he doesn't enter the geometry.
  2. Doggan

    Longest/Farthest Path (A*?)

    Playing with the heuristic of my A* as Alex suggested worked out very well, actually. There were a few other modifications to get better behaviour, such as the setting of end conditions and cost calculation adjustments, but overall it works well. Thanks for the feedback. :)
  3. Doggan

    Longest/Farthest Path (A*?)

    Thanks for the replies. In this thread, http://www.gamedev.net/community/forums/topic.asp?topic_id=547802, Alex seems to suggest that my original technique of using a pathfinder with a flee heuristic is a valid approach. Could someone elaborate on this?
  4. Thanks for the replies. Speak of the devil Dave (in a good way). I just (within the past hour) finished watching your interview on AIGameDev with Alex, regarding Behavioral Mathematics with L4D bots. I actually signed up for the premium membership just to see the interview. I stumbled upon your book earlier, but unfortunately I'm overseas and would have to wait a couple weeks before I could attain a copy. I wish there was an ebook version to purchase :( I understand the concept, but I am struggling a bit with the overall design of implementation. In the interview, you mention storing your weights and charts in easy to modify data files. I get a bit lost when thinking of how to create a system that exposes all these variables to a designer, while also combining it with a rule based system to handle very special cases. The variable names will have to be specific enough so that the designer knows what he is modifying, but these weights might get very specific if I want them to change on a per-situation, per-character, per-faction/squad (etc) type basis. I think the chosen utility functions are really the key to the whole process. They need to be general enough to be abstracted into easily tunable variables, yet specific enough to capture essential data. That is probably my current stumbling block.
  5. Doggan

    Scrolling a vertical background

    Seems like you're on the right track. First you will want to define your layer movement speeds. These will be in the units of CameraUnits / LayerUnits. So 3/4 = .75, which means for every 3 units the camera moves, the layer will move by 4. Then it's simply a matter of working out the equation to satisfy the units: scale = cameraUnits / layerUnits deltaLayerPos = scale / deltaCameraPos If you're not working with a 2D vector class, you'll need to split up the calculations for both the X and Y directions. If you want the layers to scroll at different speeds (i.e. for a parallax effect), you can set the speeds accordingly: layer1Scale = 1/3 // fastest moving layer layer2Scale = 1/2 layer3Scale = 1/1 // slowest moving layer
  6. lua_pushlightuserdata is pushing a void pointer onto the Lua stack. Lua has no way of knowing that the object is of type S_GFX*. Are you sure you want to use light user data in this situation? From the Lua programming manual (http://www.lua.org/pil/28.5.html): Quote:Some people use light userdata as a cheap alternative to full userdata. This is not a typical use, however. First, with light userdata you have to manage memory by yourself, because they are not subject to garbage collection. Second, despite the name, full userdata are inexpensive, too. They add little overhead compared to a malloc for the given memory size. Often times they are used as indices (keys) into tables.
  7. Yes, you're right. Thank you!
  8. Doggan

    Collision response

    The blue line that you're calculating looks like it is the normal at the point of impact. You know the velocity of the ball at the time of impact, so you can easily move the ball backwards along this velocity to remove any penetration with the terrain. You also know the time that was 'reversed' when moving the ball backwards (d = rt). You could assign the ball a bounciness factor (also known as coefficient of restitution) - 0 is no bounce (the ball will come to an immediate halt once hitting the terrain), 1 is completely elastic collision (the ball loses no energy when it hits the ground). You have the normal at the point of impact, so you can easily calculate the reflection vector around this normal. Then change the velocity (direction) of the ball to the reflection vector. Change the speed (magnitude of the velocity) to be something along the lines of: newSpeed = oldSpeed * bounciness.
  9. The XNA website has some free animated models in it's resource section (the Marine and Dude models are the first two that come to mind). They are in .fbx but can be exported to other formats if need be.
  10. Pass the variable as a ref parameter. Or use a basic event notification system. etc..
  11. Doggan

    Windows XP Problem

    I tried the same thing on an HP laptop that wasn't supposed to support XP. It caused me nothing but headaches - driver issues, random freezes and crashes, etc. I gave up and switched back to Vista. A desktop is a different story - you can easily set up any OS you want in that environment. But when you're constrained to a system created by a particular vendor w/ particular specifications, it can be a nightmare.
  12. Doggan

    Vector Projection Length

    The 2nd figure is showing you how to calculate a dot product via trig. cos(theta) = |w| / |v| |v| cos(theta) = |w| ...but this is assuming that the projection of v onto w is w (i.e. v.w == |w|), which is not always valid. In the figure, |w| is actually less than the projection. So you need to account for this: |v| cos(theta) = |w| * v.w |v| cos(theta) / |w| = v.w
  13. Also good to keep in mind, is that the stack size is very limited compared to the heap size. The stack is very fast for pushing/popping data, which is why it's the best choice for small, local function variables. In this case, though, there's no real speed benefit to be gained by using the stack (since it's your main function that's only called once...)... also speed is irrelevant since this is just engine init/deinit.
  14. Quote:Original post by Zahlman Quote:Original post by Doggan Boost has a hash table implementation. Or if you don't want that overhead What overhead? In the past, I felt like I had to go through a few loops to get boost working with projects. Getting it compiled (bjam, etc..), linking properly to my project, etc. I consider this more overhead than a single .h/.cpp file that can be dropped into a VS project file.
  15. I'm not familiar with the "Trace()" function you are referring to... I am assuming you are representing these two objects with simple bounding volumes (spheres, capsules, boxes, etc). This is actually pretty straight forward, and basically involves using relative motion to make one of the objects static, and then using a swept volume of the second object to get your collision. A dynamic sphere/sphere collision can actually be reduced to a static ray/sphere collision through this technique. If you google around, I'm sure you can find theory on this. There are also many good books on the subject. You can probably find actual code for this in any open source physics library.
  • Advertisement
×

Important Information

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

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!