player box collision issue

Hi guys, I have a problem with the collision of a sprite used as a "player box".

When I go to the walls, not always the collision is perfect. Most often stops at a few pixels from the edge, and just holding down the direction against the wall, or trying to detach me and go back to the wall, it resolves with a perfect collision. This is giving me so much trouble, is there a way to overcome the problem? I point out that the box is a perfect square with "bounding box" collision and NOT "polygon", and the walls too are perfectly square with the "solid" behavior activated.

Every help would be highly appreciated

this is a link to download a sample capx with the issue

https://drive.google.com/open?id=0BwNG7 ... DhhemZGZWs

What exactly you want to do? Make the player touch the wall perfectly, or make the player stay a few pixel's away from the wall?

What exactly you want to do? Make the player touch the wall perfectly, or make the player stay a few pixel's away from the wall?

i want a perfect always 100% guaranteed collision between the box and the wall edge.

I do not know how you planed your events, but if you use sprite for the player, try reducing the collision polygons a bit, until the sprite perfectly snaps in the background.

I do not know how you planed your events, but if you use sprite for the player, try reducing the collision polygons a bit, until the sprite perfectly snaps in the background.

The question is simple, and has nothing to do with how I put 2 simple events, it is a perfect square sprite that collides with other perfectly square sprites and occasionally occurs the problem of the attached photo above.

I think it's probably a bug of the tool on the collision management, but maybe someone knows a way to fix it..

imhotep22 try the capx, no events.

https://drive.google.com/open?id=0BwNG7 ... DhhemZGZWs

any help about this prob?

> any help about this prob?

>

There is a verry simple solution. Open the collision box of the box. And subtract or add to every Point about 3. So the collision is a Little bit smaller than it should be.

My friend is not as easy as it seems, the problem is not for a graphic aspect, in fact the player box puts it invisible to sketch the Player's graphics above. The problem is in the mechanical logic of the collision, because instead of detecting collision ON and stop, the tool detects collision ON, then OFF, then ON / OFF etc., you can 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

the problem in my game is strictly related to this collision issue, I have preferred to go to the source of the problem so that it does not give rise to misunderstanding or evasive reasoning about it.

once it resolves this the rest I can fix it by myself ^^

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:

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:

+-----------------------+
|sprite overlaps wall   |
+-----------------------+
   +--------------------+
   |while               | sprite:  move -1 pixel at angle sprite.8Direction.MovingAngle
   |sprite overlaps wall|
   +--------------------+
   +--------------------+
   |                    | sprite: 8direction: stop
   +--------------------+[/code:12g1y7kb]
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.

Wow. You explained it awesome. Thank you for taking the time.

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.

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:

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.

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.

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.

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 <img src="{SMILIES_PATH}/icon_neutral.gif" alt=":|" title="Neutral">

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.

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.