Efficient really quick motions with collisions?

For questions about using Classic.

Post » Sun Mar 29, 2009 6:13 pm

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? :(
B
5
S
2
G
3
Posts: 234
Reputation: 1,818

Post » Sun Mar 29, 2009 7:01 pm

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.
B
62
S
21
G
12
Posts: 1,910
Reputation: 13,155

Post » Sun Mar 29, 2009 7:06 pm

Hmmm, that sounds interesting.

Might look into it if I can't get it better with my own code, thanks!
B
5
S
2
G
3
Posts: 234
Reputation: 1,818

Post » Sun Mar 29, 2009 8:59 pm

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 :P

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).
Moderator
B
5
S
2
G
6
Posts: 4,348
Reputation: 10,971

Post » Sun Mar 29, 2009 9:12 pm

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?
B
5
S
2
G
3
Posts: 234
Reputation: 1,818

Post » Sun Mar 29, 2009 9:31 pm

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.
Moderator
B
5
S
2
G
6
Posts: 4,348
Reputation: 10,971

Post » Sun Mar 29, 2009 9:46 pm

[quote="konjak":3ahsxcfo]I was considering what you said with moving half the width/height, but a problem is it's a 360-degree movement.[/quote:3ahsxcfo]
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[/quote:3ahsxcfo]
Just compare the values .left/.top/.right/.bottom of the two objects.
Scirra Founder
B
359
S
214
G
72
Posts: 22,946
Reputation: 178,468

Post » Sun Mar 29, 2009 10:48 pm

Thanks for the tips!
B
5
S
2
G
3
Posts: 234
Reputation: 1,818

Post » Mon Mar 30, 2009 7:39 pm

[quote="konjak":1wxljbxq]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.[/quote:1wxljbxq]
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 :mrgreen: ). 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.
B
25
S
3
G
6
Posts: 1,197
Reputation: 5,620


Return to Help & Support using Construct Classic

Who is online

Users browsing this forum: No registered users and 1 guest