Hi,
When the speed of objects is significantly increased, the collisions are not being detected as they should be.
I hypothesize that conducting collision checks more than once per frame could rectify this, but I dont know how to do so. Does anyone have any advice?
How would checking more than once per frame make a difference?
If the speed is very high, the time window for collision detection might be too small and one frame per 60 FPS may not be enough to catch it.
One frame per second means your FPS would be 1 though
One frame per 60 FPS 
ok, so what does “one frame per sixty frames per second” mean? This is algebra, basically. I am trying to guide you to the answer so you may learn instead of just giving you a solution to copy-paste.
Can you give us an example of what you’re using at an extreme speed? Maybe there’s another way to approach it.
If you’re using the physics behavior, there’s a bullet option.
https://wiki.gdevelop.io/gdevelop5/behaviors/physics2/#body-type
Bullet: If set to true, the object will use a continuous-collision-detection algorithm, slightly reducing the performance but improving the response when moving very fast. Useful to correctly simulate bullets or any high-speed object and reduce the chances for the bullets to go through thin objects
.
It means a second is divided by 60 which means 1/60 second
I am trying to say that the following sentence makes no sense: "one frame per sixty frames per second”
“One frame per second”, “sixty frames per second” and “once every 60th frame” all make sense.
It’s critically important to understand the basics of framerate and how it relates to physics calculations.
I tried using the Bullet option, but in vain. The object is a ball that collides with blocks.
Spherez - a game example from the GDevelop game making app | GDevelop
I am sorry , I am just a beginner.
You are a beginner and you are in good hands. There is nothing to apologize for. I am not chiding you or correcting you, I am trying to teach you something.
A frame takes a certain amount of time to render, depending on complexity.
For each frame, object positions are calculated from that one frame. They don’t glide smoothly and continuously from one point to another as in physical reality.
What happens when the collision detection fails is this:
Frame 1: A X B
Frame 2: X AB
From one frame to the next, A moved to the right, past point x. A never exists between those two points; it jumps from one point to the next. The default collision detection simply checks whether two objects are touching, not whether they would have touched somewhere between positions A1 and A2.
The simplest way to deal with this is to reduce speed.
One hack I use for bullets is to make a “long” collision rectangle. Long enough to make up for the “skips”. The bullets move so quickly that the inaccuracy is not evident.
Or you can use Keith’s approach. Just remember, these are games. Just entertainment. They don’t need to be mathematically or physically correct as long as they look and feel alright.
It is very important that you understand the fundamentals of rendering before you start working on a game, or you will run into endless frustration and take much, much longer to get anything done.
The ball collides with many blocks in different directions at crazy speed, a long collision mask could potentially disrupt the game logic. This is because the extended mask might interact with multiple blocks simultaneously.
Thank you so much for your huge effort!
It helps a lot to see the game. So it’s like Breakout. You may use raycast. I have not needed that yet in gdev so can’t help with the implementation at this time.
In the Spherez example, the timescale is modified to speed up the balls:
I initially tried to increase the timescale. However, I found that the timescale could only be increased to about 4 times its original speed. To overcome this limitation, I decided to use force instead. As a result, I was able to make the game very fast and customizable, with speeds up to about 50 times the original speed. But I’ve noticed that collision detection issues start to occur when the speed is increased to around 10 times.
I have tried implementing raycasting this way. However, I’m still experiencing the same issue.
If you use raycasting, Consider throwing the raycast from the ball’s position in the previous frame to the current position, to determine whether the ball is now in a place it shouldn’t be and move the ball to the collision point/
Keep in mind, however, that this will mess round with the ball physics, and give undesired results.
Have a good look at what you are doing there - you’re setting the old position to the current position, and then raycasting from the current position to the old one (which is the same as the current one).
Set the old position after you’ve done the raycast, not before it. And raycast from old to current.
But my question is why do you need to have it so insanely fast? And what you end up doing here is messing the physics of the ball and it could look ugly.
