Jump to content
  • Advertisement

Andor Patho

Member
  • Content Count

    27
  • Joined

  • Last visited

Community Reputation

282 Neutral

About Andor Patho

  • Rank
    Member
  1. Andor Patho

    Unity Mid Point

    You're still using Vector3.Lerp incorrectly. The third parameter to Lerp is supposed to be a float in the range [0,1] that acts as a parameter to the interpolation. If you pass the same value to it, you will get the same result. Vector3.MoveTowards would be more suitable for what you are trying to do here.   As for the destinationPoint not being correct, you are creating a new Vector in the set_destination method instead of modifying the private variable (the compiler should generate a warning at least). You are also multiplying by 0.5 at the wrong time. You probably want this: void set_destination() { Vector3 vectorToPlayer = player.transform.position - transform.position; destinationPoint = transform.position + vectorToPlayer * 0.5f; } which can also be written more succintly as: void set_destination() { destinationPoint = (transform.position + player.transform.position) * 0.5f; }
  2. Andor Patho

    Unity Mid Point

    Hi,   your immediate issue is this line: Vector3.Lerp(transform.position,destinationPoint, 1.0f * Time.deltaTime); Lerp returns the interpolated value, so if you want the transform position to change, you should do this: transform.position = Vector3.Lerp(transform.position,destinationPoint, 1.0f * Time.deltaTime); The way you calculate the destinationPoint is also weird, but I'm sure you can figure it out with a little experimentation.
  3.   When is your Shooter::update method called? Is it called automatically e.g. every frame? If so, that is what's causing the problem. The movement of your ship is always in the m_angle direction, regardless of the target position, and m_angle gets updated to point toward the mouse position via Shooter::angleShipToMouse everytime update is called.
  4. Andor Patho

    Grid Based Block Placement

    You're right of course, thanks for the correction.
  5. Andor Patho

    Grid Based Block Placement

      There is a more efficient way to calculate what you are after, you basically want the closest larger multiple of the block size to the current number: blockPositionX = BLOCK_SIZE * ((playerPositionX / BLOCK_SIZE) + 1); blockPositionY = BLOCK_SIZE * ((playerPositionY / BLOCK_SIZE) + 1); If you remove the "+1", you would get the closest smaller multiple.   Note that I used sensible variable names and constants to make the code more readable and maintainable, this is a very useful habit to get into, even if you are doing a one-man project.
  6. Andor Patho

    Specfic AI scripting question

    Based on this I would go a step further and spawn a new game object for the friendly entity after the enemy entity dies, effectively replacing the enemy with the friendly. This is the easiest solution I can think of. The only downside is that if other game objects hold a reference to the original enemy and want to keep the reference after it transforms, then you would need to update these references somehow.
  7. Are you sure it makes sense for the PhysicsMover to be a component in the first place? Based on Your description, it seems to me it's some kind of subsystem which might operate on gameobject components, but why would it itself need to be a component?
  8. Yeah, sorry about the vague wording. Glad it's working now, and you're welcome.
  9. Luckily adding the rotation part should not be that hard either. We can just generalize what we did with the position to the entire transform of the object. We want the object to be "frozen" in view space, so we take the entire transform in view space, and transform it to world space.   So instead of taking the ahead position, multiplying with the inverse of the view matrix, then using it in the model matrix, we do it in a slightly different order: Take the ahead position, plug it into the model matrix and then multiply with the inverse of the view matrix.   Sorry if I confused you earlier with doing just the translation part, but maybe it helped you understand what the different parts of a transform do better. Another interesting way to look at this problem is this: you want the object to be frozen in view space, so what you are essentially trying to do is cancel the view transformation (because you don't want the position and rotation of the camera to have any effect on the object's screen position). The way I showed you works, because if you put all the transforms together, you get: Model * View^-1 * View, which is just Model * Identity. If you are able to modify the view matrix for just this single object, you could also just set the view matrix to identity directly, and achieve the same effect.
  10. Let's try to simplify a bit a reduce the code only to the parts that are relevant to getting the ahead position right.   Start with an identity model matrix. Calculate the world-space ahead position from the view matrix as we discussed. Translate the identity model matrix with the ahead position. This should give you a model matrix that transforms model space to the ahead position in world space. Use this model matrix in the standard transformation pipeline. Comment out any other code that is in that function. How does it behave? If it is behind the camera, flip the input (view-space) ahead position, so in the example you posted above change it to [0, 0, -2, 1].
  11. Try multiplying with the inverse of the view matrix. I assumed based on what you wrote, that the view matrix contains the camera position and rotation, and your transformations get applied as model * view^-1, but the view matrix might already be inverted, so it contains the transformation into view space from world space. That would mean you need to go the other direction, and need to invert the view matrix.
  12. When you are moving the player position around, the ahead position does not change, which means the translation component of your view matrix doesn't seem to affect it (rotation seems fine). I think I see the problem:     You use the Mtx_MultiplyFVec3 function, which guessing by the name multiplies matrices with a 3-component vector. I'm guessing if you pass a 4-component vector to it, the 4th component gets ignored (or considered 0), which in this case is quite important, in short if the 4th component is 0, the vector represents a direction and magnitude not a position, so it can only be rotated, not translated. If this sounds confusing, read up a little on linear algebra. If you work with 3d transformations, the minimum you have to understand are the components of the 4x4 transformation matrix (rotation, translation, scale), and how it behaves with vectors using homogeneous coordinates. If you work out the matrix multiplication on paper, you will see how the 0 or 1 in the 4th component changes the outcome.   Short answer: see if you have a variant of the matrix multiplication function for 4-component vectors.    
  13. If I understand you correctly, you want to calculate the world space position of a point a certain distance straight ahead (in the camera look direction) from the camera. That should be pretty straightforward: take the position of your point in view space - assuming "into the screen" is +z in your coordinate system, this would be a point with coordinates P[0, 0, distance, 1], and multiply it with your view matrix. This should give you the coordinates of your point in world space.
  14. Sorry I haven't responded, I've been AFK a few days.   First, to answer your question: unique_ptr is just a convenient way to automatically delete objects when the pointer goes out of scope, but it is not essential to use it. You can just store raw pointers and delete the objects at the appropriate time (e.g. in the game object destructor). You would need to determine which components you own and should delete, and which components are shared. Even though it's technically possible however, I would not mix objects with different ownership together in one container, seems like asking for trouble.   Second, I will ask some questions of my own if you don't mind. Why is PhysicsMover a shared singleton? If it makes sense for it to be a singleton, should it even be a component? Maybe it should be a subsystem (that acts on components) instead? Astar doesn't really seem like a component to me. If you have a single shared Astar component, where would the calculated path be even stored? How about a Pathfinder component instead, which can have parameters like pathfinding speed vs. accuracy, and uses the Astar subsystem (or can use any associated pathfinding system) to calculate paths that it can store?
  15. At first glance what you are doing seems severely overcomplicated.   First you have to figure out your ownership semantics, and go from there: Who owns the component? Seems like the game object should be the owner, since it's destruction has to destroy the component as well (since you mentioned it will not work otherwise). Is there any kind of shared ownership going on? Not really, since we alreay established the component cannot outlive the game object, so shared ownership just doesn't make sense. Who needs to have access to (store pointers to) the component (other than the owner)? The ComponentManager maybe? Here you have two choices: the ComponentManager will store a weak_ptr to the component (this means the game object will need to store a shared_ptr), or the ComponentManager will store a raw pointer, which means the game object can store a unique_ptr. IMHO the second approach is better, unless there is some specific issue preventing you from using it. When your game object is destroyed, it can simply unregister all it's components from the ComponentManager so no dangling pointer is left behind (which it should do anyway, even if using weak_ptr). Not everyone would agree, so take this with a grain of salt, but IMO using smart pointers everywhere is a poor way of managing object lifetimes, in most cases they are just a poor attempt at masking an underlying ownership issue. I very rarely encounter a justified use case for shared_ptr and weak_ptr - the use cases definitely exist, but just aren't very common.  
  • 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!