How do I find what side of an object another is colliding with? (learning vectors) [SOLVED]

[teal quest]

I'm working on a little spaceship dogfighting game, but I've reached the point in developing my collision code that I need to figure out what side of a rectangular object I'm colliding with in order to set the normal vector so ships (and potentially other objects) can bounce off at the correct angles. This code needs to work with the target object (oWall) rotated and scaled. Presently I can set the normal so the player ship bounces off the top and bottom of the wall object OR the sides, but as it stands I can't have both unless I can on the fly toggle the normal vector based on what side of the wall the ship is hitting.

Any help, suggestions, resources, etc, would be appreciated.

[teal quest]

For now the best solution I've found is to, any time that wall object is created, create 3 invisible copies of it with a different collision mask that corresponds to the side I'm looking for (ensuring they have the same scaling and image angle). When the side is hit, the normal vector is updated in the collide event. Seems to work with what I need for now, but it just feels like there's gotta be a more elegant solution.

[gritty lava]

Would Gamemaker's physics system be of interest here?

[teal quest]

I honestly only barely began looking into the physics system before I backed out. My early impression is that it'd probably be very useful for a physics heavy game, but I was a bit overwhelmed by how different it all seemed from doing things the more traditional way. Admittedly part of my hesitance was that I'd have to rewrite a lot of my code in a (at least apparently) very different kind of way to make it work.

[gritty lava]

As someone who's gotten into it a few times I can say it can be a bit to process depending on how indepth you want to get with it.
It can get pretty involved, but you can ignore most of the ins and outs once you're past the initial hurdle of setting up a physics room, collision objects, and learning their parameters for stuff like bounciness and mass.
If you feel like it would be worth the time to scope it out, I'd recommend starting a new project just to get down some tutorial movement/ collision basics

[teal quest]

Yeah, that's probably the smartest move to learning it, I think I will at some point. It seems like there's a lot of potential there.

[amber wigeon]

Im not super sure I understand, but a basic approach would be to just : 1) compare position between player and target. if player is to the right and between top and bottom, then you are colliding with the right side, etc. If you need something more complex you need to use some vector math, TurboGML has a handy vector functions library. SamSpade (https://www.youtube.com/@samspadegamedev) has a series of videos on vector movement that can orient you further (he also has his own vector functions which are very interesting)

[teal quest]

Yeah, I've tried comparing the player's position to the target's sides, which worked up until the point I had the wall object rotated. At that point the "left side" of the wall could very easily be on the bottom, top, right, or somewhere between (from the viewing perspective), so comparing x and y values is no longer an option (at least as far as I've been able to figure out).

As it stands, the "dumb" solution is working for me for the timebeing and I can move forward with other parts of my project, but I'll revisit this if I find a better solution down the road.

Also SamSpade has been an excellent resource for me learning this stuff, but I'm still working through those videos.

[amber wigeon]

I haven't tested this but it should work (with angles not vectors) using (point_direction(enemy_x,enemy_y,player_x,_player_y)-enemy_angle)%360 should indicate the relative angle to the enemy. You'll probably be better off with a vector based approach, but meanwhile you could give this a shot

[teal quest]

As far as I can tell from testing it, it only really works perfectly if the object isn't unevenly scaled and isn't rotated. If it's evenly scaled and rotated, it usually works... but with an occasional hiccup where the player just gets stuck. Additionally if the wall object is elongated in one direction it can, for example, sometimes register hitting the right side of the object close to the top as if you're hitting the top itself.

This is the closest I've gotten it to work, though, outside of the 4 wall object trick I'm currently using.

[amber wigeon]

if the object is elongated the angle limits will be different than the ones I wrote. You could find them by doing point_direction(x,y,top_bbox, right_bbox) (with each corner, not sure if the bbox is written like that or not)

Not sure about the "hiccup" though, you would need to go into the debugger and step through that.

[teal quest]

Although bbox_top/bbox_bottom/etc don't really work with rotation, I calculated the sides via other means (basically just sprite_width/height and lengthdir) and did as you suggested, and now the collisions seem to work perfectly (hiccup gone as well). Thank you, and thanks to Dontae as well, this has been a great learning experience for me and I appreciate the input. I already know what my next big hurdle is going to be and I feel comfortable making another thread to address that when I'm ready to.

[amber wigeon]

you would calculate with bbox before rotating it and store the angle that matches the corner at the objects initialization. Glad its working though!!