I believe most JVMs use heuristics to determine which code is important enough to spend time compiling and optimising. So on startup, it uses a basic mechanism to get the program running, as much initialisation work is done once and never executed again. As the program spends more time running particular segments, these are progressively recompiled and optimised.
It is possible that you're seeing this in action. It would be interesting to keep a record of the delta times and number of updates in a buffer, and log them.
Other than that, mousetail is probably right. You might need to increase your physics rate to handle this, or use a physics library that helps address this, e.g. Box2D has the concept of "bullets":
BulletsGame simulation usually generates a sequence of images that are played at some frame rate. This is called discrete simulation. In discrete simulation, rigid bodies can move by a large amount in one time step. If a physics engine doesn't account for the large motion, you may see some objects incorrectly pass through each other. This effect is called tunneling.By default, Box2D uses continuous collision detection (CCD) to prevent dynamic bodies from tunneling through static bodies. This is done by sweeping shapes from their old position to their new positions. The engine looks for new collisions during the sweep and computes the time of impact (TOI) for these collisions. Bodies are moved to their first TOI and then halted for the remainder of the time step.Normally CCD is not used between dynamic bodies. This is done to keep performance reasonable. In some game scenarios you need dynamic bodies to use CCD. For example, you may want to shoot a high speed bullet at a stack of dynamic bricks. Without CCD, the bullet might tunnel through the bricks.Fast moving objects in Box2D can be labeled as bullets. Bullets will perform CCD with both static and dynamic bodies. You should decide what bodies should be bullets based on your game design. If you decide a body should be treated as a bullet, use the following setting.bodyDef.bullet = true;The bullet flag only affects dynamic bodies.Box2D performs continuous collision sequentially, so bullets may miss fast moving bodies.
I am already using box2d, but implemented a particle system on top of it and i am calculating the contact points based on the static fixtures (Chain shapes) myself, including the solving of the velocity constraints using an sequential impulse method - nearly the same method box2d uses, but without rotation dynamics (not needed for particles).
Maybe changing the solver to a CCD like system would help. I heard about speculative contacts, but had problem understanding the "Conservative Advancement" part.
It hangs for a while, maybe 10 frames and then it starts normally. If i increased my gravity to a normal earth-like level 9.81, then some line segment collisions are being missed.
Fix your timestep.
Your fundamental problem is that a variable-length frame time is causing your physics to behave differently. Your physics simulation should be deterministic (not affected by any randomness). It is currently being affected by the randomness of frame time. That's a bug.
You also generally need to cap your frame time (to avoid the spiral of death), have graphics interpolate between physics states (to avoid jittery animations), and tie almost all of your other game systems to the fixed timestep (to avoid all the other possible bugs regarding overly long or unexpectedly short frame times).
It looks like maybe you are using a fixed timestep. Double check that you're using the fixed dt in your game logic and not the variable one. If you only see this bug during a long frame, it's definitely a time step issue. If you see it all the time, your objects are moving too fast and you need to cap their speed, use continuous collision detection, or decrease your fixed timestep time.
I already use a fixed timestep update loop. But i was unsure if this is correctly implemented, therefore i posted just the code partition for the game loop.
Also i use linear interpolation for the rendering part and record the previous position for every entity as well.