Efficient really quick motions with collisions?

I was just sort of wondering about something in general how people do their movement/collisions. I usually have the approach that basically boils down to moving one pixel at a time inside a loop looping X amount of times, and I think most people use that.

But for this one instance in this project of mine I want the character to be able to close-to-instantly move to a designated spot on the screen, with collisions, but no matter how I try to use the same-old approach to moving there quickly with pixel-perfect collision I seem to get the slightest of framerate-drops. I assume this is because considering the distance sometimes to move every screen-refresh can be upwards of 200+ pixels each time.

But I know that for example a game like Smash Brothers has done this for the Fox and Falco characters (forward+B), and they clearly pulled it off. My game doesn't even have anything but the main character yet!

So I'm wondering if anyone has a tip for a speed-efficient way to do this. Maybe I have something wrong somewhere in my code that adds to this (it's not TimeDelta related and being run much more often than needed, and the collisions are "bounding box"), but it doesn't seem that way and checking for collisions 200-300+ times before moving seems bad practice overall.

Help?

I haven't done much about that, but I have one thing on my mind: Bullet behavior. If you set its speed to instant, it will check for collision if you use bullet behavior's "On Step" trigger.

Worth noting.

Hmmm, that sounds interesting.

Might look into it if I can't get it better with my own code, thanks!

I believe David mentioned the possibility of porting his Move Safely object (or an equivalent) to Construct, but that's not likely going to help you for now

I suppose you could reduce the number of steps in your loop, then back out when collision is triggered. For instance, if your player hitbox is, say, 64px wide then you can very easily move in increments of 32px and know that if there is something to collide with, then a collision will occur. At that point, run a second loop to back it up to the point of impact.

It would be much more efficient than advancing your object by 1px every time you loop.

To streamline your collisions further you can change the sprite's collision mode to Bounding Box for the first step, then if collision is triggered switch it over to Per Pixel to back it out if that's what you need. Per Pixel is a lot slower than Bounding Box (especially since Per Pixel does a Bounding Box check first, then a Per Pixel check second).

Thanks for the suggestion! I threw some variables around and got something working fine enough. But I was considering what you said with moving half the width/height, but a problem is it's a 360-degree movement.

It might be hard to implement but something like being able to tell how much a bounding box is overlapping something else and from what side, X and Y respectively, would be ace... then forcing back that amount with a single event.

Somebody mentioned Flash has something similar to that. But I'm managing as it is.

As an aside, what is the difference between "advanced" collision/overlap and the normal?

The system condition just gives you more control over picking of the instances that are colliding.

It's more useful, I think, if you don't want to pick the instances for whatever reason.

I was considering what you said with moving half the width/height, but a problem is it's a 360-degree movement.

Why is that still a problem? You can move in 32 pixel steps in any direction. And it cuts the CPU usage by a factor of 32 - much much faster.

[quote:3ahsxcfo]It might be hard to implement but something like being able to tell how much a bounding box is overlapping something else and from what side, X and Y respectively

Just compare the values .left/.top/.right/.bottom of the two objects.

Thanks for the tips!

But I know that for example a game like Smash Brothers has done this for the Fox and Falco characters (forward+B), and they clearly pulled it off.

No, actually theres just a long hitbox that appears for the length of the attack. You can trust me: i'm probably the only guy on these boards (along with my brother) who has played smash brothers since it's dawn. Me and quazi still play often, and we know all about the hitbox postions and such (yes, we're hardcore melee players ). I suggest you should think of multiple ways to acheive a desired result. While a loop can work well, it's often the slowest way of doing something.