Forgot to mention: The game speed is not slowed down alongside the timer. We looked at other runs from the “world record holder” mentioned in this video and some of them are actually faster than humanly possible. It is possible that some of the game physics are running faster than intended, giving him an even bigger advantage, but we are not 100% sure about this one and there are no reliable ways to test it. This is another thing for to investigate Correction At 4:28: That's 56 clean runs for 30fps
You've put more time and effort into figuring this out than playground games has ever done with anything in the game. Well done. Actually explains alot.
Love that you're using my tool for real forza science. Lmk if there's anything else you might find helpful. For example, maybe the recorded log files can be converted to something like csv files so you can load them in a spreadsheet to better analyze the plots
Interesting to have the physics refresh rate tied to your FPS. Major sim racing titles figured out ages ago that it was a bad idea to do so. Now they have physics updates detween 300 and 900 Hz for increased fidelity.
@@OCinneide well, I stand by what I said XD Joking aside after looking a bit deeper into it... No wonder they have so many issues with cheating and exploits. Damn that game needs an overhaul.
@@Heldermaior yeah, I would have thought this year would have been the one for an overhaul with the new cars (it’s 2022 cars) and all the popularity from an exciting season and drive to survive. But it looks more like they rushed it through and we’ll see what they do next year.
Rivals mode's biggest sin is the inability to sort times by cars driven. That way you could pick whatever you want and tally your time with others who used the same car. Otherwise it's 1-2 META cars per track or GTFO. Apart from well known issues plaguing this mode, looks like there's even more, quite significant to anyone that cares or cared at this point...
One of the coolest things I noticed about Project cars 2 was they sorted lap times by model. Forza has had Rivals for over 10 years, and it is one of the biggest selling features of the games (particularly in Motorsport), and realized it’s crazy that the Forza team hasn’t seemed to even try to implement this
At one point I know Forza (Motorsport, at least) ran a fixed 180hz physics refresh rate, and also most major racing sim titles run fixed physics refresh rates as well. I suspect this is caused here because at some point, Forza switched to tying the physics refresh to your framerate - or may do this in specifically Horizon titles. It still doesn’t explain the game timer issues, but it would at least explain the physics issues between 30 and 60 fps locks.
@ryan It's easier to run at an acceptable rate vs an independent physics engine. In the 108hz physics example, super slow hardware that can't keep a consistent 180hz tick rate will cause the game to speed up and slow down. But, in an fps based physics system, the slowdowns are compensated for by having more time between physics tick, by having a frame drop.
You know that's some GTA V level programming there. That game has exactly same problem in online mode. Framerate gives more speed, suspension works weirdly and it also gives you speed boost which we call kerb boosting. Basically exploiting physics to gain more speed by clipping methods like changing rims. Anyone interested can check broughy's fact check videos.
Im glad to see this about the physics and the timing. I honestly felt I was going insane and the only one thinking the physics were off. I’d enter a turn with all the same variables and it was almost always different everytime. Like my car will grip the earth like a champ, slide a little, or act like it was on ice. Frustrating to say the least.
Good god been looking for a similar word to my own. One race you’ll feel totally confident around corners and next you might slide through one at a lower speed than the run just before
If you are trying to play any high demanding game on a console competitively and not for fun that IS the definition of insane. Expecting consistency at 30fps is just madness. On console your way to go is adjust the difficulty, turn on the driving aids under difficulty and enjoy in a leaned back position on the couch instead of try harding with a controller and 30fps. Reading stuff like this is indeed frustrating to say the least.
@@kontoname Imagine defending shitty coding, telling people how to play and what to expect and turning the whole conversation into console vs pc masterrace in one comment. Piss off mate!
"you might have tried dozens of tuning setups with little to no improvements" (shows ugrundy's tunes) this is kinda genius way to explain why there's no impovements lol
In "Beetle Adventure Racing" Physics also change with different frame rates. PAL N64 runs in 50 fps where american version N64 runs in 60 fps. The console calculates the cars position every frame. Means that if the car experiences any changes in (the track) directions, it calculates whether it gets closer to the ground or further away. Resulting in a change of the cars direction, or not. For example if your going up a ramp, your car wants go into the ground. The cars velocity and direction is always the result of the calculation from the last frame and the players input ofc. So going up a ramp means that the cars calculated direction and the direction of the street do not match, resulting in compression of the springs and a change in direction and velocitiy for the next frame. Long story short. In 60 fps it does that progress more smoothly than in the 50 fps version, resulting in the cars physics and behaviour beeing more volatile. It is more likely that strange things happen with lower fps. Maybe thats whats going on here
Yeah, in CoD the more framerate you have the better your hit detection is. I've actually proven it to myself since CoD ghost since I have a potato PC then.
@@voron1911 Isn't that just because the precision sucks, and the network scripts overall work slower, so the server recieve information from yor enemy much faster than it does from you GTA ONLINE has muuuuuch worse network problems, when you have a potato PC
@@narrativeless404 I think framerate do matters. I tested this by playing both locked to 60 fps and 144 fps. I'm pretty sure that on 144 fps, I get more consistent kill with certain amount of hitmarker. If I played on 60 fps that same amount would not always kill the enemies. Sure my test is not a scientific one. It could also be a placebo effect of playing on higher framerate.
My conclusion from the suspension graphs; the physics updates are fully tied to the framerate. Reducing the framerate reduces the amount of updates the suspension model recieves. The lack of updates means that the suspension will behave less consistently due to important details of the track not being reflected in it. At the same time, while higher framerates seem to help with consistency, I'm sure there is a point in the hundreds of frames per second, where the suspension will update so quickly that it may begin to behave erratically. And because the update rate improves consistency, the erratic behavior may also be consistent.
It is the physics tick speed which has numerous different names. Almost every modern game with any sort of collision has separate tick speeds, it's usually locked to a lower number like 40-60fps which has very little deviation in consistency and they use something called DeltaTime which is an approximation of the time between two frames to do t mathematics which is everything from the timer to the rate of force dispersion in suspension. However the larger the difference tick consistency the more deviation. Im not sure exactly why but I suspect Forza's default tick rate (for menu logic and what not) is somewhat tied into the physics system so unstable normal tickrate has an impact on the physics tickrate. I beleive it might have something to do with performance in that regard or it could be a legacy issue with their engine being built for 30fps on older consoles. That's why many games still have a fps cap on consoles so that the gameplay is consistent especially in physics based games. The non determinism you spoke about is true, it can be caused by another computer science term called "floating point errors" where a number is too large or small for the computers 32bit floats to encapsule so numbers get trimmed. If the framerate is higher or lower it can change what values are in certain equations and sometimes they can get chopped off, only causes minor mis-calculations in equations but when the equations go from like millimetres surface are to newton meters of force created by downforce you could be a whole int value out, have that happen a bunch of times and you get some silly physics or silly timers. en.wikipedia.org/wiki/Delta_timing en.wikipedia.org/wiki/Floating-point_error_mitigation en.wikipedia.org/wiki/Speedrunning
Having worked with lots of physics simulation programming I think i could provide some insight into possible causes. Things like suspension, tire friction modelling, aerodynamics simulation are bound to be error prone when handled incorrectly. Time interval between the frames of simulation can change the outcome. In the case of the suspension - for example slower simulation rate may cause springs to get more compressed under changes of load on the car (like seen in the video with the cliiping on the loop) because there is more time between the cause (compression of the spring) and effect (spring force and damping acting on the car). Same can happen with tire friction but the time precision errors are usually more pronounced because the response in non-linear. You can search for tire friction curves if you want to see how they look. This can cause a tire to spin further before the forces are applied, therefore making it possible to spin faster than it should and getting less friction as a result. If the simulation results are dependent on the simulation framerate, an unstable simulation framerate will make them more random/non deterministic. Possible solutions to these problems are: running the simulation at a (edit: stable) rate independent of the graphics fps (commonly used, not idea why it's not used in fh5) and numerical integration or running critical parts of the simulation multiple times per frame internally to minimize the errors. It would be interesting to see you test the friction with different fps. Maybe some powerful cars with a lot with wheelspin? No idea about the possible cause of the timer thing, but someone definitely did a shitty job with that.
@@edgesplitmusic Which doesn't specifically negate the point of the video, if 30fps is giving different results than 60fps then clearly there are still not enough physics samples.
They did have framerate tied to the physics, but in specific sets of framerates. They did try to solve the issue but they didn't realise that computer can't do math.
Lots of games have mechanics that are based on your FPS. Personally I think the best part of this game is how your stats and movement are all local, meaning you can speed-hack, fly-hack, get cars and money, and also even save-swap with accounts all local to your computer, kind of like Grand Theft Auto 5. (I think save-swapping was patched not too long ago, but it was a thing.)
I remember something similar happened to me in The Crew 1: Back then I had pretty old and slow hardware which limited my fps. This lead to the problem that I couldn't drive with/against my friends in multiplayer because there was some sort of correlation betweem FPS and the speed/distance a car drove. I could drive top speed with my LaFerrari and my friends with high fps could just drive past me with some default offroad car lol...
Dude until I upgraded my computer I was stuck at the ironclad dash for so fucking long.. Speedran the rest of the game with no fails cause I was grinding parts in freeroam for months 😂
I used to play The Crew 1 A LOT with my friend who had a cheap laptop, he had idk like 30fps while I ran the game at steady 60fps. I was legit twice as fast as him even on slower car. it was hilarious.
@@EDXVA its funny to read that other players experienced the same stuff after YEARS lmao. Have to say, that this basically destroyed the game experience for me... Back then I really liked the game, it was the closest thing to TDU2 for me since Forza Horizon wasn't a possibility for PC gamers yet
Not a competitive game but Brick Rigs has the same issue in multiplayer, when you have a low fps your vehicle moves at a third of the speed of everyone else
FH5 was the last game I expected where dropping graphic settings gave you an edge. well I guess it's time to drop them ultra/extreme settings and make the frame counter go brr
@@JoelHernandez-tz3vk I'm running on ultra because the game otherwise goes CPU bound and causes stutters. Don't know why it's happening but it drives me crazy.
Yeah I've dropped extreme shadows, environmental geometry, shaders (huge performance savings) and cut out real time RT (my GTX 1070 can't push for a locked 60FPS with it anyway). I think I also cut reflection quality down a lot, drawing those dynamic cube maps is brutal on the GPU.
Pay2win physics has been a problem not only in forza but in entire gaming history. Like for example in cod4 league, everyone is hitting 200+ fps and the rule no 300+ fps is enforced on some matches In gta fivem racing communities, moderators and admin has server grade gaming pc running 400+ fps to assert their ego on us and going even a second faster on 40 seconds straight with the same car/build
I don't want to pretend like I'm an expert on the topic, but I feel like these types of issues are easily ignored when developing mainly for the console market because framerates are capped... trackmania has largely been developed for PC only so they took this into account.
I remember how the OG Doom engine kept the same gameplay speed on any CPU while the later Quake 1 engine would spaz out on faster systems unless you either pulled some console wizardry or pushed your monitor to higher resolutions
another idea for testing this: make an autohotkey script (or similar recorded inputs) with set steering and throttle/brake inputs, then let that run on 2 different machines. When overlaying the two videos, it should show one of them with synchronous inputs, but different positions on the course, leading to inputs that are desychronized from the track leading to a wipeout.
I have an educated guess on why cars are faster at higher frame rates. It's jerk, or the change in acceleration. The jerk for each car will be a fixed value (lets say J=1 for now). That means that the acceleration for each car will be a a function that approaches the controller value depending on the jerk. In a perfect world, the velocity at each moment would represent the area under the curve, but since the physics engine measured the jerk and acceleration each frame, it looks like those Riemann sums you did in highschool. The more rectangles you add, the closer the area approaches the true value, so if you double the sampling rate you will get a closer answer to the true velocity of your car. One way to fix this is for the PC to do all its physics calculations every other frame to match 30 fps.
60 fps causes less loop clipping because the physics engine has double the amount of frames to calculate physics iterations which can only happen based on the amount of frames rendered in the simulation. Slow the game engine down with uncapped framerate and you'll notice almost zero loop clipping at all because the game has all the time it needs to calculate the suspension travel. This is true in a significant amount of games, but I've never personally witnessed it in a racing game, especially one with a competitive scene. Another example of this is can be seen in BeamNG Drive, where the physics calculations on the crashes get significantly more 'approximate' the faster gamespeed and lower the FPS. Slow the gamespeed down significantly, which then increases the FPS simultaneously, and you'll have far more accurate crash physics calculations per frame.
This can effect a lot of games and is down to time delta not being accurate enough. In multiplayer the *tick* for physics takes place on the server and so it should be more consistent in terms of timing. In singleplayer the "tick" is on the players CPU. If there are 60 ticks in 1 second and the time between each tick is some number, e.g. 0.000230 but the CPU depending on architecture and also lots of other factors can reduce the accuracy of this number (in other words, the computer isn't fast/good enough to know the smallest amount of times possible in reality, i.e. picoseconds) After the 5 ticks are added up discrepancies can appear, for example: Tick 1. 0ms Tick 2. 0.0020000032ms Tick 2. 0.0010000032ms Tick 2. 0.0030000032ms Tick 2. 0.020000032ms If this were handled by a a computer, it may not have this degree of accuracy so lets round it up. Tick 1. 0ms Tick 2. 0.00200000ms Tick 2. 0.00100000ms Tick 2. 0.00300000ms Tick 2. 0.0200000ms As we can see now, we missed all those 0.000000032ms at the end of the number... And that really matters. All of this adds up over many ticks. A good way to think about Ticks is FPS, its not always the case, but you could say for every frame, there is one tick. 30 FPS means much less numbers, also rounded innacurately, therefore producing worse results 60 FPS means trying to do 60 ticks inside 1 second, rather than 30. Well if we imagine if the CPU can handle 60 ticks, it probably has less of a time delta between each ticks. Because its a better CPU. 30 FPS means trying to do 30 ticks inside 1 second, which means if the CPU is running fast, or the tick is running faster than 1 per frame, the maths get's even more out of whack. For example your game may be 30 fps, but your tick is 60 ticks per second. Now the maths to calculate the time between frames is much more different, we're now factoring the fact 2 ticks occur per frame, and so we once again destroy the original "1 tick per frame" ideal, and end up with some bodge maths. As game devs we use a simple math trick to resolve the issue, which when we're talking on the "seconds" time scale is fine. But anything sub 1 second, we all accept we lose the accuracy. Here is the math: 1 Second is equal to Desired FPS/TicksPerFrame - Time since last frame Example: Desired FPS / Ticks per frame - Time since last trick (or frame) 60 / 60 - 0.0002ms
I would bet $1,000 this type of stuff is not limited to Forza 5. This is common among many games. Hence why consoles should not be forced to play against PCs.
I have something to add about the suspension clipping in the loop. Two of my friends playing at uncapped FPS always wondered how I get less clipping when playing in the Hot Wheels world. I play at capped 72 fps. When my friends also tried capping their fps to 72 they stated getting significantly less clipping than before. So it seems like at high enough fps you start getting disadvantages again.
well fuck this series then, I only care about playing at 120fps or higher, 72 fps looks so bad on an 144hz monitor. If I want to play a low FPS game I'll choose one that at least maintains a stable physics like Ridge Racer R4 on playstation emulator
@@KvltKommando If you are think that being when can if do that of is where wasn't can be without it. Do when bring is of it can you up mad is of there? Or can bring when be of that is? When they are there is the in of doing with them they are that ones. So if are they that one is you and without then? When do so can angered if it was there when it will didn't can then how does it went to that before there is on timing inside without them?
in some cases the physics problem is "solved" by using fixed physics timesteps that may result in physics that runs at much higher or lower tick rates than the framerate, either asynchronously (runs independent of rendering) or synchronously (runs X physics steps on each frame) in order to achieve more accurate and consistent physics, but even then floating point arithmetic may sometimes result in a buildup of small inaccuracies or changes that can make an otherwise "similar enough" run have a different outcome
The physics difference is because the physics engine works on a 2x multiple of your framerate, so I believe what you are seeing is half the data points hence the smoother graph at 30fps.
This needs to die. Fast. I don't care on what part of the sliding scale of racing realism your game lands on either. I loathe non-deterministic physics.
@@JoelHernandez-tz3vk well it was originally done so that the physics where a high fidelity on console and could remain highly reactive even at lower framerates. It's a good system for a closed ecosystem like a console, but obviously has issues when the ecosystem is opened up. Hopefully the new physics engine addresses this in the next Motorsport.
*Slams into wall* - Me: skill issue that I have too. How to fix? In short, learn racing lines, braking points, brake release points, or how long and how hard you should brake at a certain point in time before a corner, and max speed for clearing corners without dealing with wall
That loop scenario is why i tend to run Rally Suspension on almost every car, sure i'm not getting most handling possible but avoiding bottoming out is perferable imo
I'd guess it's a rounding issue 60fps = 1 frame every 16.6(recurring)ms, 30 = 33.3(recurring)ms, 120 = 8.3(recurring)ms with the fps rate on console locked to maintain 60fps then it's always rounded up. the others get rounded down. Testing at performance mode vs quality mode on console might well highlight this. IDK what the server polling rate is but if it's at the millisecond level then 60fps would become 17ms, 30fps would be 33ms. 2 frames at 60fps would then work out at 34ms, a 1ms discrepancy 30 times every second. 60 seconds = 60,000ms, 60,000 / 17 = 3,529.411764705882 frames created per minute. 60,000 / 33 = 1,818.181818181818 frame created per minute. 30fps is exactly half of 60 fps but if you divide 3,529.411764705882 by 2 you get 1,764.705882352941. Here's where it gets interesting... divide 1,818.181818181818 by 1,764.705882352941 and you get 1.03030303030303 multiply this by 100 and you get 103.030303030303 a 3% difference between 30fps and 60fps over just 60 seconds. It'd be almost impossible for 2 different players to do EXACTLY the same lap, if you COULD you'd probably see exactly a 3% time discrepancy. Roughly 1.77 seconds behind or 1.81s ahead depending on viewing at 60 or 30fps. In the loop section? Again it'd be nigh on impossible to rewind to exactly the same ms every single time you COULD be upto 0.5ms either side and be totally unaware of it, add in the 17 and 33ms frame time and going frame by frame the accuracy error is copounded, therefore you'd see the changes shown in the telemetry traces, some would bottom out others wouldn't...
I can confirm this… the physics does really change with hardware…some things do behave a lot differently When I play on my pc, 12th Gen i3 and 3060ti, I am always racing as perfect as I want….but when I switch to my laptop which is like 4+ years old (7th Gen i5 and GTX 1050 4GB), so it runs on 1080p 30fps, it has a significant impact on my driving…and it becomes irritating as my driving becomes bad and turning and braking become mess… Whereas on pc I can easily play 60/90/120 fps (I play with 1080p60 EXTREME) and its just perfect…no shenanigans…..and there’s slightly more things you can get away with And no I’m not a bad driver…its like above above average….
It's not just forza with this problem, other games have it to, but in different ways. One being Roblox where in some, or most games, the physics act better with higher frames. A game or two to test this on would be Dawn Of Aurora and Phantom Forces. For DoA, look how vehicles drive with higher vs lower frames and how they react to the terrain. For Phantom Forces, look how the gun recoils. It's less noticeable as FPS increases, but there is a difference. Usually when recoil starts acting wild is at lower frames below about 20-30.
It's probably because the donkeys who coded the game programmed the clock tick on frame and not time. So the more frame you have, the more tick, therefore the slower your timer is.
Gravity is often tied to fps in first-person shooters. I think a simple way to make it make sense is that a faster device doesn't have to skip any calculations to meet a performance target. Hence why with more fps the suspension values have time to go through more position checks, returning more values, smoothing out the transitions.
I have noticed the frame affects something very early. when playing 10 skill points blueprint, such as 139 710 733, the lower frame makes you run faster. Using X seseto fe, 41 fps → about 25.4s，83 fps → about26.3s. And sometimes, the speed just ignores obstacles. You have the skill points but just like going through the obstacles, so it will be under 23s. But when you go faster, you will get less exp. using 165fps, about 3733 3961 4000 exp per round, 30 fps would be 32xx exp. It seems like because one frame cannot handle more than 2 times collisions. For example, if the speed is enough to hit 61 obstacles in 60s, but you only have 60fps, there will be at least one frame that has 2 or more than 2 collisions. It may only cause one slowdown. So lower fps let you ignore more slowdown by collisions. And I think I played afk more than all players in fh5, my id : nmcleo, I even go afk for online racing. And now I am on the top 25 of the exp board. I spent a lot of time on tuning for afk, so I have tried what is the best fps for afk. Higher fps have advantages in most maps. But the game is more likely to crash with the unlocked frame, so I am using 83fps. With NV gpu + over 5ghz cpu, using nvidia profile inspector, you can run fh5 over 200 fps. Just like how some people play pubg.
I’ve seen you show up afk in Playground Games and it’s slightly annoying. The game already makes the teams mismatched or have an uneven amount of players and then to have a player show up and not even do anything makes it real fun.
@@jbjoseph01 I am sorry about that. For accolades and sometimes for seasonal, I need to go playground. As you said, the game already makes the teams uneven. I totally do not enjoy playing this game at all. Since I got all playground accolades, except seasonal, I have never been into playground games. Now I am only afk at s2 road. Cuz this makes 4 million online exp and about 120 levels per 24 hours, which is the fastest afk way to get online exp that I found.
Well this should be the game engine problem, some older games relies heavily on stable 60fps where if you go over or under that, the game can behave differently or didn't trigger the correct action, i think that's because they tie the physics with frames rather than time. It is surprising actually to find that this problem still exist in modern games
This isn't a game engine problem. its a math and real life problem. Computers run in real time. And you can't store infinitely small numbers with limited bits because math, and real life.There exists no perfect solution. Either high framerates are inconsistent, low frame rates are inconsistent, or the game runs in real time.
I would say the physics vary based on the cpu load but that's is something that hasn't been a problem for years where if you manage to boot up some really antique games on modern hardware, the physics would be overclocked because it was designed around a much slower processor.
If I had to guess, it seems like it’s in-part a problem with interpolation, and the frequency of physics updates. It seems from the video like collision + physics updates are only applied when a frame is rendered. If you had a mod to prevent the rendering of the game without triggering some sort of lag compensation system (if one exists), I have a feeling the cars may start “driving” through walls. Video games these days are meant to work at varying framerates in a roughly consistent manner. However, it can be difficult to handle collision updates in these non-deterministic situations - almost as if the collision detection somehow relies on the frame that was previously rendered to determine if a collision happened rather than calculating the physical interpolation based on a frame or two ahead. As such, it makes sense in the loop example that the car clips into the floor more at lower frame rates because the game has to “catch up” more slightly more to visually reflect the velocity applied from the previously-rendered frame. As easy as it can be to put our conspiracy hats on, as a developer of other games and systems I believe this “pay2win” aspect that appears here is very much not an intentional design element, but rather just an unfortunate side-effect of the way physics updates are handled. I think that one of the few ways to level the playing field more in ‘competitive’ environment would be to limit physics to a time-based system. Ex - when the in-game timer passes certain thresholds, one or more physics updates are applied, but not so much that it causes the game to lag on older hardware. This would, however, cause a VERY SMALL visual desync in the moment to moment gameplay that can cause things to feel _extremely_ different on newer hardware. It’s a biiig balancing act. If ya wanna truly fix things, fix the real-world economy lol
I read a while back about this issue in GTA Online, frames and physics were tied closely, somewhat rigging races to your hardware. Surprisingly, this was fixed with Expanded and Enhanced.
The reason why framerate interfere with physics is because the simulation rate is frame bound. An object moves distance pr time unit , then you calculate 'whats up' and fix errors according to the physics (intersections ) .. if objects are intersected , you push them back and continue with the simulation. This is the simple version of physics calculations. The more appropriate is to use Euclid's which do calculations BEFORE moving the objects. And therefore doesn't need to fix intersections. .. but Euclid is harder math and therefore not always used. When you only have 30fps, objects can potentially move further into each other and require bigger fixes. Thereby potentially make you go faster or slower. Having 100fps on the other hand creates a finer gradient of physics with smaller fixes. Which again can improve or slower your driving speed.
This is a universal issue with render engines. Faster number crunching equals faster results. Combine better hardware with less computational load, _everything_ runs faster (clock speeds take on a double meaning here shortly). I forget the title where this became very evident, but well over a decade now, it was observed in an online competitive looter shooter with very large maps and no fast travel that looking down while running had a dramatic increase on how fast your character could run. Less information was being thrown into the GPU for rendering, increasing not only the overall FPS return, but also the speed at which it is processed. So the test was two characters geared up identically would run 10 miles across the map, one looking only at the ground, the other normal. The character who looked only at the ground received an FPS bump and finished Minutes before the other character.
Well in games you can set time in two ways: Update - It's measure time with Frames Per Second, if you have two computers one with 60fps and second with 30fps you can notice that this same game runs on one computer faster and the other slower Update with deltatime - deltatime is the time that has passed to complete the last frame in for example unity in default is 0.33 in this case if you have one computer with 60fps and the other with 30fps this same game will run almost equally Normal update is best use is for inputs or function that be must check every frame Update with deltatime is used to physics, timers and other things that must be mesaured equally on every device Unfortunately there is not other way to measure Time in computer devices
Shit like this, and how brutally stupid a lot of the meta builds are is what made me lose interest in FH5 after putting quite a bit of time into it. FH tries to be this weird middle ground in terms of realism and arcade hilariousness and that just breaks it IMO. I've had a lot of fun TBF, and really enjoyed building and tuning cars to a high level and taking on online races. This just gets shit on by stupid meta builds, glitches and half assed development though. It really is a bummer when one has built up their favorite car, spent ages tuning it to be a winner in its class, but then has to resign their mindset to "winning the non-meta class" in online races. Drifting was fun, I got involved in some online communities that did great, realistic driving and it was the most fun I'd had in FH5. It's a real letdown how half assed the competitive component of drifting is. If a dozen cheap mobile games can implement more realistic drift scoring (zones, clipping points and proximity), why cant PG? It's kind of interest specific I know, but really highlights how much of a lazy, child market cash grab FH has become. Mobile games do most of it's elements better. Just this morning I uninstalled FH5 after playing it since launch and change my racing game library to two polar opposites that don't try to split the genre and come out half assed. I'm happily playing Unbound for fun and really enjoying the style and story, and getting into Assetto drifting now that people have figured out controller support while I save for a wheel.
This happens because fixed timestep (and thus physics computation) is locked to the target framerate, but not framerate-dependent. It's not the timer running slower, but rather the timer being updated more frequently without as much interpolation between samples. In other words, your timer is a higher resolution at a higher framerate, which is a more accurate representation of your lap time. Anyone running on inferior hardware is actually sandbagging themselves with interpolation errors. In multiplayer, everyone's clock is synchronized to the least frequent timestep possible to ensure that any potential low-spec users can actually join and play. This means all multiplayer matches are fair in regards to clock speed and your hardware won't give you an advantage in that regard. Coincidentally, it also means handling characteristics and lap times in multiplayer are a bit less accurate in general.
It's a very common bug in videogame engines. Basically it is a rounding error. The numbers in your PC re represented by a finite number of bits, usually 32. When you divide something unevenly, on paper you often generate an imfinite decimal nimber. Think of Pi for example - it never ends. But your PC can't do that - it can only calculate numbers up to a certain measure of precision, after which it will discard everything else. That precision is usually more than enough for any error to be absolutely negligable and unnoticeable. But sometimes, like here, you may notice it. Imagine if a timer is calculated every frame. If you run at 60 FPS, you add 1/60th of a second every frame. If you are at 120 fps - 1/120th. But those fractions only look neat if they are represented as a fraction. If you show them as a decimal, the story is different. 1/60 = 0.01666666(6) 1/120 = 0.0083333(3) They stretch on infinitely to the right. Now let's cut them! The PC is a bit smarter than what I'm gonna show here, and much more precise, but the gist of the problem is the same. I will just drop everything after 5th decimal place,and then round the remainder: 0.01666666... = 0.0167 0.00833333... = 0.0083 And... Uh-oh, we were forced to round up on the first number, but we are rounding down on the second. So at 60 fps we are adding slightly more to the timer than necessary, and on 120 fps we are adding slightly less. I should note that depending on calculations and exact fps you can see the reverse as well, so it is never a clearcut "more fps = better timer". Unfortunately, I should note that the only way to get rid of this error is to run your timer in a frame-locked thread or to compare it with system time or something. And even then you will get discrepancies on 2 different machines. This is impossible to fix completely simply due to how computer maths works.
IIRC, someone posted a couple of months ago on r/F1Game a video on how taking the same corner with a big sausage kerb on 30 FPS had almost no effect, whereas at over 60 FPS he was almost flying. That's a game made by Codemasters ( now part of EA but that's another story ) so this makes it even more strange that 2 completely different racing games have this behaviour
At this point, after 610 hours of playtime on FH5, the game is just awful, might as well just play Asetto Corsa. >proceeds to play FH5 after writing this comment anyway
On my first watch here, the bit about 30fps vs 60fps and its effect on lap times seems to rest on some flimsy logic. If you just got done running 100 laps on the same track in the same car, you’ve gotten more and more familiar with both the track and how to maneuver around it with that particular setup. It’s not at all unreasonable to imagine that you’re genuinely just doing better and are able to meet the time much more quickly and consistently with all that practice - especially if you’re now receiving visual updates twice as often as on your first 100 attempts. Those are both pretty huge advantages.
With the difference in physics between 30 and 60fps it makes me wonder how something like 24, 75, 90 and 120+ will fair for those on lower end hardware and those with high refresh rate monitors.
This is the worst car game I’ve played in years. You don’t feel a connection to your vehicles, cars are basically just handed to you, the map is huge and empty.
This is true for all games. In sim racing titles like Raceroom, AM2, I racing, etc., you can have a screen that only does 60fps but the game does 90 or 120 fps with a frame viewer. With each fps all of the inputs and physics is updated and calculated. So, 120 fps is going to be more fluid and accurate in it's handling even though the screen is updating at 60 fps. There was a mod that allowed one of the Transformers games to run at 60fps. The catch was the physics were a little off because the engine was built around 30 updates a second.
This situation rememberem me the things with 3d fallout engines and why an internal clock is so important Basically, in 3d fallout the physics engine does the calculation on movement, time and so on based on your frame rate, given the game was made to run @30fps anything bigger than this will cause problems, we see faster movement, objects behaving weirdly and many clippings happening To solve this problem many developers started implementing an internal clock, it limits the ammounts of inputs the game engine recieves so you don't get weird bugs while maintaining a high fps count, see any multiplayer game for instance, the vast majority of servers only register stuff @30fps so to maintain low performance cost and a somewhat smooth physics simulation I believe the same things is happening to FH5, either the engine lack an internal clock that limits the game inputs to a set ammount or the game does feature an internal clock but the same is set to capture >=60 inputs per second, resulting in weird behavior from a lack of inputs
This is because the physics are not independent of the frame rate. In many games this causes the physics to break if the frame rate goes too high or too low. Physics calculations are done on each frame so if there is too much frame time (between frames) the physics aren't calculated in real time or vice versa causes issues. If they are dont independently this issue is resolved
Does this advantage extend to 120, 144, and even 300 frames per second or is the internal clock rate(unsure of exact terminology) limited to 60 per second?
this reminds me of the quirk in Doom Eternal where extremely high FPS affected the physics of the meathook and players with that hardware learned to fling themselves across the map
Tons of games have this issue. Amongst many genres. There's even some games the benefit from intentionally lowering your frames per second to 1-2 on the opposite end of this videos spectrum.
I think this is because the delta time is a float of 32 bits and when it multiplies to get the values of the timer and physics it just loses a little bit of precision every time
game physics tied to framerate has been an issue from time immemorial. many games tie the physics to the framerate, and you can abuse that by limiting or unlimiting the framerate. I would bet a lot of the world record runs are done at 15fps because it means the physics are updating less and thus, not as effective. this is why other online racing sims don't tie their physics models to the framerate of the client, because that would leave opportunities for a huge client advantage on one direction or the other depending on how they react.
Other gams have some similar bugs, for example, the hit horror game Poppy Playtime. Running at 60 fps or above gives you normal physics. The lower below 60 you get, the slower the physics runs. The physics aren't intended to be tied with the fps, but they are. At 15 fps the first jump in the game is almost impossible.
You will always encounter these accuracies unless you use deterministic code, I don't know any game that uses a deterministic physics system, apart from games that have very basic movement that doesn't require a physics engine, such as among us (probably). The reason why it doesn't happen in online races is likely because the multiplayer system is server biased (i don't remember the actual word) which means that what you see in your screen is just a local simulation, your inputs are sent to the server which then runs its own simulation and decides the actual results. If there is a difference in your local simulation and the server simulation, the game will gently apply the corrections to your local sim. If the difference between what the server calculated and what your game calculated is too large, that is when the game might teleport you to the server's calculated position. Besides that, even if the game ignores a small amount of difference, the timer will be based on the server's simulation. So it doesn't matter if you're running on 10 fps or 100 in your local sim, what would matter is the server's performance. Even that won't matter much in a race since everyone will face the same affects caused by the server's performance
The best part is that for us people on Xbox Series (and formerly on Series), most of us probably gave up on Forza Horizon 5 after we were forced to put a 230+ GB game on the internal SSD when it works perfectly fine on a HDD. So they actively hurt people who are poor, and people who become poor.
Why? It’s a good game. You’re not gonna play this game over a 0.2 second inconvenience? You pretend as if the developers could have foreseen this teeny tiny problem in over millions of code.
i'm guessing the source of the problem is floating point imprecision. the bigger your framerate is, the smaller your deltaTime is going to be (the amount of time between each frame, used in math calculations ran every frame), so as the accuracy of the variable diminishes, the bigger the skew is going to be. this can cause problems like slower/faster physics depending on framerate. the only solution would be using a fixed tic system a la older games
I recently doing a real time rendering job for an earthquake simulation in UE. The only way to get a precise calculation is by NOT going real time. Dividing and calculating 1 frame 20 times will get you more accurate physics. But it will slow down your rendering by 20 times. that's what basically what's substeps does. So if you're using a slow PC, the calculation of 1 frame could cut short, and it goes "fuck it, just move to the next frame" and you get a very bad incomplete calculation. This could lead to understeering a lot. In other kinds of games, say fps for example, where you sometimes see boxes or ragdoll goes crazy, is because it had 1 bad frame, and it intersects with the floor or other rigid bodies, and the next frame goes "that's not supposed to be in here" and tries to push it back out, which leads to the boxes launches at high speed.
Interesting video. I have an xbox and a pretty good pc (framerate is normally in 100s). I run lots of rivals mainly on pc, but sometimes on xbox. I've set pb laps on both. I can't say I've noticed this bug myself and I usually race my own ghost. It seems like a massive oversight for a racing game if it is correct.
At a blind guess I'd say they are using delta timing. This is where the games mechanics, in this instance a physics engine, are run once per frame with a time_step interval, called a "delta" time to process how much movement happens during that physics cycle. It's the fastest and most efficient way to squeeze more fps out of the same hardware. However, in instances such as the suspension wobble you showed, the delta time for a frame is too course to simulate the debounce on the suspension. Serious sims tend to circumvent this by running the physics at a fixed rate that is decoupled from the frame rate, but as you can imagine this means running the physics much faster in order to for the frame updates to represent a smooth interval of time, otherwise alternative frames would represent very different deltas and the framerate would feel slower than it really is due to the choppyness. Therefore highly compound numbers work well for physics rates, (120/240/360 etc) but such high frequencies can be difficult to achieve on entry level hardware. Thus, Forza - being a mass market game - is aiming to support as much hardware as possible, and I suspect that is why they have opted for this variable delta timed physics approach.
I don't think there is really a complete solution for this problem, because a better pc will just go through the code in the loops faster. I had the same problem (but far worse) in a small racing game I had to programm for university and the professor said there isn't really a solution to fully eliminate that problem. On my slow Laptop it would take about double the amount of time to finish the course compared to a gaming pc.
Your professor was likely not that well versed in programming. There are always work arounds in the virtual world it's why really terrible HW by today's standards was already able to give us consistent results.
GTA online suffers from the same issues. The higher your framerate, the faster some cars go. The Pfister 811 was one of the fastest cars due to the framerate bug, beating rocket cars. Add this with curb boosting (the suspension compresses and decompresses creating more speed) and you're not losing a straight line race.
I've seen something of the same nature happen to some graphical adventure puzzles. The game update the timer every some amount of prosessor cycles instead of real time, while online timers depend on the servers' cycles.
I can almost guarantee what is happening here is that the devs created the timer by calling it in what we call the update loop without multiplying it by delta time. The update loop runs the program connected to it every frame and basically what multiplying by delta time does is make sure it is measures the time between frames in actual seconds so it is no longer calculated depending on frames. We will never really know unless we get our hands on the programs inside, but that is the most likely reason for this problem. Most likely a bug could be intentional for other unknown reasons.
Really interesting ! I immediatly think of "simulation" : Physics in a car game is always simulated. While in the real world, the compression of the spring is continuous, in a simulation, it is discrete. In mathematics, something continuous is when all values of times (in this example) are available. Something discrete is only "step-by-step". For example, y=x^2 is a continuous function, but Fibonacci sequence is discrete (1, 1, 2, 3, 5 etc, but nothing between 3 and 5). For a 30fps rate, values are calculated every 0.0333.. seconds and for 60fps, it's every 0.0166... seconds. It seems a detail, but for a simulation it highly important. Due to the interaction between all values (with derivatives, primitives etc), calculations for continuous in live are quite impossible, because there far too massive. So physicists and developers use simplified discrete calculations. Far more simple, far faster, but more or less approximative. So approximate that for the same starting value, the t=0.003 value at 30 fps and at 60 fps will not longer be exactly the same, simply because at 60 fps there was an intermediate value. On the contrary, for a rendering scene in 3d, you can use longer and more precise calculations. That's why rendering in a 3d software takes so long.
The weird thing is the game physics should be running at an independent tick rate from the framerate, so why there's a weird correlation is interesting.
They do. But there are always going to be small inconsistencies. You see this in every piece of software on earth. The more complex the physics simulation, the more inconsistences stack per second. Its a physical issue. Computers run in real time and you can't change that. Delta times can't be infinitely small because you have a limited number of bits to represent any number. (and floating point inaccuracy). Its not interesting its a fundamental aspect of computers.
Forgot to mention: The game speed is not slowed down alongside the timer. We looked at other runs from the “world record holder” mentioned in this video and some of them are actually faster than humanly possible. It is possible that some of the game physics are running faster than intended, giving him an even bigger advantage, but we are not 100% sure about this one and there are no reliable ways to test it. This is another thing for to investigate
Correction At 4:28: That's 56 clean runs for 30fps
You've put more time and effort into figuring this out than playground games has ever done with anything in the game.
Well done. Actually explains alot.
Love that you're using my tool for real forza science. Lmk if there's anything else you might find helpful. For example, maybe the recorded log files can be converted to something like csv files so you can load them in a spreadsheet to better analyze the plots
@naekstasy that would definitely help but after this discovery doing further tests on this game is pointless
@@seP4 yeah Sadge
Did anyone test if more than 60 fps can cause a bigger difference?
"The players, with less tools, doing developer's jobs for free." That hit hard
Not only that, the developers regard you as knowing nothing peasants
@@teertaa the devs can't even drive properly when demo-ing the game lmao
*Bethesda has entered chat*
Deep
**Test Drive Unlimited community has entered the chat**
Interesting to have the physics refresh rate tied to your FPS. Major sim racing titles figured out ages ago that it was a bad idea to do so. Now they have physics updates detween 300 and 900 Hz for increased fidelity.
Well F122 ESports found out that FPS is tied to physics.
@@OCinneide well, I stand by what I said XD
Joking aside after looking a bit deeper into it... No wonder they have so many issues with cheating and exploits. Damn that game needs an overhaul.
@@Heldermaior yeah, I would have thought this year would have been the one for an overhaul with the new cars (it’s 2022 cars) and all the popularity from an exciting season and drive to survive. But it looks more like they rushed it through and we’ll see what they do next year.
@@OCinneide overhauling costs money. Better to slap a new coat of paint and call it a day
Roblox does the same thing
"he has a better gamong chair" is now officially working in fh5.
Has been for a while my g
Gamong
the fps boost from the rgb led's is real
@@tyreksimmons4167 you ain't kidding. Gaming chair doesn't even hold up anymore. Get 6 tenths just from my RGB 5G overclocked headset
Xd
Rivals mode's biggest sin is the inability to sort times by cars driven. That way you could pick whatever you want and tally your time with others who used the same car. Otherwise it's 1-2 META cars per track or GTFO. Apart from well known issues plaguing this mode, looks like there's even more, quite significant to anyone that cares or cared at this point...
That is something I would love to see. Would add a whole new reason to play rivals.
Man, imagine fighting to be the actual ghost of Akina, or the Gran Caldera in that case.
One of the coolest things I noticed about Project cars 2 was they sorted lap times by model. Forza has had Rivals for over 10 years, and it is one of the biggest selling features of the games (particularly in Motorsport), and realized it’s crazy that the Forza team hasn’t seemed to even try to implement this
would be pointless anyways, too many cheaters on leaderboard
@@Mgoblagulkablong Leaderboards are still useful you just have to scroll down until you see more realistic times.
At one point I know Forza (Motorsport, at least) ran a fixed 180hz physics refresh rate, and also most major racing sim titles run fixed physics refresh rates as well. I suspect this is caused here because at some point, Forza switched to tying the physics refresh to your framerate - or may do this in specifically Horizon titles. It still doesn’t explain the game timer issues, but it would at least explain the physics issues between 30 and 60 fps locks.
Why would they make that change? Seems like a massive downgrade
@ryan It's easier to run at an acceptable rate vs an independent physics engine. In the 108hz physics example, super slow hardware that can't keep a consistent 180hz tick rate will cause the game to speed up and slow down. But, in an fps based physics system, the slowdowns are compensated for by having more time between physics tick, by having a frame drop.
You know that's some GTA V level programming there. That game has exactly same problem in online mode. Framerate gives more speed, suspension works weirdly and it also gives you speed boost which we call kerb boosting.
Basically exploiting physics to gain more speed by clipping methods like changing rims.
Anyone interested can check broughy's fact check videos.
180hz must have been forza motorsport 1. i remember they proudly announced 360hz for fm3 and then i think 960hz for fm5.
@@GraveUypo
Yeah but I'm fairly certain that was always a huge lie from DG.
Im glad to see this about the physics and the timing. I honestly felt I was going insane and the only one thinking the physics were off. I’d enter a turn with all the same variables and it was almost always different everytime. Like my car will grip the earth like a champ, slide a little, or act like it was on ice. Frustrating to say the least.
Good god been looking for a similar word to my own. One race you’ll feel totally confident around corners and next you might slide through one at a lower speed than the run just before
If you are trying to play any high demanding game on a console competitively and not for fun that IS the definition of insane. Expecting consistency at 30fps is just madness.
On console your way to go is adjust the difficulty, turn on the driving aids under difficulty and enjoy in a leaned back position on the couch instead of try harding with a controller and 30fps.
Reading stuff like this is indeed frustrating to say the least.
@@kontoname Imagine defending shitty coding, telling people how to play and what to expect and turning the whole conversation into console vs pc masterrace in one comment.
Piss off mate!
"you might have tried dozens of tuning setups with little to no improvements"
(shows ugrundy's tunes)
this is kinda genius way to explain why there's no impovements lol
True
In "Beetle Adventure Racing" Physics also change with different frame rates. PAL N64 runs in 50 fps where american version N64 runs in 60 fps. The console calculates the cars position every frame. Means that if the car experiences any changes in (the track) directions, it calculates whether it gets closer to the ground or further away. Resulting in a change of the cars direction, or not. For example if your going up a ramp, your car wants go into the ground. The cars velocity and direction is always the result of the calculation from the last frame and the players input ofc. So going up a ramp means that the cars calculated direction and the direction of the street do not match, resulting in compression of the springs and a change in direction and velocitiy for the next frame.
Long story short. In 60 fps it does that progress more smoothly than in the 50 fps version, resulting in the cars physics and behaviour beeing more volatile. It is more likely that strange things happen with lower fps. Maybe thats whats going on here
People won't believe this is happening in CoD, but you literally just proved it's going on in Forza. Lol
Cod bots are too zombified to think critically
Yeah, in CoD the more framerate you have the better your hit detection is. I've actually proven it to myself since CoD ghost since I have a potato PC then.
@@voron1911 Isn't that just because the precision sucks, and the network scripts overall work slower, so the server recieve information from yor enemy much faster than it does from you
GTA ONLINE has muuuuuch worse network problems, when you have a potato PC
Just unable cross platform….?
@@narrativeless404 I think framerate do matters. I tested this by playing both locked to 60 fps and 144 fps. I'm pretty sure that on 144 fps, I get more consistent kill with certain amount of hitmarker. If I played on 60 fps that same amount would not always kill the enemies. Sure my test is not a scientific one. It could also be a placebo effect of playing on higher framerate.
My conclusion from the suspension graphs; the physics updates are fully tied to the framerate. Reducing the framerate reduces the amount of updates the suspension model recieves. The lack of updates means that the suspension will behave less consistently due to important details of the track not being reflected in it. At the same time, while higher framerates seem to help with consistency, I'm sure there is a point in the hundreds of frames per second, where the suspension will update so quickly that it may begin to behave erratically. And because the update rate improves consistency, the erratic behavior may also be consistent.
It is the physics tick speed which has numerous different names. Almost every modern game with any sort of collision has separate tick speeds, it's usually locked to a lower number like 40-60fps which has very little deviation in consistency and they use something called DeltaTime which is an approximation of the time between two frames to do t mathematics which is everything from the timer to the rate of force dispersion in suspension. However the larger the difference tick consistency the more deviation. Im not sure exactly why but I suspect Forza's default tick rate (for menu logic and what not) is somewhat tied into the physics system so unstable normal tickrate has an impact on the physics tickrate. I beleive it might have something to do with performance in that regard or it could be a legacy issue with their engine being built for 30fps on older consoles.
That's why many games still have a fps cap on consoles so that the gameplay is consistent especially in physics based games.
The non determinism you spoke about is true, it can be caused by another computer science term called "floating point errors" where a number is too large or small for the computers 32bit floats to encapsule so numbers get trimmed. If the framerate is higher or lower it can change what values are in certain equations and sometimes they can get chopped off, only causes minor mis-calculations in equations but when the equations go from like millimetres surface are to newton meters of force created by downforce you could be a whole int value out, have that happen a bunch of times and you get some silly physics or silly timers.
en.wikipedia.org/wiki/Delta_timing
en.wikipedia.org/wiki/Floating-point_error_mitigation
en.wikipedia.org/wiki/Speedrunning
Having worked with lots of physics simulation programming I think i could provide some insight into possible causes. Things like suspension, tire friction modelling, aerodynamics simulation are bound to be error prone when handled incorrectly. Time interval between the frames of simulation can change the outcome.
In the case of the suspension - for example slower simulation rate may cause springs to get more compressed under changes of load on the car (like seen in the video with the cliiping on the loop) because there is more time between the cause (compression of the spring) and effect (spring force and damping acting on the car).
Same can happen with tire friction but the time precision errors are usually more pronounced because the response in non-linear. You can search for tire friction curves if you want to see how they look. This can cause a tire to spin further before the forces are applied, therefore making it possible to spin faster than it should and getting less friction as a result.
If the simulation results are dependent on the simulation framerate, an unstable simulation framerate will make them more random/non deterministic.
Possible solutions to these problems are: running the simulation at a (edit: stable) rate independent of the graphics fps (commonly used, not idea why it's not used in fh5) and numerical integration or running critical parts of the simulation multiple times per frame internally to minimize the errors.
It would be interesting to see you test the friction with different fps. Maybe some powerful cars with a lot with wheelspin?
No idea about the possible cause of the timer thing, but someone definitely did a shitty job with that.
Run the benchmark and you'll see the simulation FPS is not tied to game FPS.
@@budthecyborg4575 I checked it and you are correct, my mistake.
@@edgesplitmusic Which doesn't specifically negate the point of the video, if 30fps is giving different results than 60fps then clearly there are still not enough physics samples.
@@budthecyborg4575 maybe using rewind is the problem.
They did have framerate tied to the physics, but in specific sets of framerates. They did try to solve the issue but they didn't realise that computer can't do math.
Lots of games have mechanics that are based on your FPS. Personally I think the best part of this game is how your stats and movement are all local, meaning you can speed-hack, fly-hack, get cars and money, and also even save-swap with accounts all local to your computer, kind of like Grand Theft Auto 5. (I think save-swapping was patched not too long ago, but it was a thing.)
I remember something similar happened to me in The Crew 1:
Back then I had pretty old and slow hardware which limited my fps. This lead to the problem that I couldn't drive with/against my friends in multiplayer because there was some sort of correlation betweem FPS and the speed/distance a car drove.
I could drive top speed with my LaFerrari and my friends with high fps could just drive past me with some default offroad car lol...
Dude until I upgraded my computer I was stuck at the ironclad dash for so fucking long.. Speedran the rest of the game with no fails cause I was grinding parts in freeroam for months 😂
I used to play The Crew 1 A LOT with my friend who had a cheap laptop, he had idk like 30fps while I ran the game at steady 60fps. I was legit twice as fast as him even on slower car. it was hilarious.
@@EDXVA its funny to read that other players experienced the same stuff after YEARS lmao.
Have to say, that this basically destroyed the game experience for me... Back then I really liked the game, it was the closest thing to TDU2 for me since Forza Horizon wasn't a possibility for PC gamers yet
Not a competitive game but Brick Rigs has the same issue in multiplayer, when you have a low fps your vehicle moves at a third of the speed of everyone else
DUDE
I had the exact same issue, when I used to drive on a potato laptop and I used to struggle so much in multiplayer
4:35 44+66 is not 100 runs
FH5 was the last game I expected where dropping graphic settings gave you an edge. well I guess it's time to drop them ultra/extreme settings and make the frame counter go brr
I always default to until I hit a hard CPU bottleneck.
@@JoelHernandez-tz3vk I'm running on ultra because the game otherwise goes CPU bound and causes stutters. Don't know why it's happening but it drives me crazy.
@@Sphynx93rkn wihout knowing more context, sounds like a RAM issue rather than CPU issue.
Yeah I've dropped extreme shadows, environmental geometry, shaders (huge performance savings) and cut out real time RT (my GTX 1070 can't push for a locked 60FPS with it anyway). I think I also cut reflection quality down a lot, drawing those dynamic cube maps is brutal on the GPU.
@@VariantAEC RT only applies to forzavista doesn't it? what fps did you end up at after changing all those settings and what were u at before hand?
new forza game is locked to 60fps online most likely due to this problem lol
Pay2win physics has been a problem not only in forza but in entire gaming history.
Like for example in cod4 league, everyone is hitting 200+ fps and the rule no 300+ fps is enforced on some matches
In gta fivem racing communities, moderators and admin has server grade gaming pc running 400+ fps to assert their ego on us and going even a second faster on 40 seconds straight with the same car/build
thought we would we way past this in modern games. trackmania had this figured out decades ago
Server grade means shit for gaming. Maybe you simply mean "the fastest there is"
I just realized nadeo were the only racing dev concerned about this framerate issues
@@teertaa and yet they broke ice.
thank you nando. very cool.
I don't want to pretend like I'm an expert on the topic, but I feel like these types of issues are easily ignored when developing mainly for the console market because framerates are capped... trackmania has largely been developed for PC only so they took this into account.
Friendly reminder that this game got the Steam Award for "best art direction" when Psychonauts 2 was an option.
Reminds me of these good old DOS games that run their timers by the CPU fequency and therefore spazzed out on faster systems
Leading to the Turbo button which actually slowed down your system to run them in a sane speed XD
I remember how the OG Doom engine kept the same gameplay speed on any CPU while the later Quake 1 engine would spaz out on faster systems unless you either pulled some console wizardry or pushed your monitor to higher resolutions
Lol,good.
@@dudejo IIRC DOS Doom was limited to 35fps
Tons of games have this issue. Anything on Unreal Engine 1 for example.
another idea for testing this: make an autohotkey script (or similar recorded inputs) with set steering and throttle/brake inputs, then let that run on 2 different machines. When overlaying the two videos, it should show one of them with synchronous inputs, but different positions on the course, leading to inputs that are desychronized from the track leading to a wipeout.
I have an educated guess on why cars are faster at higher frame rates. It's jerk, or the change in acceleration. The jerk for each car will be a fixed value (lets say J=1 for now). That means that the acceleration for each car will be a a function that approaches the controller value depending on the jerk. In a perfect world, the velocity at each moment would represent the area under the curve, but since the physics engine measured the jerk and acceleration each frame, it looks like those Riemann sums you did in highschool. The more rectangles you add, the closer the area approaches the true value, so if you double the sampling rate you will get a closer answer to the true velocity of your car.
One way to fix this is for the PC to do all its physics calculations every other frame to match 30 fps.
60 fps causes less loop clipping because the physics engine has double the amount of frames to calculate physics iterations which can only happen based on the amount of frames rendered in the simulation. Slow the game engine down with uncapped framerate and you'll notice almost zero loop clipping at all because the game has all the time it needs to calculate the suspension travel. This is true in a significant amount of games, but I've never personally witnessed it in a racing game, especially one with a competitive scene.
Another example of this is can be seen in BeamNG Drive, where the physics calculations on the crashes get significantly more 'approximate' the faster gamespeed and lower the FPS. Slow the gamespeed down significantly, which then increases the FPS simultaneously, and you'll have far more accurate crash physics calculations per frame.
4:29 44 + 66 = 100!
💀
This can effect a lot of games and is down to time delta not being accurate enough. In multiplayer the *tick* for physics takes place on the server and so it should be more consistent in terms of timing. In singleplayer the "tick" is on the players CPU.
If there are 60 ticks in 1 second and the time between each tick is some number, e.g. 0.000230 but the CPU depending on architecture and also lots of other factors can reduce the accuracy of this number (in other words, the computer isn't fast/good enough to know the smallest amount of times possible in reality, i.e. picoseconds)
After the 5 ticks are added up discrepancies can appear, for example:
Tick 1. 0ms
Tick 2. 0.0020000032ms
Tick 2. 0.0010000032ms
Tick 2. 0.0030000032ms
Tick 2. 0.020000032ms
If this were handled by a a computer, it may not have this degree of accuracy so lets round it up.
Tick 1. 0ms
Tick 2. 0.00200000ms
Tick 2. 0.00100000ms
Tick 2. 0.00300000ms
Tick 2. 0.0200000ms
As we can see now, we missed all those 0.000000032ms at the end of the number... And that really matters. All of this adds up over many ticks.
A good way to think about Ticks is FPS, its not always the case, but you could say for every frame, there is one tick.
30 FPS means much less numbers, also rounded innacurately, therefore producing worse results
60 FPS means trying to do 60 ticks inside 1 second, rather than 30. Well if we imagine if the CPU can handle 60 ticks, it probably has less of a time delta between each ticks. Because its a better CPU.
30 FPS means trying to do 30 ticks inside 1 second, which means if the CPU is running fast, or the tick is running faster than 1 per frame, the maths get's even more out of whack.
For example your game may be 30 fps, but your tick is 60 ticks per second. Now the maths to calculate the time between frames is much more different, we're now factoring the fact 2 ticks occur per frame, and so we once again destroy the original "1 tick per frame" ideal, and end up with some bodge maths.
As game devs we use a simple math trick to resolve the issue, which when we're talking on the "seconds" time scale is fine. But anything sub 1 second, we all accept we lose the accuracy.
Here is the math:
1 Second is equal to Desired FPS/TicksPerFrame - Time since last frame
Example:
Desired FPS / Ticks per frame - Time since last trick (or frame)
60 / 60 - 0.0002ms
Incase you weren't mad enough already at the game, here's some more crap to work you up.
You do such incredible work man, respect
I would bet $1,000 this type of stuff is not limited to Forza 5. This is common among many games. Hence why consoles should not be forced to play against PCs.
@@spartanx169x Bro, console peasants need us. Otherwise, FH4 would be a ghost town.
@@spartanx169x sounds like a cope
@@SageBladeG to be fair most of you guys are cheaters anyway 😂
@@iamlilbll ngl cheaters are gay. That’s why i play at 120 fps
you have to love games where physics and whatnot are still tied framerates
I have something to add about the suspension clipping in the loop. Two of my friends playing at uncapped FPS always wondered how I get less clipping when playing in the Hot Wheels world. I play at capped 72 fps. When my friends also tried capping their fps to 72 they stated getting significantly less clipping than before. So it seems like at high enough fps you start getting disadvantages again.
well fuck this series then, I only care about playing at 120fps or higher, 72 fps looks so bad on an 144hz monitor. If I want to play a low FPS game I'll choose one that at least maintains a stable physics like Ridge Racer R4 on playstation emulator
@@KvltKommando If you are think that being when can if do that of is where wasn't can be without it. Do when bring is of it can you up mad is of there? Or can bring when be of that is?
When they are there is the in of doing with them they are that ones. So if are they that one is you and without then? When do so can angered if it was there when it will didn't can then how does it went to that before there is on timing inside without them?
in some cases the physics problem is "solved" by using fixed physics timesteps that may result in physics that runs at much higher or lower tick rates than the framerate, either asynchronously (runs independent of rendering) or synchronously (runs X physics steps on each frame) in order to achieve more accurate and consistent physics, but even then floating point arithmetic may sometimes result in a buildup of small inaccuracies or changes that can make an otherwise "similar enough" run have a different outcome
The physics difference is because the physics engine works on a 2x multiple of your framerate, so I believe what you are seeing is half the data points hence the smoother graph at 30fps.
This needs to die. Fast. I don't care on what part of the sliding scale of racing realism your game lands on either.
I loathe non-deterministic physics.
@@JoelHernandez-tz3vk well it was originally done so that the physics where a high fidelity on console and could remain highly reactive even at lower framerates. It's a good system for a closed ecosystem like a console, but obviously has issues when the ecosystem is opened up. Hopefully the new physics engine addresses this in the next Motorsport.
@@JoelHernandez-tz3vk Deterministic physics are boring
Unless you are a Trackmania speedrunner
@@narrativeless404 Tell that to Sonic Robo Blast 2 Kart.
@@JoelHernandez-tz3vk That's a specific type of racing games as well
*Slams into wall* - Me: skill issue that I have too.
How to fix?
In short, learn racing lines, braking points, brake release points, or how long and how hard you should brake at a certain point in time before a corner, and max speed for clearing corners without dealing with wall
Remember when racing games had clock brands as sponsors?
This is the reason they used to
That loop scenario is why i tend to run Rally Suspension on almost every car, sure i'm not getting most handling possible but avoiding bottoming out is perferable imo
3:24 or maybe after going 100 laps you finally got to know the track and started getting better times.
Yeah wtf was his thought process on that...
I’ve always told myself that I swear I’m not playing the same game as everyone else. Turns out I was on to something.
I'd guess it's a rounding issue 60fps = 1 frame every 16.6(recurring)ms, 30 = 33.3(recurring)ms, 120 = 8.3(recurring)ms with the fps rate on console locked to maintain 60fps then it's always rounded up. the others get rounded down. Testing at performance mode vs quality mode on console might well highlight this.
IDK what the server polling rate is but if it's at the millisecond level then 60fps would become 17ms, 30fps would be 33ms. 2 frames at 60fps would then work out at 34ms, a 1ms discrepancy 30 times every second.
60 seconds = 60,000ms, 60,000 / 17 = 3,529.411764705882 frames created per minute. 60,000 / 33 = 1,818.181818181818 frame created per minute.
30fps is exactly half of 60 fps but if you divide 3,529.411764705882 by 2 you get 1,764.705882352941.
Here's where it gets interesting... divide 1,818.181818181818 by 1,764.705882352941 and you get 1.03030303030303 multiply this by 100 and you get 103.030303030303 a 3% difference between 30fps and 60fps over just 60 seconds.
It'd be almost impossible for 2 different players to do EXACTLY the same lap, if you COULD you'd probably see exactly a 3% time discrepancy. Roughly 1.77 seconds behind or 1.81s ahead depending on viewing at 60 or 30fps.
In the loop section? Again it'd be nigh on impossible to rewind to exactly the same ms every single time you COULD be upto 0.5ms either side and be totally unaware of it, add in the 17 and 33ms frame time and going frame by frame the accuracy error is copounded, therefore you'd see the changes shown in the telemetry traces, some would bottom out others wouldn't...
I can confirm this… the physics does really change with hardware…some things do behave a lot differently
When I play on my pc, 12th Gen i3 and 3060ti, I am always racing as perfect as I want….but when I switch to my laptop which is like 4+ years old (7th Gen i5 and GTX 1050 4GB), so it runs on 1080p 30fps, it has a significant impact on my driving…and it becomes irritating as my driving becomes bad and turning and braking become mess…
Whereas on pc I can easily play 60/90/120 fps (I play with 1080p60 EXTREME) and its just perfect…no shenanigans…..and there’s slightly more things you can get away with
And no I’m not a bad driver…its like above above average….
I can still get near a locked 60 on my laptop's GPU at 1080p with many settings set above medium and high. 7th gen i7/GTX 1070(8GB)/16GB
It's not just forza with this problem, other games have it to, but in different ways. One being Roblox where in some, or most games, the physics act better with higher frames. A game or two to test this on would be Dawn Of Aurora and Phantom Forces. For DoA, look how vehicles drive with higher vs lower frames and how they react to the terrain. For Phantom Forces, look how the gun recoils. It's less noticeable as FPS increases, but there is a difference. Usually when recoil starts acting wild is at lower frames below about 20-30.
It's probably because the donkeys who coded the game programmed the clock tick on frame and not time. So the more frame you have, the more tick, therefore the slower your timer is.
Your study of this situation in the game is very important!
Gravity is often tied to fps in first-person shooters. I think a simple way to make it make sense is that a faster device doesn't have to skip any calculations to meet a performance target. Hence why with more fps the suspension values have time to go through more position checks, returning more values, smoothing out the transitions.
I have noticed the frame affects something very early. when playing 10 skill points blueprint, such as 139 710 733, the lower frame makes you run faster. Using X seseto fe, 41 fps → about 25.4s，83 fps → about26.3s. And sometimes, the speed just ignores obstacles. You have the skill points but just like going through the obstacles, so it will be under 23s. But when you go faster, you will get less exp. using 165fps, about 3733 3961 4000 exp per round, 30 fps would be 32xx exp.
It seems like because one frame cannot handle more than 2 times collisions. For example, if the speed is enough to hit 61 obstacles in 60s, but you only have 60fps, there will be at least one frame that has 2 or more than 2 collisions. It may only cause one slowdown. So lower fps let you ignore more slowdown by collisions.
And I think I played afk more than all players in fh5, my id : nmcleo, I even go afk for online racing. And now I am on the top 25 of the exp board. I spent a lot of time on tuning for afk, so I have tried what is the best fps for afk. Higher fps have advantages in most maps. But the game is more likely to crash with the unlocked frame, so I am using 83fps.
With NV gpu + over 5ghz cpu, using nvidia profile inspector, you can run fh5 over 200 fps. Just like how some people play pubg.
I’ve seen you show up afk in Playground Games and it’s slightly annoying. The game already makes the teams mismatched or have an uneven amount of players and then to have a player show up and not even do anything makes it real fun.
@@jbjoseph01 I am sorry about that. For accolades and sometimes for seasonal, I need to go playground. As you said, the game already makes the teams uneven. I totally do not enjoy playing this game at all. Since I got all playground accolades, except seasonal, I have never been into playground games. Now I am only afk at s2 road. Cuz this makes 4 million online exp and about 120 levels per 24 hours, which is the fastest afk way to get online exp that I found.
Well this should be the game engine problem, some older games relies heavily on stable 60fps where if you go over or under that, the game can behave differently or didn't trigger the correct action, i think that's because they tie the physics with frames rather than time. It is surprising actually to find that this problem still exist in modern games
This isn't a game engine problem. its a math and real life problem. Computers run in real time. And you can't store infinitely small numbers with limited bits because math, and real life.There exists no perfect solution. Either high framerates are inconsistent, low frame rates are inconsistent, or the game runs in real time.
I would say the physics vary based on the cpu load but that's is something that hasn't been a problem for years where if you manage to boot up some really antique games on modern hardware, the physics would be overclocked because it was designed around a much slower processor.
If I had to guess, it seems like it’s in-part a problem with interpolation, and the frequency of physics updates. It seems from the video like collision + physics updates are only applied when a frame is rendered. If you had a mod to prevent the rendering of the game without triggering some sort of lag compensation system (if one exists), I have a feeling the cars may start “driving” through walls.
Video games these days are meant to work at varying framerates in a roughly consistent manner. However, it can be difficult to handle collision updates in these non-deterministic situations - almost as if the collision detection somehow relies on the frame that was previously rendered to determine if a collision happened rather than calculating the physical interpolation based on a frame or two ahead. As such, it makes sense in the loop example that the car clips into the floor more at lower frame rates because the game has to “catch up” more slightly more to visually reflect the velocity applied from the previously-rendered frame.
As easy as it can be to put our conspiracy hats on, as a developer of other games and systems I believe this “pay2win” aspect that appears here is very much not an intentional design element, but rather just an unfortunate side-effect of the way physics updates are handled.
I think that one of the few ways to level the playing field more in ‘competitive’ environment would be to limit physics to a time-based system. Ex - when the in-game timer passes certain thresholds, one or more physics updates are applied, but not so much that it causes the game to lag on older hardware.
This would, however, cause a VERY SMALL visual desync in the moment to moment gameplay that can cause things to feel _extremely_ different on newer hardware.
It’s a biiig balancing act. If ya wanna truly fix things, fix the real-world economy lol
I read a while back about this issue in GTA Online, frames and physics were tied closely, somewhat rigging races to your hardware. Surprisingly, this was fixed with Expanded and Enhanced.
The reason why framerate interfere with physics is because the simulation rate is frame bound.
An object moves distance pr time unit , then you calculate 'whats up' and fix errors according to the physics (intersections ) .. if objects are intersected , you push them back and continue with the simulation.
This is the simple version of physics calculations.
The more appropriate is to use Euclid's which do calculations BEFORE moving the objects. And therefore doesn't need to fix intersections. .. but Euclid is harder math and therefore not always used.
When you only have 30fps, objects can potentially move further into each other and require bigger fixes. Thereby potentially make you go faster or slower. Having 100fps on the other hand creates a finer gradient of physics with smaller fixes. Which again can improve or slower your driving speed.
This is a universal issue with render engines. Faster number crunching equals faster results. Combine better hardware with less computational load, _everything_ runs faster (clock speeds take on a double meaning here shortly).
I forget the title where this became very evident, but well over a decade now, it was observed in an online competitive looter shooter with very large maps and no fast travel that looking down while running had a dramatic increase on how fast your character could run. Less information was being thrown into the GPU for rendering, increasing not only the overall FPS return, but also the speed at which it is processed. So the test was two characters geared up identically would run 10 miles across the map, one looking only at the ground, the other normal. The character who looked only at the ground received an FPS bump and finished Minutes before the other character.
this should be brought to Playground's attention so it could be fixed... and maybe reset leaderboards
🤣🤣 you must be new to forza
they won't fix anything for shit bro, they became a bunch of child friendly degens
Well in games you can set time in two ways:
Update - It's measure time with Frames Per Second, if you have two computers one with 60fps and second with 30fps you can notice that this same game runs on one computer faster and the other slower
Update with deltatime - deltatime is the time that has passed to complete the last frame in for example unity in default is 0.33 in this case if you have one computer with 60fps and the other with 30fps this same game will run almost equally
Normal update is best use is for inputs or function that be must check every frame
Update with deltatime is used to physics, timers and other things that must be mesaured equally on every device
Unfortunately there is not other way to measure Time in computer devices
Shit like this, and how brutally stupid a lot of the meta builds are is what made me lose interest in FH5 after putting quite a bit of time into it. FH tries to be this weird middle ground in terms of realism and arcade hilariousness and that just breaks it IMO. I've had a lot of fun TBF, and really enjoyed building and tuning cars to a high level and taking on online races. This just gets shit on by stupid meta builds, glitches and half assed development though. It really is a bummer when one has built up their favorite car, spent ages tuning it to be a winner in its class, but then has to resign their mindset to "winning the non-meta class" in online races.
Drifting was fun, I got involved in some online communities that did great, realistic driving and it was the most fun I'd had in FH5. It's a real letdown how half assed the competitive component of drifting is. If a dozen cheap mobile games can implement more realistic drift scoring (zones, clipping points and proximity), why cant PG? It's kind of interest specific I know, but really highlights how much of a lazy, child market cash grab FH has become. Mobile games do most of it's elements better.
Just this morning I uninstalled FH5 after playing it since launch and change my racing game library to two polar opposites that don't try to split the genre and come out half assed. I'm happily playing Unbound for fun and really enjoying the style and story, and getting into Assetto drifting now that people have figured out controller support while I save for a wheel.
This happens because fixed timestep (and thus physics computation) is locked to the target framerate, but not framerate-dependent. It's not the timer running slower, but rather the timer being updated more frequently without as much interpolation between samples. In other words, your timer is a higher resolution at a higher framerate, which is a more accurate representation of your lap time. Anyone running on inferior hardware is actually sandbagging themselves with interpolation errors.
In multiplayer, everyone's clock is synchronized to the least frequent timestep possible to ensure that any potential low-spec users can actually join and play. This means all multiplayer matches are fair in regards to clock speed and your hardware won't give you an advantage in that regard. Coincidentally, it also means handling characteristics and lap times in multiplayer are a bit less accurate in general.
I am so happy you made this video. This happens across games as well
Ahem ahem*, World
It's a very common bug in videogame engines.
Basically it is a rounding error. The numbers in your PC re represented by a finite number of bits, usually 32. When you divide something unevenly, on paper you often generate an imfinite decimal nimber. Think of Pi for example - it never ends. But your PC can't do that - it can only calculate numbers up to a certain measure of precision, after which it will discard everything else. That precision is usually more than enough for any error to be absolutely negligable and unnoticeable.
But sometimes, like here, you may notice it.
Imagine if a timer is calculated every frame. If you run at 60 FPS, you add 1/60th of a second every frame. If you are at 120 fps - 1/120th.
But those fractions only look neat if they are represented as a fraction. If you show them as a decimal, the story is different.
1/60 = 0.01666666(6)
1/120 = 0.0083333(3)
They stretch on infinitely to the right.
Now let's cut them! The PC is a bit smarter than what I'm gonna show here, and much more precise, but the gist of the problem is the same.
I will just drop everything after 5th decimal place,and then round the remainder:
0.01666666... = 0.0167
0.00833333... = 0.0083
And... Uh-oh, we were forced to round up on the first number, but we are rounding down on the second. So at 60 fps we are adding slightly more to the timer than necessary, and on 120 fps we are adding slightly less.
I should note that depending on calculations and exact fps you can see the reverse as well, so it is never a clearcut "more fps = better timer".
Unfortunately, I should note that the only way to get rid of this error is to run your timer in a frame-locked thread or to compare it with system time or something. And even then you will get discrepancies on 2 different machines. This is impossible to fix completely simply due to how computer maths works.
IIRC, someone posted a couple of months ago on r/F1Game a video on how taking the same corner with a big sausage kerb on 30 FPS had almost no effect, whereas at over 60 FPS he was almost flying. That's a game made by Codemasters ( now part of EA but that's another story ) so this makes it even more strange that 2 completely different racing games have this behaviour
F1 2018 also had a bug where tyre cool down rate was tied to FPS aswell. Meaning higher FPS = faster cooldown.
What about playing in less than 10 FPS?
sir, this isn't a mobile port 😂
i knew it wasnt because im a rammer who spams meta!
Interesting. Looks like it's some kind of physics frame dropping on hardware that's not quite able to push enough operations.
Now forza fans will use this as a excuse to why they are still slow
Forza Fans are in reality Pokémon fans because of its toxicity
is there any advantage above 60 fps?
At this point, after 610 hours of playtime on FH5, the game is just awful, might as well just play Asetto Corsa.
>proceeds to play FH5 after writing this comment anyway
Forza Fans = 🤡
On my first watch here, the bit about 30fps vs 60fps and its effect on lap times seems to rest on some flimsy logic. If you just got done running 100 laps on the same track in the same car, you’ve gotten more and more familiar with both the track and how to maneuver around it with that particular setup. It’s not at all unreasonable to imagine that you’re genuinely just doing better and are able to meet the time much more quickly and consistently with all that practice - especially if you’re now receiving visual updates twice as often as on your first 100 attempts. Those are both pretty huge advantages.
With the difference in physics between 30 and 60fps it makes me wonder how something like 24, 75, 90 and 120+ will fair for those on lower end hardware and those with high refresh rate monitors.
hokihoshi tested 30vs60vs120fps. the difference between 60 and 120 is very minimal compared to 30 and 60
This is the worst car game I’ve played in years. You don’t feel a connection to your vehicles, cars are basically just handed to you, the map is huge and empty.
i always felt like my high fps gave an advantage more than just better reaction time. thanks for the intel!
This is true for all games. In sim racing titles like Raceroom, AM2, I racing, etc., you can have a screen that only does 60fps but the game does 90 or 120 fps with a frame viewer. With each fps all of the inputs and physics is updated and calculated. So, 120 fps is going to be more fluid and accurate in it's handling even though the screen is updating at 60 fps.
There was a mod that allowed one of the Transformers games to run at 60fps. The catch was the physics were a little off because the engine was built around 30 updates a second.
This situation rememberem me the things with 3d fallout engines and why an internal clock is so important
Basically, in 3d fallout the physics engine does the calculation on movement, time and so on based on your frame rate, given the game was made to run @30fps anything bigger than this will cause problems, we see faster movement, objects behaving weirdly and many clippings happening
To solve this problem many developers started implementing an internal clock, it limits the ammounts of inputs the game engine recieves so you don't get weird bugs while maintaining a high fps count, see any multiplayer game for instance, the vast majority of servers only register stuff @30fps so to maintain low performance cost and a somewhat smooth physics simulation
I believe the same things is happening to FH5, either the engine lack an internal clock that limits the game inputs to a set ammount or the game does feature an internal clock but the same is set to capture >=60 inputs per second, resulting in weird behavior from a lack of inputs
This is because the physics are not independent of the frame rate. In many games this causes the physics to break if the frame rate goes too high or too low. Physics calculations are done on each frame so if there is too much frame time (between frames) the physics aren't calculated in real time or vice versa causes issues. If they are dont independently this issue is resolved
Does this advantage extend to 120, 144, and even 300 frames per second or is the internal clock rate(unsure of exact terminology) limited to 60 per second?
Id like to see a pc capable of running this game at 300fps.
@@redcatxb125 fh5 isn't a particularily hard game to run at the lower settings, 300fps is certainly possible on not-obscenely-expensive hardware
Everyone jumping on RUclips to find meta builds and you can't find one race without someone using "the best meta car" for each class
amazing job, good work m8!
this reminds me of the quirk in Doom Eternal where extremely high FPS affected the physics of the meathook and players with that hardware learned to fling themselves across the map
Tons of games have this issue. Amongst many genres. There's even some games the benefit from intentionally lowering your frames per second to 1-2 on the opposite end of this videos spectrum.
As a developer I can confidently say; Forza coming out on a new engine MAY fix this problem but there will be 50 other problems to replace it
I think this is because the delta time is a float of 32 bits and when it multiplies to get the values of the timer and physics it just loses a little bit of precision every time
game physics tied to framerate has been an issue from time immemorial. many games tie the physics to the framerate, and you can abuse that by limiting or unlimiting the framerate. I would bet a lot of the world record runs are done at 15fps because it means the physics are updating less and thus, not as effective. this is why other online racing sims don't tie their physics models to the framerate of the client, because that would leave opportunities for a huge client advantage on one direction or the other depending on how they react.
Other gams have some similar bugs, for example, the hit horror game Poppy Playtime. Running at 60 fps or above gives you normal physics. The lower below 60 you get, the slower the physics runs. The physics aren't intended to be tied with the fps, but they are. At 15 fps the first jump in the game is almost impossible.
Knew it wasn’t because we spent five nights at Gumi’s 🦜
🐦
sweat opr mfers
🦜
You will always encounter these accuracies unless you use deterministic code, I don't know any game that uses a deterministic physics system, apart from games that have very basic movement that doesn't require a physics engine, such as among us (probably).
The reason why it doesn't happen in online races is likely because the multiplayer system is server biased (i don't remember the actual word) which means that what you see in your screen is just a local simulation, your inputs are sent to the server which then runs its own simulation and decides the actual results. If there is a difference in your local simulation and the server simulation, the game will gently apply the corrections to your local sim. If the difference between what the server calculated and what your game calculated is too large, that is when the game might teleport you to the server's calculated position. Besides that, even if the game ignores a small amount of difference, the timer will be based on the server's simulation.
So it doesn't matter if you're running on 10 fps or 100 in your local sim, what would matter is the server's performance. Even that won't matter much in a race since everyone will face the same affects caused by the server's performance
The best part is that for us people on Xbox Series (and formerly on Series), most of us probably gave up on Forza Horizon 5 after we were forced to put a 230+ GB game on the internal SSD when it works perfectly fine on a HDD.
So they actively hurt people who are poor, and people who become poor.
pro tip: dont play forza
For real, forza is such a shit game😂
Why? It’s a good game. You’re not gonna play this game over a 0.2 second inconvenience? You pretend as if the developers could have foreseen this teeny tiny problem in over millions of code.
@@ZqTi0 honestly i just dont like forza lol
@@ZqTi0 make slot cars in roblox studiob🗣🗣‼️‼️‼️‼️
@@lebronjames-lb8jcuz u play roblox su
That explains a lot why when online competitions I cant be even in the middle no matter what I do.
So if I play at 165fps it’s even bigger advantage lol
i'm guessing the source of the problem is floating point imprecision. the bigger your framerate is, the smaller your deltaTime is going to be (the amount of time between each frame, used in math calculations ran every frame), so as the accuracy of the variable diminishes, the bigger the skew is going to be. this can cause problems like slower/faster physics depending on framerate. the only solution would be using a fixed tic system a la older games
This feels like the type of thing that Microsoft would just never bother to fix
I recently doing a real time rendering job for an earthquake simulation in UE. The only way to get a precise calculation is by NOT going real time. Dividing and calculating 1 frame 20 times will get you more accurate physics. But it will slow down your rendering by 20 times. that's what basically what's substeps does.
So if you're using a slow PC, the calculation of 1 frame could cut short, and it goes "fuck it, just move to the next frame" and you get a very bad incomplete calculation. This could lead to understeering a lot.
In other kinds of games, say fps for example, where you sometimes see boxes or ragdoll goes crazy, is because it had 1 bad frame, and it intersects with the floor or other rigid bodies, and the next frame goes "that's not supposed to be in here" and tries to push it back out, which leads to the boxes launches at high speed.
Best forza content
for professionals :)
My guess with the framerate changing the physics is that the physics is calculated on every frame. More frames = faster calculations = more accuracy
Interesting video. I have an xbox and a pretty good pc (framerate is normally in 100s). I run lots of rivals mainly on pc, but sometimes on xbox. I've set pb laps on both. I can't say I've noticed this bug myself and I usually race my own ghost. It seems like a massive oversight for a racing game if it is correct.
The fact the game physics are not deterministic is already a oversight as it is
At a blind guess I'd say they are using delta timing. This is where the games mechanics, in this instance a physics engine, are run once per frame with a time_step interval, called a "delta" time to process how much movement happens during that physics cycle. It's the fastest and most efficient way to squeeze more fps out of the same hardware. However, in instances such as the suspension wobble you showed, the delta time for a frame is too course to simulate the debounce on the suspension. Serious sims tend to circumvent this by running the physics at a fixed rate that is decoupled from the frame rate, but as you can imagine this means running the physics much faster in order to for the frame updates to represent a smooth interval of time, otherwise alternative frames would represent very different deltas and the framerate would feel slower than it really is due to the choppyness. Therefore highly compound numbers work well for physics rates, (120/240/360 etc) but such high frequencies can be difficult to achieve on entry level hardware. Thus, Forza - being a mass market game - is aiming to support as much hardware as possible, and I suspect that is why they have opted for this variable delta timed physics approach.
I don't think there is really a complete solution for this problem, because a better pc will just go through the code in the loops faster. I had the same problem (but far worse) in a small racing game I had to programm for university and the professor said there isn't really a solution to fully eliminate that problem. On my slow Laptop it would take about double the amount of time to finish the course compared to a gaming pc.
Your professor was likely not that well versed in programming. There are always work arounds in the virtual world it's why really terrible HW by today's standards was already able to give us consistent results.
this is not just forza a lot of fps have this too, the higher the fps the faster your gun shoots
GTA online suffers from the same issues.
The higher your framerate, the faster some cars go.
The Pfister 811 was one of the fastest cars due to the framerate bug, beating rocket cars.
Add this with curb boosting (the suspension compresses and decompresses creating more speed) and you're not losing a straight line race.
I've seen something of the same nature happen to some graphical adventure puzzles. The game update the timer every some amount of prosessor cycles instead of real time, while online timers depend on the servers' cycles.
I can almost guarantee what is happening here is that the devs created the timer by calling it in what we call the update loop without multiplying it by delta time. The update loop runs the program connected to it every frame and basically what multiplying by delta time does is make sure it is measures the time between frames in actual seconds so it is no longer calculated depending on frames. We will never really know unless we get our hands on the programs inside, but that is the most likely reason for this problem. Most likely a bug could be intentional for other unknown reasons.
Really interesting !
I immediatly think of "simulation" :
Physics in a car game is always simulated. While in the real world, the compression of the spring is continuous, in a simulation, it is discrete.
In mathematics, something continuous is when all values of times (in this example) are available. Something discrete is only "step-by-step". For example, y=x^2 is a continuous function, but Fibonacci sequence is discrete (1, 1, 2, 3, 5 etc, but nothing between 3 and 5).
For a 30fps rate, values are calculated every 0.0333.. seconds and for 60fps, it's every 0.0166... seconds.
It seems a detail, but for a simulation it highly important. Due to the interaction between all values (with derivatives, primitives etc), calculations for continuous in live are quite impossible, because there far too massive. So physicists and developers use simplified discrete calculations. Far more simple, far faster, but more or less approximative. So approximate that for the same starting value, the t=0.003 value at 30 fps and at 60 fps will not longer be exactly the same, simply because at 60 fps there was an intermediate value.
On the contrary, for a rendering scene in 3d, you can use longer and more precise calculations. That's why rendering in a 3d software takes so long.
That is why you don't lock your physics calculation to frame rendering and run separate fixed updates for it.
The weird thing is the game physics should be running at an independent tick rate from the framerate, so why there's a weird correlation is interesting.
They do. But there are always going to be small inconsistencies. You see this in every piece of software on earth. The more complex the physics simulation, the more inconsistences stack per second. Its a physical issue. Computers run in real time and you can't change that. Delta times can't be infinitely small because you have a limited number of bits to represent any number. (and floating point inaccuracy). Its not interesting its a fundamental aspect of computers.
@@Wylie288 which is interesting.
watching this video after the physics engine explanation video from the engine simulator guy makes it make so much sense.