Jump to content

View more

Image of the Day

WIP title screen for #DeathOfAPartisan #screenshotsaturday #gamedev https://t.co/qJNhfZCvd4
IOTD | Top Screenshots

The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.

Sign up now

Custom Physics: Preventing objects from losing velocity in certain situation

4: Adsense

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 Nickie   Members   


Posted 12 April 2014 - 05:12 AM

Illustration: http://s22.postimg.org/7agd30vap/Untitled.png

So the little box is my character. The red arrow shows the current velocity(Some force to right + gravity). Below it are 2 blocks which has the same height. The problem is that my algorithm would solve the collision normals with error.(You can see them in green). These would mean that my character would not slide, but will stop in one place.  In this place both collision normals should have been UP(0,1).


Implementation details:

I'm following this tutorial: http://gamedevelopment.tutsplus.com/tutorials/how-to-create-a-custom-2d-physics-engine-the-basics-and-impulse-resolution--gamedev-6331



Is there something I miss and how can I fix this problem?


#2 Buckeye   GDNet+   


Posted 12 April 2014 - 08:56 AM

I took a brief look at the tutorial. The problem you're having appears to be a limitation of the very simple collision detection method described in that article. Assuming you're using AABB collisions, the method results in just what you're seeing. It's likely you are implementing it correctly.


Unfortunately, there isn't a simple fix for that simplified collision detection system. You can try other collision/physics engines like Bullet or ODE. Those are 3D systems which may be overkill for your purposes. Perhaps others know of a 2D engine you could use.


If you're just trying to write your own engine for the experience, you could add a routine that extends AABBs when more than 1 collision is detected. In your example, that would result in combining the AABBs for the two adjacent boxes, and should result in just a vertical normal for the collision.

Edited by Buckeye, 12 April 2014 - 08:58 AM.

Please don't PM me with questions. Post them in the forums for everyone's benefit, and I can embarrass myself publicly.

You don't forget how to play when you grow old; you grow old when you forget how to play.

#3 Randy Gaul   Members   


Posted 12 April 2014 - 12:08 PM

This is a difficult problem that shows up in even very experienced programmer's simulation for large companies. Very old-style games would use tile arrays, which don't have this problem due to the quantization of an array.


It is much easier to avoid the problem altogether. You can try to manage your levels by-hand to make sure that there is no geometry that has adjacent rectangles that the player can snag onto. You could also use a different shape for the player, perhaps a sphere or a shape similar to this: http://i.imgur.com/P7NNc9T.png

#4 Nickie   Members   


Posted 13 April 2014 - 01:11 AM

Thank you for your replies-oppinions.


What I'm going to do is to prioritize the collision response of the objects that have largest area overlapped. This is most likely to solve the other problem(I hope).


P.S Randy nice tutorial you have written. It was really easy to follow and everything took place in my head. Good job.



Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.