player box collision issue

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.

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.

Oh boy.

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.

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

finally i have discovered how to avoid this issue.

The problem of space between Player Box and Walls, happens when dragging objects on the layout instead of placing them manually Assigning integers pixel values for x, and y position of objects.

for example if you don't use pixel grid and you drag a wall at X 345,5 position, instead of 345, the issue occur, but if you use integer pixel not occurr