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

Improve collision system #21

Open
ryukinix opened this issue Oct 4, 2020 · 7 comments
Open

Improve collision system #21

ryukinix opened this issue Oct 4, 2020 · 7 comments
Assignees

Comments

@ryukinix
Copy link
Collaborator

ryukinix commented Oct 4, 2020

Currently we have the following Colliders:

  • ColliderRect
  • ColliderScreen
  • ColliderCircle

All them implement at least the collide method which is used to calculate if two Colliders objects are in the collision state. However that implementation it is obscure, without clear documentation what does and poorly tested.

It is kind weird to use because I need a Collider object wraping the primitive geometric object to use it... which create a weird overhead of primitive geometric copies and worse: I use the internal representation of the collider to render it on screen. I think collision and rendering should be totally decoupled.

The collide operation is not commutative too. If I have two different instances from diferentes classes of Colliders maybe will not work as expected. Suppose I have a ColliderRect called cr and a ColliderCircle called cc. That calls they are not the same:

  • cr.collide(cc)
  • cc.collide(cr)
@wesleycsj
Copy link
Contributor

wesleycsj commented Oct 6, 2020

Yes, i agree too. I think we should make any kind of system some module apart(Since they're are part of systems which normally doesn't fit inherintance for work, only for internal representation). And for this case, make these types part of a Collision/Physics header to be only imported in the game loop main file as something like "#include "Physics.hpp" " // just an example.

@rafaelcn
Copy link
Member

rafaelcn commented Oct 6, 2020

I agree.

@ryukinix ryukinix assigned wesleycsj and unassigned ryukinix Oct 13, 2020
@wesleycsj
Copy link
Contributor

I think we should remove Colliders/Physics files from the project until we define what gonna do in the project.

@ryukinix
Copy link
Collaborator Author

The step to remove colliders should be the same to add the new ones, otherwise, it will break at least two examples: lerax-square-platform and lerax-breakout. That would be bad.

@wesleycsj
Copy link
Contributor

Then i think, it will be freezed by now until a Collision class be provided with minimal functions.

@ryukinix
Copy link
Collaborator Author

No problem. If you want destroy code, you should provide something better to replace it, otherwise doesn't makes sense to me.

@wesleycsj
Copy link
Contributor

In this case, i would not say destroyed, but instead, rewritten. And be sure it is better to provide the initial structure to do the collision detection and resolution instead of a file with some separated functions to just calculate intersections(which could be made in the gameloop because it is too short).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants