AL Advanced Guide #3: Physics Explained: Broken Car - @Driver555Archive

追加: 2026-06-02

[00:00:06]Hello everyone, 555 here. In my previous advanced explain videos, I have discussed the checkpoint system and fake speed. Today I seek to share my thoughts on game physics. Specifically, I want to explain the difference between FPS and PF, touching upon determinism and mathematically dissecting why broken character works and the way it does work. Let us begin by establishing the absolute basics. FPS or frames per second refers to the frequency at which the visual graphics are updated. In as legends, we can observe that certain game logic is also tied to FPS. For instance, the timer, nitro activation, and nitro gain logic, inputs like steering and brake to name a few are all tied to FPS. On a side note, when nitro activation and nitro gain are tied to FPS, using nitro and the performance boost nitro grants is not tied to FPS.

[00:00:57]Therefore, technically on very high FPS, the nitro bar would decrease less smoothly than it increases. Therefore, it appears as though players with higher FPS can technically accomplish more precise inputs as their input is evaluated more often. While higher FPS allows for a smoother gaming experience, thankfully it doesn't meaningfully impact competitive potential, though.

[00:01:16]More important than FPS is the so-called PF or physics frequency. This is the frequency at which actual physic updates happens. This is also where forces applied to the car by input logic, for example, steering or braking will take effect. PF is not a setting players can modify because different PF values grant a significant competitive advantage. A higher PF will generally improve car handling while a low PF will generally improve float capabilities. This happens because bullet physics uses a step simulation system. Each new tick is based on the laps real time. If the PF decreases, the period increases. Between updates, there then lies more time leading to different results mathematically in the physics simulation. Many do not understand how FPS and PF relate to one another.

[00:02:03]Therefore, if devised a pseudo code example of how the system is very likely roughly implemented. When a new frame happens, an accumulator is incremented by the delta time of that frame. If the accumulator is positive, the engine will evaluate n physics steps. Each step will have a fixed duration of 1 divided by PF. After each step, the accumulator will be decreased by the duration of the physics step that has just happened. If the accumulator is negative, meaning the physics is ahead of the visuals, physics updates will terminate for that frame.

[00:02:34]Note that as we can also observe via the visual race timer, frame delta time is limited to 100 milliseconds or.1 seconds. This is done so after a leg spike, the car does not teleport multiple seconds ahead. However, this also means if you get a stutter and therefore a frame time greater than.1 seconds in multiplayer, you will irreversibly lose that time because your accumulator kept out at.1 second while the others continue to increase.

[00:02:59]Consider the implications of this system. Let us suppose PF is less than FPS. The accumulator will be incremented by a value roughly proportional to 1 divided by FPS. Given FPS is smaller than PF, 1 divided by FPS is strictly greater than 1 divided by PF. Suppose last frame a full physics tick was subtracted from the accumulator and now roughly has the value negative 1 divided by PF. If we add to that a positive but smaller value, we will still be in the negatives. Indeed, that means this frame will have no physics update at all. To smoon the visuals, the game now would interpolate object transformations visually displaying objects between the previous and current physics step as the current step would still represent the future. Remember that a negative accumulator indicates that we have subtracted more physics steps than actual time has been added to the accumulator. So therefore, we have done more physics logic than real time has passed. Let us also consider the opposite scenario. Let us suppose FPS is less than PF. Now 1 divided by FPS is strictly greater than 1 divided by PF.

[00:04:09]Therefore, adding this value of 1 divided by FPS will always bring us into the positives on the accumulator.

[00:04:15]Therefore, at least one, but likely multiple physics updates will happen per frame. Therefore, not every physic position is ever rendered. The car will have done things never seen by the player.

[00:04:28]Many believe higher FPS to give an unfair competitive advantage. But let us consider the system. Consider a player with higher FPS than another player.

[00:04:37]Yes, set player may be able to activate Nitro more often per second, seemingly giving him more precision. But in truth, the actual performance boost, the acceleration and top speed boost gained by Nitro will nevertheless be evaluated at physics frequency. Therefore, the outcome will be identical between them.

[00:04:54]You only begin getting a def facto disadvantage if your FPS are less than PF.

[00:05:01]Let me also throw in a little fun fact.

[00:05:04]When most people know PF to be 60 Hz by default, less people know that Gameloft enables lower PF values for less powerful devices, giving them a competitive advantage without any way to disable it. However, virtually nobody will know that specifically when entering RAMs, PF is actually increased from its base value. If your PF is usually 60 for a couple of frames, the game will increase that value to 120, slightly improving stability. It stands to reason that this is an effort to prevent bugs when driving up ramps. To summarize, why would Game of Theresa's approach? For one, the visuals are updated smoothly at your FPS, while next to no competitive advantage is granted by having more powerful hardware and more FPS. So, next time you get a lack and believe the physics change because of it, know you're hallucinating. It has no effect whatsoever on your PF or your physics.

[00:05:56]Understanding that FPS is basically decoupled from all important logic, many may point to the San Diego portal shortcuts, allowing players to drive through portals without being teleported when having very low frame rates.

[00:06:15]Portals, unlike other hitboxes that are handled with bullet physics, are most likely updated inside the per frame logic, not tied to PF. My best guess as to why would be developers not wanting to touch physics logics for scripting related things. This is in line with how they, for instance, treat nitrog separately from PF. As discussed earlier, for normal wall collisions, Gameloft uses continuous collision detection via bullet physics. Distinct collision detection on the other hand checks per tick if the rigid body intersects with a wall. At high velocities and with low PF and therefore large intervals, you may within the span of one single physics step already be halfway through the wall. Therefore, you would easily be able to clip through walls. Continuous collision detection works by casting array in the direction of motion ahead of your vehicle. It then stores where in the future and when the vehicle will impact the wall given its current trajectory. The game will know in advance when a collision will happen.

[00:07:20]Therefore, you cannot drive through walls at high velocities unless you have ridiculously big physics intervals which are not obtainable legitimately.

[00:07:29]When people do glitch through walls, it should always be because the collision hitbox is malformed. For example, it could have a small hole in it where part of the vehicle can clip through and behind or many walls are also only one directional walls, meaning collisions are only enforced one way. If part of the car is behind the wall, physics may not be evaluated as the game thinks the car is driving through them from behind.

[00:07:51]To make matters worse, when we lower our FPS, the lowest possible is 10 FPS for a.1 second interval. Remember we are kept in our frame intervals to at most 100 milliseconds. Then every frame will however still use the same PF value. So if we do.1 seconds divided by 1 divided by 60 Hz we get a factor of six. This means frame based collision detection will be less accurate by a factor of six since the delta distance between two frames is the amount of physics ticks times the distance traveled per tick in that one frame. And if we have more physics ticks per frame, then this number will naturally be bigger. This overwhelms the distinct collision detection used for portals based on FPS logic. And therefore, you can glitch through portals when you have very low FPS and a sufficiently big velocity. A fun experiment many players do is drive the same run whilst performing no inputs whatsoever. They will observe drastically different results, leading most to conclude the game is helplessly indeterministic. Determinism is the notion that under identical input an algorithm will provide identical output.

[00:08:59]I.e. if we play the same race with same input our laps will be identical.

[00:09:04]If this as we observed does not happen we must consider that the input of the algorithm was not identical. In the case of asphalt that variable is time specifically our systems clock. Every frame on a hardware will take slightly less or more time to be processed by the hardware. Therefore, the game will measure a slightly different elapse time between frames. Let me circle back to what I previously discussed. Since the physics updated at one divided by PF intervals, um, and PF is not a random value. PF is not subject to time differences. It is a constant 60. Um, the physics are technically immune to this. However, logic like nitro inputs, checkpoints, progress, timer, respawns, and many more are however at least in part governed by FPS or at least influenced by FPS. As previously discussed, per frame multiple or no physics takes may happen. However, if the FPS of our identical no input ls diverge ever so slightly, the synchronization relative to physics sticks will break. It will happen that on any given frame n one lap may have two the other only one physics tick.

[00:10:12]Between two subsequent physics tick no FPS tight logic will be evaluated and therefore the order of operations between the two laps will be fundamentally different causing different results.

[00:10:25]Also let's remember how I've earlier said that PF increases to 120 when going up drums. Well, this logic would by its very nature have to be something that happens outside of the physics logic and therefore it depends on FPS. But if our fixed time step for physics now relies on values evaluated by logic that is influenced by FPS, then this value also will be poisoned. Slight mathematical differences will quickly develop and these will quickly compound. Even the slightest of differences will snowball into completely incomparable results exponentially. Even a 0.1 kilometers/ hour speed loss is intolerable for it will over the course of a full run completely change the result by as much as seconds. Therefore, if frame time diverge by as little as a one microcond, the smallest unit the game clock likely uses, the outcome of two runs are incomparable.

[00:11:17]You may try to cut FPS, however, through normal means you will never get down to microcond precision. But even after that, even if you accomplish microscond precise frame intervals, the game is still nowhere usably deterministic. And this is because of the multi-threaded architecture. Think of a thread as a digital worker. Multiple workers handle multiple tasks at the same time. In a big game like Asphford Legends, dozens of threads may be used at once. However, the order in which one thread completes its work relative to the other workers is unpredictable. It will be different each time based on how your CPU cycles are distributed and which thread is given priority by the operating system.

[00:11:58]Experimentally, I figured out that input, be it controller or keyboard, is pulled or updated in a thread separate to the physics or frame logic. In other words, you may have your input updated multiple times or not even once per frame. If that thread lags behind for some reason, you very well, in other words, could have 120 fps but get less inputs per second than a guy with 90 fps. With regards to determinism, this means even if you accomplish microscond frame time precision, you would have to account for a random order in which your input is evaluated if your goal was to recreate an identical run.

[00:12:36]>> So to summarize, inherently there's no reason the game cannot be deterministic.

[00:12:41]Gameloft even follows good practice by separating physics via PF from FPS and updating it in discrete time intervals.

[00:12:49]However, given the multi-threaded architecture and the fluctuating FPS, unfortunately, As for Legends out of the box isn't deterministic.

[00:13:00]>> Now, let me touch upon arguably one of the most infamous Asphalt Legends bugs, broken car. When you wreck your car, detachable parts of your car will break as part of the wreck cinematic. However, on occasion, you can also keep your car in this state after wreck has concluded and drive around with these detachables deployed. To understand my leading theory, we will require all of the basic knowledge I've outlined up to this point. As people rightfully observe, broken car occurs more often the higher FPS are. At 60 FPS or below, it is virtually impossible. But what changes the probability SFPS increase?

[00:13:39]Let P physics stick be the probability that at XFPS any given frame has at least one physics update. Let P no physics stick be the opposite. At 60 FPS or below, one physics tick per frame is mathematically guaranteed as the delta time will always be big enough to compensate minus1 divided by PF as PF equals 60 Hz constant. Therefore forcing a positive accumulator, therefore forcing a physics tick every frame.

[00:14:07]However, the higher your FPS gets, the less the accumulator is incremented per tick. Therefore, P physics tick happening in any given frame asymtotically shrinks towards zero as FPS grows towards infinity. We could say the limit of FPS towards infinity of P physics tick of FPS is zero. At 120 FPS, only every other frame, for example, so a 50% chance has a physics update.

[00:14:32]Let us assume that activating the detachable parts is physics based logic and thereby ruled by the physics frequency. Two, let us assume respawn logic is not handled by PF but rather FPS-based. We can see this because portal teleportation respawns are also tied to FPS intervals. It simply stands to reason.

[00:14:53]In order to get broken car, you must then satisfy two conditions. One, your car must hit a zone where within one frame you both respawn and wreck. And two, within that frame, there must be zero physics ticks. I imagine it to go somewhat like this. Your car enters the wreck state, be this via collision calculations from the previous physics ticks or otherwise. This triggers flux to enter the wreck state and among them a flag to detach the breakable parts.

[00:15:24]Next, your car wreck logic should be called wrecking your car and deploying the detachables. However, since this frame has no physics tick, that logic never gets the chance to run in this frame. Instead, the respawn logic will now be handled since it is part of the FPS update that will run every frame.

[00:15:42]Respawn resets your car state and the breakables. That is why you respawn as an intact car usually. That is why if you respawn while your car is wrecked by flinging its corpse into a respawn zone, you respawn intact even if the wrecked state has exited early via the respawn.

[00:15:59]Respawn will read the car state to be in wreck, reset that state, and reset breakables. However, it will never reset the flag that cues the breakables to be detached in the next physics update.

[00:16:13]When the next physics tick happens, the breakables will be deployed given the cued flag is still set to active.

[00:16:20]However, now the car is not officially in the wrecked state. Therefore, the breakables are never reset. If you respawn, they remain. Why? Because the respawn sees the cars not in wrecked state and likely because of optimization skips any reset logic of the breakable parts. Only after you wreck again, your parts reset. Why? Because now your car is officially in wrecked state.

[00:16:41]Therefore, the next respawn now properly does the cleanup logic. That or similar to this is most likely why broken car physically occurs, how to replicate it, and why it appears so strongly correlated to your FPS.

[00:16:55]Now, we understand how broken car happens, but why should we at all care?

[00:16:59]There are several reasons for this. For one, it is fun to look at and fun to play around with. Secondly, it changes car weight and center of mass.

[00:17:07]Therefore, under some conditions, it can actually improve your car's drifting speed. The most interesting usage, though, is >> slingshoting.

[00:17:31]This is a bug that happens when driving a broken car into a respawn zone.

[00:17:35]Inexplicably, the car will gain tremendous velocity being slung in the direction of its respawn position, the last valid ground contact the car has had. Why this happens, I do not know. It could have to do with the breakables being independent physical objects that freak out once the car's main body that they are still attached to is being teleported. It could be a plethora of other things as well. Certain tricks exist to manipulate your trajectory.

[00:18:00]However, as this is a theory crafting video and I'm not the best qualified to explain them and with regards to brevity, I will not. Instead, let's look at another component of broken car.

[00:18:12]Specifically, what determines exactly which part of your car breaks?

[00:18:17]With breakables, there are three scenarios per part. A part can not break at all. A part can break but stay attached to the main body of the vehicle. or a part can break and then separate or detach entirely from the car's body. Only the last two scenarios are relevant for us because player cars, from my experience, always break on every part. Which parts they attached or fly away when you wreck appears to be entirely random. Too random to be a coincidence. I've looked deeper and devised an algorithm to mathematically predict in advance with certainty not just how many but exactly which individual parts will fly away or stay attached when a carrix.

[00:19:02]First, we must again touch upon the topic of determinism I've mentioned earlier. To decide which breakable part deploys, the game entirely relies on the MSVC C++ compiler's rant function. This function returns an integer between 0 and 32,767 inclusive.

[00:19:21]The soda random number generator is not tied to system clock. Instead, every result of grant is 100% mathematically predictable based on the previous outputs. The function can however be given a random seat at random starting point with srand giving it for example the current time as a randomizer.

[00:19:42]The game does not do this and if left uninitialized, it will default to a seat of one. Using the starting point, we can ourselves easily generate exactly the random numbers in order the game will produce in any given race. Better yet, recall me touching upon multi-threaded architecture earlier. The state of MSVC's run function is tied to thread local storage. This has two significant implications. One, the physics worker thread has its own version of run. This means other threads doing other stuff like random visual effects do not affect its rand progress. Since it is one thread, thereby inherently synchronous, the order of its operations is guaranteed deterministic. And since the rand algorithm is deterministic, its outputs are predictable. And two, every race, the game appears to spawn a new physics worker thread to handle that race. Therefore, every race, the run function is effectively receded to one for that threat, guaranteeing every race is predictable, not even requiring us to restart the game per race. Luckily, calls to run are very scarce on this thread. In fact, they appear to be none aside from the rack breakable logic as indicated by my predictions being accurate over the course of entire races.

[00:21:01]So, how does my prediction work? Well, every car has different amount of breakable parts. For example, I've isolated exactly seven breakable parts on Jesco absolute run will determine the state of every breakable part in order. Every vehicle has two thresholds. Let us call them T1 and T2. Per breakable part, the following will happen. One, if rand returns a value below that car's T1, the part will break. If run returns a value above that cast T1, the part will not break. And two, if and only if a part was ruled to break in step one, want will be called a second time on that part. If the value of the second want call is below T2, the part will detach, fly away, or separate. Otherwise, the part that is now broken will still stay attached to the car's main body.

[00:22:02]I have observed that for all drivable cars, every single part has a 100% chance to break. That means t1 is equal to 32,767.

[00:22:14]This value can never be exceeded by the run function and is therefore always going to lead to a broken part. T2 appears to be the same for all cars as well. However, T2 appears to only be 75% of the max value. Therefore, every part has a 75% chance of flying away from the vehicle. If we normalize these values into the interval 01 by dividing through 32,767, we can also interpret them as raw probabilities. Hereby P of T1 exceeded equals 100% whereas P of T2 exceeded under the condition T1 equals 75%.

[00:22:55]By shuffling the numbers around, you can calculate probabilities, however, never concrete predictions. Let's remember, however, that we know grant is a common open-source utility that everybody has access to. We can simply test by looking at the list of numbers run produces.

[00:23:12]Will the first number be small or equal to T1? If so, the part will break. If not, the part will not break. Will the second number then be greater than T2?

[00:23:23]If so, the part stays attached. If it is smaller, the part will fly away. Do this seven times and you've mapped out exactly what will happen to Jesco absolute the first time it wrecks. For absolute, I find the parts in the following order. The first one is the left door, then the right door, then the hood, then the front bumper, rear bumper, rocker panel left, and then the right rocker panel.

[00:23:53]Life isn't that simple, however. Your car is not the only object. Other cars, police cars, but most importantly, traffic cars also have breakable parts and they rely on the same logic.

[00:24:05]Therefore, if an AI tracks or if you destroy a traffic car, their breakable parts will also deploy. The bad news is for our car, our first threshold T1 is virtually never exceeded, meaning every single breakable part deploys 100% of the time. For JFY cars, this is not the case. They each only break about 50% of the time, meaning their T1 threshold would be normalized to 0.5.

[00:24:31]This is serious trouble for our predictions.

[00:24:36]In order to predict our Rex state, we rely on knowing how many run calls have occurred in this race before your car rex, thereby giving us an index into the list of random numbers the function run spits out. And we can easily calculate the result.

[00:24:53]If we wreck, since every part will 100% break, T1 threshold being the maximum value, we are guaranteed that the amount of ramped calls we advance per that one rack is exactly two times the amount of breakables the car has. Since the T2 check will always happen, therefore, two run calls per detachable part will always be called.

[00:25:18]This is no longer the case with traffic cars as traffic cars have a 50% chance for T1 to be surpassed. And if T1 is surpassed, the second call will never happen since the part never broke. And therefore, it will never be evaluated whether or not the part will detach or stay attached.

[00:25:40]Therefore, when we knock down any traffic cars, we must also calculate in our prediction the amount of breakable parts that traffic car has and then consider whether or not the run number corresponding to the index of the T1 check of that traffic car will exceed the T1 threshold. And if it does, the second call will be skipped. Therefore, that breakable part will now only account for one rand call skip. And we must account for this when indexing into the random numbers for further predictions.

[00:26:15]For the purpose of making slingshot runs, I needed a way to one figure out given n amounts of varying traffic cars I knock down. If I then get broken car, exactly which type of broken car am I guaranteed to get as different types perform differently with regards to slingshot potential. And two, I needed a way to figure out given I want a certain broken car config exactly in which order I must knock down traffic cars of which types to skip exactly sufficient run calls such that whenever I drag and get my broken car, I get the broken car configuration that I want. These considerations become impossibly complicated to figure out by hand. And therefore I've written a simple calculator algorithm that instantly calculates these two questions for me.

[00:27:04]The algorithm will essentially try out all possible combinations and provide me with the simplest way to accomplish the configuration I want by trying out different combinations of traffic knockdowns.

[00:27:18]I then can limit the pool of traffic cars since different traffic cars have different amounts of breakables that are available and therefore I must consider on the track which types of traffic cars are available and also in which order they are available whether or not those traffic cars are available before the point at which I get the broken car.

[00:27:56]Many combinations of broken car are so unlikely that they realistically never happen in a real race. After all, suppose absolute seven breakable parts.

[00:28:06]There is a total of 2 to the 7 equals 128 possible combinations of breakables.

[00:28:12]Now let us consider that T2 equals 75%.

[00:28:16]Therefore, every part has only a 25% chance of staying attached. Therefore, if I want a car state that has many breakables attached and few breakables detached, my chances are one in hundreds. Let us also consider that there is no traffic car with less than four breakable parts. So skipping one or two individual RNG calls is very difficult.

[00:28:41]I now will show you two examples that let us verify my algorithm accurately predicts the results of broken car type and that shows that I'm not just yapping nonsense.

[00:28:50]For this I will take a look at Jessco absolute. I have calculated two outcomes. First of all, the outcome of hitting a bus and then hitting a truck.

[00:29:01]And the predicted bit mask for brake is all once. And the predicted detach mask is also all once. Meaning all parts should detach the car. And then I have also calculated the result for the case that I wreck without touching any trophy cars. And the resulting bit mask should be for brake. All old parts break as expected. And the detach mask should be 0x55 or every second part detaches.

[00:30:04]data.

[00:30:21]Hey Heat. Hey, heat. Hey, heat.

[00:30:54]If you are still here, you're one of the few legends interested in understanding asphalt legends on a theoretical level.

[00:31:01]And that is admirable and I hope you've learned something new from this video. I believe this to not be useless lodge. It has helped me more than anything else understand the game better recently and it will continue to enable more and more impressive segmented runs akin to my Pudong 57.6 lab I did recently. Uh leave a comment if I've made any mistakes in my coverage along the way. While I am very confident in my findings, I am always open for evidence that contradicts my theory. And thank you for watching.

[00:31:49]Heat. Hey. Hey. Hey.