player box collision issue

Get help using Construct 2

Post » Fri Jun 02, 2017 6:39 pm

The 8direction behavior logic is basically:

save previous position of sprite
move sprite
if sprite overlaps a solid then move sprite back to it's previous position and stop it

The result is at higher speeds the sprite will stop short of the wall, which is the issue you're seeing.

In cases where that isn't acceptable then one option is to remove the solid behavior from the walls and handle it yourself with events. Here's one possible solution that also allows for wall sliding as well:
how-do-i-make-the-8-direction-behavior-span-class-posthilit-slide-s_p904925?#p904925

Or if you want something less deluxe you could do something as simple as:
if sprite overlaps a wall?
then repeatedly move backward until sprite no longer overlaps wall
and stop sprite

Or in events:
Code: Select all
+-----------------------+
|sprite overlaps wall   |
+-----------------------+
   +--------------------+
   |while               | sprite:  move -1 pixel at angle sprite.8Direction.MovingAngle
   |sprite overlaps wall|
   +--------------------+
   +--------------------+
   |                    | sprite: 8direction: stop
   +--------------------+

The -1 means it moves a pixel at a time which makes the gap be less than 1. You could use -0.1 to make the gap smaller, it just would loop more.
B
94
S
33
G
114
Posts: 5,360
Reputation: 73,781

Post » Fri Jun 02, 2017 7:14 pm

Wow. You explained it awesome. Thank you for taking the time.
Last edited by Cryttexx on Fri Jun 02, 2017 8:46 pm, edited 1 time in total.
My Project at this time: robottory-2d-platformer-devlog_t190807



(Sorry for my english. I know it is not the best)
B
18
S
10
G
4
Posts: 120
Reputation: 3,530

Post » Fri Jun 02, 2017 7:39 pm

R0J0hound wrote:The 8direction behavior logic is basically:

save previous position of sprite
move sprite
if sprite overlaps a solid then move sprite back to it's previous position and stop it


It would seem to me the opposite, that when the box comes to the solid, it slows down and stops a bit earlier..
However, I tried to decrease speed (if speed was the problem) and nothing was fixed :|

Kindly, where did you find this information on the logic of "8 dir behavior"?
Because I checked the manual and did not find anything so specific around.
kindly, i would like to know if you have any other source or if I checked badly the manual...

Anyway, thank you for your attention and helpful advice, Your reputation is undoubtedly well-deserved.
B
13
S
7
G
5
Posts: 448
Reputation: 4,720

Post » Fri Jun 02, 2017 8:36 pm

It's paraphrased from the Javascript source of the behavior which can be found in C:\program files\construct 2\exporters\html5\behaviors\8driection\runtime.js. Also how I described it working does cause what you're seeing. Lower speeds reduces it but doesn't stop it.

Here is a post from the dev that says the same thing:
8-span-class-posthilit-direction-span-possible-bug_p882228?#p882228

Here is a rough visual example of how it works. When the wall is overlapped the sprite jumps to the last position when it was not overlapping, stops, and if the player is still pressing that arrow key will accelerate toward the wall again.
Image

Anyways that's why it happens. Making it better isn't exactly "no programming required" friendly from a user standpoint. It's irrelevant to me if it's considered a bug or limitation, but there's always the option of bringing it up as a bug report.
B
94
S
33
G
114
Posts: 5,360
Reputation: 73,781

Post » Fri Jun 02, 2017 9:22 pm

ok @R0J0hound, im agree with what @Aphrodite say in the link you shared.
at this point I do not think it's a bug, it's just something badly designed and done worse. Thank you anyway for further clarification and deepening. At least I know now what I have to do. And still apologize for my English pessim translated with google.
B
13
S
7
G
5
Posts: 448
Reputation: 4,720

Post » Fri Jun 02, 2017 9:29 pm

NN81 wrote: see if you put an event that when the BOX collides with the wall adds 1 to a variable X. If you do it you will realize that when you go with the BOX against the wall the value of the variabe does not rise by one and then it stops but it also rises by 3/4 units if I hold down the key to send the box to the bottom :|


Some comments about that remark.

Of course that's what is gonna happen. It is impossible to stop exactly there where the wall is.
For 1 reason: You are Human.

The 8direction stops at solids as follow. When it overlaps a solid, it pushes the sprite back to from where it came from until it is not overlapping the solid no more. The famous Push-Out-Off_Solid_Routine.

So what happens. It hits the wall. The push out happens. You are still pressing the key, so it starts accelerating again. You literally push it back into the solid. It hits the wall. The push out happens again. And so on, for a few ticks.

Set up that construction that you describe, run up against the wall, see the variable go up every time you press the key when just leaning against the wall.

Still dont believe me ?

Set the acceleration to ridiculous high. Now the variable counts only 1 collision when you run in to the wall. But, the sprite ends up way off the wall. Meaning, the push-out had to push it out to much.

Set the acceleration back 600. Set the Deceleration to 12 or so. Now move towards the wall. But lift your finger before it hits the wall. When it now hits the wall, that variable is registering only 1 collision. Prove that it is your finger and only your finger.

Do i like this behaviour? No, not at all. Can it be changed ? I dont think so.

Some things happen before the start of a tick. Other things happen after the end of the tick.
The push-out happens before the start of the tick, because you need the position of that sprite in all the events.
The acceleration (unattended behavior thing) happens after the end of the tick, before the drawings.

Is it easy to work around? Nope, not that i know. But, hey, i am for sure not a c2 pro.

You can limit the keys, like in this example.
And if you are careful with positions and sizes, you can even snap to a pixel, as in this example.

https://www.dropbox.com/s/ecbn35mqsnln4 ... .capx?dl=0

But i dont think that it is totally flawless.
Bottom line ....
If you want pixel perfect games, you better might forget making video games. Those games are linked to a frame rate, and the sample rate that comes with it.
Second bottom line.
When you need a pixel perfect game, you are better of scripting EVERYTHING. You can not use pre-made behaviours at all. And i can not help you with that. Really sorry (4 myself).

Edit: i see that there are new posts, posting anyway.
B
33
S
18
G
28
Posts: 2,493
Reputation: 20,950

Post » Fri Jun 02, 2017 10:06 pm

In my ignorance what I do not understand is why you keep talking about "overlapping" when a sprite has "solid state" there is no overlapping but only a contact / collision with this.
What else I do not understand is why all this complicated way to handle collision when XY coordinates of all sprites are well known to the tool, so it would be very easy to point out when the box has to stop on a sprite with "solid state".
However my problem is those microscats because the graphics with my player's animations are bound to the box, so when this does "crazy collision" my Player suddenly changes animations from idle to walking, causing a very unpleasant effect in the game.
B
13
S
7
G
5
Posts: 448
Reputation: 4,720

Post » Fri Jun 02, 2017 10:14 pm

NN81 wrote:it would be very easy to point out when the box has to stop on a sprite with "solid state".


How would you program that ? (pseudo algorithm)

Keep in mind that at 60 FPS and a speed of 600 pixels/second, the sprite moved 10 pixels between between 2 ticks. Keep in mind that you, in reality, dont know the FPS for every targeted device.


PS It is possible in c3 with its improved steps on the Bullet. But i dont understand steps yet.
B
33
S
18
G
28
Posts: 2,493
Reputation: 20,950

Post » Fri Jun 02, 2017 10:37 pm

Oh boy.
B
223
S
125
G
8
Posts: 146
Reputation: 22,243

Post » Fri Jun 02, 2017 11:51 pm

Well I actually agree the way the behavior works is in want of a revamp. It should be made to not have this issue, and it is possible.
B
94
S
33
G
114
Posts: 5,360
Reputation: 73,781

PreviousNext

Return to How do I....?

Who is online

Users browsing this forum: DiegoSanudoDT, R0J0hound and 8 guests