Yes folks, One of my projects has just become un-completable, not because I can't do it, its because GM can't.
Basically the game was going to be like breakout except you used the mouse to control the bat. the x-axis controllled image_angle and the y axis moved the bat up and down. The big problem with GM is that no matter what i do, (masks, unchecking preciseboxes, collion_free/collision_point, room speed) the result always stays the same. The ball gets stuck in the bat when you move the bat into the ball, and it becomes stuck and its due to image_angle.Inhope they fix this in GM7 because then maybe this project will be made successfully…Here is a screenshot if my description didn't help:
Now for the bug:
EDIT: I fixed the problem and the project is back on!!Hooray! (hands cookie to all members of 64 Digits..)
Use collision codes and see what you come up with. Oh, and use lenghdir_x and lengthdir_y. Those combined might be the answer your looking for.
Don't use image_angle. rotate the whole object and use draw_sprite_ext (hope you have registred GM6)
he does… obviously…
I hate it when that happens. This isn't impossible in GM, no. It's certainly possible.
Write your own collision system.
I'll try Onyx's approach, but it would make the files size shoot up and I don't know if my comp can take 360 sprites made at once, but I'll give it a try (It can't hurt can it?)
It seems the image_angle can't handle collisions very well, (I hope this is fixed in GM7) @bryan: I think that would require a dll, and I can't code C++ (or whatever dll are made with…)Thank you Onyx, that has solved my problem, many thanks! This means I can work on this game, and if it gets good enough release it here!
NEVER EVER use image_angle if you don't have to! It sucks! Now you know why ;)
Well, I kinda did before,but I suppose its an easy and less memory consuming way to rotate stuff, so it has its advantages in some situations.