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. Worked fine.

I hope i helped you

Cryttexx

(We are so near to the Prototype Realess )

> 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

I dont understand what your problem is. There is a logical mistake. Ok. But is this as important for your game? I think no. So your first problem that the box is not direct at the wall is solved. So your problem is that there is just a logical mistake. I would play around with it, but i dont have the time. Sorry

Cryttexx

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.