1
\$\begingroup\$

Imagine a scenario where there are four cubes. Two blacks that do not move, one red moving at a constant speed of two (2) straight and the other blue moving at a constant speed of five (5) also straight.

enter image description here

They all have equal bounding boxes.

By doing a test, I realized that if I put a command so that as soon as the red cube strikes against the black it turns left, the command does not run as soon as they collide ...

With the blue he wanted him to turn right as soon as he hit. The command takes longer to happen, I think because it is faster than red ...

Illustration of the incident:

enter image description here

It seems that the faster the object is, the longer it responds to the collision command. I would like you to give me a solution to this problem.

I've already moved with some bounding box options, but nothing that has given the desired result.

enter image description here

I also moved at the speed of the room, but it did not work either.

enter image description here

Sorry for any translation error. Thanks in advance!

\$\endgroup\$
2
\$\begingroup\$

The reason coloured cubes behave this way is because of how you treat collision check - it's not a bug, it's about setting up collision checking system.

Predicting collisions vs computing actual collisions
Imagine a cube with speed equal to 1; it will move one pixel forward each room step, until collision with a black cube occurs.

enter image description here

Since you moved the cube pixel by pixel onto collision, it will snap with the black cube one step before the actual collision occurs.

enter image description here

Let's say step tn is the time (in room steps) the moving cube snaps with the black one, without actually colliding with it; this is represented in the above image. Then the next step, we call tn+1, is the very moment the moving cube is overlapping with the black cube even if for a single pixel.

enter image description here

The highlighted area (intentionally exaggerated) is the result of overlapping sprites when collision is detected, but there are no countermeasures for correcting coordinates.

When you predict a collision (e.g. place_meeting(objID,x+a,y+b), where arguments are current coordinates plus speed values), you want to know if the next position implies overlapping (not snapping) of objects sprites.

On the other hand, computing a collision on the current coordinates (e.g. place_meeting(objID,x,y)) you are asking the engine if the object is hitting a given object already: so the collision as we mean it has already happened. Before going on with game logic, you should carry the object away from the other one so that it doesn't seem it kept moving forward before collision actions occurred.

enter image description here

If the cube moves faster, there may not be a moment when the moving cube snaps the fixed cube; it is a bunch of pixels in front of the still cube, and the next step it is overlapping the other, or even be moved beyond if travelling at very high speed!

Possible solution
Try to check for collision before moving the cube; if a collision is detected at next position, before changing the cube direction, use move_contact_solid() to snap the moving cube to the fixed one, right before the actual collision occurs. Then, apply the speed direction variation to turn the cube around.

enter image description here

Remember: such solutions are always independent from room_speed or other time variables, it's only on the order actions are performed in your game logic.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.