Jump to content
  • Advertisement

ravinDavin

Member
  • Content Count

    47
  • Joined

  • Last visited

Community Reputation

102 Neutral

About ravinDavin

  • Rank
    Member
  1. Hi, can someone try to explain on me how is it that the "queue" system works in the microsoft example of particles? The english is confusing on me, sorry. Thanks.
  2. ravinDavin

    Help with reflection Maths

    Nvm, I forgot some basic vector math
  3. ravinDavin

    Help with reflection Maths

    That was great, I didn't even see the vector parallel to N, which was basically the most confusing part. Can you recommend any books on rendering algorithms/Maths that may have simple worked examples to illustrate equations and such? Are there any?
  4. Hi, I attached a picture of something I got from a maths book. It is about calculating angle/direction of reflection. I cannot anywhere find actual worked examples using numbers on any type of math used in different rendering methods. Can someone explain to me why the distance bettween L and N is L-(N.L)N and linked to that, why is the vector N as (N.L)N? I have studied vector math and I understand the basics, but the way these books "explain" things is not helpful for me, I need to see things in action for understanding, any help is appreciated. Picture of my problem is attached http://i44.tinypic.com/i40dna.png
  5. ravinDavin

    Collision Response

    Don't really want to be doing 2 pixel tests per update though. And if I do that for a bounding box test it will not work for complex shapes. [/quote] If you are doing any sort of spatial hashing, then a bounding-box test, then pixel-level collision, I SERIOUSLY doubt you'd see a performance hit. If you're world (or level) isn't that large and/or you odn't have too many collideable objects, I bet you could even get by without spatial hashing. Years ago (2001), I wrote a space-shooter, and it did a bounding box test, then a pixel-perfect test (using load-time bit-masks from the sprites), and i never saw any performance hits. And, I was doing a lot of other stuff. AND, this was over 10 years ago. So, if you find a better method (which, using a 2d-physics library is a better method, see my sig for an example), go for it, otherwise, I'd bet you don't ave performance issues. [/quote] Ah thanks for the replies I'll have a go at it.
  6. ravinDavin

    Collision Response

    Don't really want to be doing 2 pixel tests per update though. And if I do that for a bounding box test it will not work for complex shapes.
  7. ravinDavin

    Collision Response

    Yes, Thats what I was attempting in the first place, But I cant seem to find a good way of determining if it was an X or Y collision. I tried determining it using the rectangle test before the pixel test etc. But it doesn't seem to work flawlessly. And I also was trying to think of a way to do it using the exact point of collision. I guess my main question is what is the best way of determining if its an X or Y collision
  8. ravinDavin

    Collision Response

    I'll give this one last bump too see if anyone can give me more advice.
  9. Yeah man, chicks really dig computer geeks! LOL [/quote] Computer "literates", and yes, they do dig those
  10. ravinDavin

    Collision Response

    I don't see how that will work for me, Each update I implement gravity by increasing the yincrement over time. I need the Y to be set to 0 when a collision occurs, otherwise it will keep falling through the floor. But, I cant really just set y to 0 when I find a collision because then if the player collides with the side of a platform for example, he will stick to it. This is currently my update method of a base CollidableObject class: increment.y += gravity * acceleration * deltaTime check collision using projected matrix(based on x and y increments) if(no collision will occur) move it So what way will I structure it so I can use the oldPosition way to resolve collisions, so the gravity stops incrementing when I am on a platform?
  11. ravinDavin

    Collision Response

    Any tips?
  12. Hi, Again I am on collisions. Ok, so this is what I want to do: If a collision occurs at the bottom of my player, I want to stop the Y increment. If a collision occurs at either side of my player, I want to stop the X increment. I have the code in place which will return a vector of the position at which a pixel collides. I have been trying for quite a while now to do this seemingly simple task. I have access to the point of collision, and both colliding objects' position and size. I should point out, that the resulting vector for the collision point is based on a projected matrix which tests for pixel collision. I have tried nearly every variation that comes to me. Making sure the players Xbounds are outside the other objects, meaning a side collision had occured. Making sure the players Xbounds were in the same range as the objects, and that its Yvalue was less(Top collision) I tried numerous ways with the collision point. Tried to code it to find out if the point of collision was at the bottom/top/left/right of the player (this is what I want to achieve, it seems the best approach) But everything I have done just seemed to fail, It would work on top,bottom and 1 side. It would work on both sides,bottom and not top etc. Any help appreciated.
  13. ravinDavin

    Collision hiccups

    Hi thanks for reply. I am going to take out your point about rounding errors , it seems most likely for me. Would normally be calculating a 2D position on screen using a float type or an int? Or it depends on how I check stuff like bounding boxes etc?
  14. Hi, Just wondering if its normal for sometimes pixel perfect collision detection to make the player go a small bit into a platform. And if it is not, What do you think causes it? Too many collision checks/too fast movement etc? Or just bad collision detection?
  15. I think you're missing the whole point of polymorphism. Declaring a method as virtual makes the link between the link between the class and method in runtime. So you don't need to check of which type your object is. The correct method will be called automatically. If you'll show us your code, we'll be able to see what you're doing wrong [/quote] The reason I check the type is because Obstacle is a child of a CollidableSprite, which inturn is a child of Sprite. So, I am looping through my list of sprites on screen, and finding the obstacles. If the sprite is a typeof obstacle, then I cast it to an obstacle. But with my bouncepad, it doesnt get that far, it does not see it has a typeof obstacle, even though it has a "is a" relationship through inheritance. And I do understand polymorphism, if I have many different obstacle objects all inheriting from the base obstacle class which as the onCollide method, I should be able to cast the sprite as an obstacle and call the onCollide, depending on what type of obstacle it was, the correct onCollide will be called, which is what I am trying to accomplish. [/quote] Ploymorphism = No casting required. Polymorphism enables you to have an array of "Sprite"s, and run different implementations of the same interface without knowing exactly what types of "Sprite"s you're having. The fact that you try to *cast* your sprite to an "obstacle" implies that you're doing something basically wrong. and again, without seeing your code it will be pretty hard to know what is not working in it. [/quote] Mate, Of course I will need to cast it to a certain type. Child classes will more than likely have different methods than their parent, if you have a method that you want to call in a child class, you won't be able to call that method from its parent, it won't know what it is. The virtual method I was trying to invoke was in the Obstacle class, Meaning only an obstacle object could access it, meaning I needed a cast from my parent Sprite class. Thanks for your help anyway. [/quote] I think what he is saying is that you are misusing polymorphism quite heavily, if child classes have different methods than their parents then you should most likely store and deal with them separatly and reconsider if they really should inherit from that parent at all. (In your case it would make far more sense to store your Obstacles in their own list and give those a Sprite member rather than having them inherit from Sprite, Let your renderer keep a list of sprites and keep all graphical stuff away from the game logic). [/quote] I agree it would be much better practice to decouple things like that, but I am working on something that was already coded to a point where refactoring would take alot of time without any significant benefits.
  • 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!