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

rect collisions don't account for rectMode #48

Open
teacher-svb opened this issue Jun 5, 2021 · 2 comments
Open

rect collisions don't account for rectMode #48

teacher-svb opened this issue Jun 5, 2021 · 2 comments

Comments

@teacher-svb
Copy link

When rectMode is set to CENTER, collision with a rect still acts like it is drawn from the top-left.

@teacher-svb
Copy link
Author

I see in the code comments that there is already a mention for this issue.

this._renderer._rectMode

this gets you the current renderer/canvas, en allows you to find the rectmode currently in use.

@bmoren
Copy link
Owner

bmoren commented Jun 5, 2021

Yes this is a known issue/feature, thanks for bringing it up :)

It's one that is somewhat parallel with the rotation issue (#46) and could be solved by looking at the state of the render in p5 at large. This has the benefit of 'it just working' when the rectMode(), ellipseMode(), imageMode() etc are changed.

Although the downside is that if you're not working with matched geometry and output (eg. a hitbox that does not correlate directly to the visual element rendered) then you might end up in a reverse situation where you're trying to 'correct' the hitbox back to 'normal'

On example of this is if you had an image (rectangular) and it had a elliptical picture inside of it that you wanted to have collide using the collideEllipse function. if we make the assumptions about the modes, it can easily become a situation where things become mis-aligned – eg. imageMode causes the rect(?) collide function to move it's center/cornder coordinates and the ellipse collide function's coordinates are not manipulated because there is no call to ellipseMode() (?).

I'd love to hear ideas or thoughts about these kind of scenarios before working on an implementation. You're correct that there is reference to it. I did think about adding it right at the beginning of this lib, but I ended up holding back as I thought it would ultimately add more confusion having things magically move based on the rendered or a second setting, but I'm totally open to re-opening the discussion!

To kick this idea off – When I was thinking about this I settled on thinking about the collisions as its own set of sort of 'shadow geometry', and as such it could have it's own mode which would reset everything. Something like collideMode() which would set all geometry based collisions to function with offsets to account for the mode change.

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

2 participants