Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Collision issues #61

Closed
Elit3d opened this issue Mar 21, 2016 · 7 comments
Closed

Collision issues #61

Elit3d opened this issue Mar 21, 2016 · 7 comments

Comments

@Elit3d
Copy link

Elit3d commented Mar 21, 2016

Not exactly 100% on the collision, so far I have this but it isn't recognizing my player inside of the collision for some reason. Here is my code:

http://pastebin.com/6F4kjEJX

@jdmarsh
Copy link

jdmarsh commented Mar 25, 2016

If you're using SetPosition, it calls Move which edits the polypoints and causes collision issues, there is a bug for it here: #21

@Elit3d
Copy link
Author

Elit3d commented Mar 26, 2016

is there a way around this? been trying to get my player to collide with the walls but gave up as it wasn't recognizing it

@jdmarsh
Copy link

jdmarsh commented Mar 26, 2016

You can comment out the lines where the polypoints are changed in MapObject::Move but even after I did this I was getting some different issues and I didn't want to waste lots of time debugging it.

I went the route of converting each MapObject into an sfml convex shape and wrapping it in my own class. You'll have to copy the MapObject::intersects and MapObject::contains methods to do collision with the convex shapes.

@fallahn
Copy link
Owner

fallahn commented Mar 28, 2016

This is basically down to a badly designed MapObject class on my part. I'm aware of this and plan to rewrite it using the sf::Transformable class. As this will be likely an API breaking change it will be part of version 2 of the map loader (although I can't offer any estimation on when it's done, I only work on this as time allows). Version 2 can always be previewed via the 'next' branch of the repository (and already has many improvements) if you want to track its progress. For a work around in its current state, although it's a little more effort, the box2D utilities do correctly parse map objects, so the box2D collision detection system can be used. Box2D doesn't force you to use the physics part if you only wish to detect collisions - they can be handled by your own callbacks if you'd prefer (check out the box2D docs for this).

@Elit3d
Copy link
Author

Elit3d commented Mar 28, 2016

So I wouldn't need box2d in order to do this method?

@fallahn
Copy link
Owner

fallahn commented Mar 28, 2016

You still need to link to box2D. Using the functions found in tmx2box2d.cpp you can then convert the map objects to box2D objects. Afterwards you can either let box2D use its physics, or you can supply callbacks to box2D to handle your own collisions.

@fallahn
Copy link
Owner

fallahn commented Apr 2, 2016

I've pushed a potential fix for this to the 'next' branch, if anyone would like to try it and offer feedback / pull requests. I'll close this particular issue and point to #21 for further discussion

@fallahn fallahn closed this as completed Apr 2, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants