The Unity Engine's 50Hz Physics Problem Strikes Again!
HTML-код
- Опубликовано: 4 июл 2024
- ► Watch the FULL Video: • DF Direct Weekly #169:...
► Support us on Patreon! bit.ly/3jEGjvx
► Digital Foundry RUclips: / digitalfoundry
► Digital Foundry Merch: store.digitalfoundry.net
► Digital Foundry at Eurogamer: eurogamer.net/digitalfoundry
► Follow on X/Twitter: / digitalfoundry
"IT'S MONKEY BALL' screams the man in a wifebeater :D
This is the content I'm here for.
TIL monkey ball is a genre
I had this exact issue in unity when i was, like, sixteen. I noticed it, i fgured out the problem, i fixed it. This isn't a flex, this is unity 201 lmao. Insane that a whole-ass studio like this didn't know.
People would just tell me my PC was bad, so infuriating. Dead Core was the biggest offender for me, in both how awful it looked and the community of people saying it doesn't have problems lmao
I hate when a large amount of people just don't see obvious shit. Lol I mean, this is why we have stuttering in the UE engine. Half the people don't notice it or don't care, so the problem doesn't get fixed for years.
How did you fix it?
@@Zinkolo interpolation
@@kosmosycheI mean, for some if you aren't primed to look for it, you won't find it. I had that happen to me with the shudder I believe it was? In Bloodborne. The game is a steady 30fps on PS4 Pro w/Boost Mode. Yes it has frame time issues as far as I know but to me it's always been perfect. No issues with controller response which is the most important aspect of those games. Had a hell of a time and never once thought it to be weird.
I did send Sega support an email about this and they respond that they're "aware" of the issue and "investigating".
So that's something at least.
That is the default canned response of any support staff in general. They will say this even if the issue isn't even on their side and which has known fixes, like the Intel CPU debacle for example.
It's definitely something. 🙄
@@okesikThe default answer is “we’ll pass your feedback to the dev team”. You never acknowledge that there’s a problem in a default response template.
3:48 You know it's bad when John says the f-word.
The f word: Final Fantasy
D:
But he didn't
fetard or figger?
Pro unity dev here. The physics update rate, know as the fixed update rate in unity, is represented as a floating point number. It is set to 0.02 seconds which is 50 fps. Setting it to 60 fps is actually impossible because 1/60 of a second cannot be represented perfectly as a decimal. You need to use a value of 0.016666.... This reduces the frequency of stutters but can't eliminate them because the last digit gets rounded to a 7. At best you can reduce the stutter to 1 frame every few seconds. Interpolation works, but a better solution is the have the camera lerp to a target position. This removes the camera from the physics engine altogether. Honestly it is about 10 minutes of work.
Non-Unity-dev here. That works for the camera, but what about the movement of the balls themselves? If you interpolate then you add latency, which sounds bad for this type of game. A quick Google search suggests that there’s an “extrapolate” option. Perhaps it makes sense to use that, combined with getting the update rate as close to 60Hz as possible?
@@comexkextrapolate is a bad idea. Interpolation looks fine, but if you want to remove the issue completely you can also just switch physics from fixed update to normal update so it will update exactly every frame without skipping anything. This can cause delta time to be unstable but if your game is locked to 60 fps all the time it should be fine. Like Nintendo games are locked to 30 fps and if the game is lagging it just gets slower (delta time is a constant value), which ensures physics stability and perfect timing
@@comexk interpolation and extrapolating is almost the same thing. You're most likely not going to notice the latency unless it's an extremely high precision game or a rhythm game, so interpolation would work fine.
Use 0.01 seconds (100fps/Hz), problem solved.
@@saricubra2867 Outside switch there's plenty of screens with higher refresh rates lol
Inexperience with Unity or severely lacking QA processes seem to be the root causes here. I find it hard to believe that a professional Unity dev would intentionally setup a camera rig this way or that the issue would go unnoticed all the way to the release build.
QA can only do so much, the rest is in the hands of "too proud to take feedback" devs. You'll see it even in public with memes such as "but artistic vision" or "it is as designed" or "we have not identified a problem in our game".
Some folks are both inexperienced and unable to acknowledge their own mistakes, and again, no amount of QA can fix that when their feedback is ignored like that.
Video lists multiple cases where it's happened
It's such an easy fix in Unity and is just pure laziness or a lack of care from the developers, they should just release a patch for it
I hate calling developers lazy but in this case I think it's just sheer brain rot.
How these devs don't notice obvious stuttering is beyond me But I can only hazard to guess that Japanese devs don't notice these things as much as Western Developers do since we are more focused on performance and graphical fidelity than they are.
But at the same time they made the dragon engine so what gives?!?
@@ZinkoloDisco Elysium has the same problem so I wouldn't say it's an Eastern developer issue
@@Goob1246Not eastern, but eastern european in that case. We do produce eurojank. Disco Elysium has the excuse of being their first game for a lot of the devs though.
@@Goob1246 Disco Elysium doesn't have physics as the main gameplay mechanic so at least it sort of makes sense why it wasn't noticed during development. Hell, I've played that game and I've never noticed the physics looking weird
@@ivandarmawan9372 it's not about physics but about camera movement, Disco Elysium camera stutter all the time if not played at 50Hz or multiple of that, same for all other games with this issue. I've lost the count of how many times I've reported this to indie developers... I've managed to get developers fix it for Yellow Taxi Goes Vroom at least.
You can also just change the Fixed Timestep setting (That controls the fixed tickrate in Unity) from 0.02 to 0.01666666. All the Unity projects I work in now, we do this as it's silly to have the physics & fixed tickrate update not be divisible by 30.
Yup you can do this in preferences of the project
Is there a difference between this and what they said in the video about changing the tick rate to 60hz? Genuine question here, are those different things somehow or are you simply describing the actual means to do it.
I'm a hobbyist, but haven't been messing around with games for a while so I'm curious.
@@milddiffuse Well the physics time step & the game time step are disconnected from each other & can be set to run at different rates.
You can run a game at 120Hz without having to increase the physics to 120Hz. Increasing the physics that high would probably slow down the game.
Instead, you can run the physics at a lower rate to the game. 50Hz is fine for most physics interactions.
The problem is that the physics objects are out of sync with the frame rate of the game. They will appear to stutter as they move because in some frames they don't update.
To fix this, you can interpolate the motion between frames.
So, the physics will still run at 50hz but it will look like 120Hz because its motion is being smoothed out between the frames.
@@milddiffuse it's the same thing.
1 / 50 = .02 = 20 millisecond
1 / 60 = 0.0166 = 16.66 milliseconds
@@john_hunter_ Just to be a little nitpicky: allot more game logic is likely tied to the physics tick rate then it is the rendering rate... I'd more say that the GRAPHICS and the game are disconnected, then the physics/game.
The game itself exists entirely in data, and that data often changes with the physics rate. The rendering-side of games is simply a representation of that data, and you could technically have a physics tick of 1fps and have good enough interpolation where you could render at 120 fps and not even realize that internally objects are jumping massive distances each movement tick(interacting with the world would just be very unresponsive).
I've been bashing my head against a wall trying to figure out why my movement in unity looked janky. I knew interpolation "fixed" it but I'm the kind of person that want's to know WHY.
I literally have my main project open while watching this video, and in the time it took for the video to finish I found how to change the physics rate to 60hz. DF always delivering knowledge even at the least expected time!
rb.interpolation = RigidbodyInterpolation.Interpolate;
rb.collisionDetectionMode = CollisionDetectionMode.Continuous;
The devs should absolutely do this themselves and patch it, but with this being so simple, I feel like even a dedicated modder could just enter these enum values into wherever this is necessary (in a base class preferably so it would go down the chain on everything maybe). Just feels like a mod could fix this very easily.
EDIT: Oh I missed the part earlier where this is only on Switch... yikes.
@@desmondbrown5508 If this were on PC, I'd be able to make this mod in an hour (or 10 minutes, really depends on how hard it is to find the right file)
@@gwentarinokripperinolkjdsf683 They should pay you for some big brain move. (Note: This is consider a big brain move for Unity developers who isn't aware of this problem for some reason)
Collision detection mode change isn‘t necessary
disable.denuvo=true;
give.allDLC=also.true;
I use unity and never knew this. No wonder my games look choppy... thought I was doing something else wrong
Someone forgot to enable physics interpolation
Unity dev here, this is the devs fault. This issue is beginner-mid level.
The camera movement is likely nested to a physics simulated object (bad).
Instead the camera should update freely and physics should be interpolated or run faster than screen refresh rate like 100Hz (if perfs allow it, which today devices do without problem, Unity PhysiX can even run on PSP lol)
That second option is not viable for the switch, which is what's being discussed.
@@InvidiousIgnoramus I suspect that it's very viable to simulate 2 or more physics steps per frame, even on a slow device, when you're dealing with one moving sphere vs mostly-static geometry. With Unity, focus optimisation on rendering, keeping draw calls down, or it'll eat a whole lot of CPU time (And for mobile/switch, keep shaders simple too)
@@InvidiousIgnoramus I don't think that's a genuine limitation for the type of calculations needed for the gameplay in monkey ball. There is one physics object and it's a sphere. The level geometry is flat planes. The collision test is something like a dot product and a vector difference. Something like 100 clock cycles. They could test the sphere against every single surface in the level every step and still probably 10x the number of physics steps without significantly eating into the rendering budget.
The game already drop to 5 fps on the switch, no need to make it drop to 0 fps
@@1337pianoman Yes and no. There is a 16 player multiplayer mode, and they clearly want this to be as big an attraction as single player, as evidenced by the common features in multiplayer focused games, like a season pass. Yes, there is a monkey ball season pass. I personally have no clue how much physics calculations are done on which connected devices or if there's even a server involved. However, it would be sensible to believe it's more resource intensive that single player. Hopefully they weren't dumb enough to optimize for single player as they do multiplayer. Not that you can even compare them, since multiplayer barely hits 20fps.
For single player, you're technically wrong. Monkey ball, this game included, features many physics based gimmicks, such as weighted cylinders and, in this game, free rolling spheres. Obviously there's many moving objects on cycles too, but we all know those are essentially moving walls. However, the game formula you described was actually used... on the friggin gba! I shit you not. So, yes, the physics can easily be ran on the switch, assuming the upgrade from game boy advance to switch should accommodate the addition of a level with 5 rolling spheres.
Imo multiplayer on the switch was always going to be god awful, and everyone knows this. Any argument stemming from the idea that they catered the physics for multiplayer only shifts the blame from incompetence to naivety
The ironic part is there are people who say they can't see hitching, stutter, or frame drops. That's bad to have on a dev team lmao
I have gotten burned too many times from people saying that a Switch game runs perfectly smooth, then I play it to find it a stuttering mess. It bothers me just how many people don’t notice these problems.
Yeah, those people should probably either stop talking, or be tied down and forcibly educated on what they "can't see", because their ignorance is ruining the experience for everyone.
It's absurd that people are allowed to become professionals while being utterly clueless as to any technical details about their craft. But I suppose that is only natural thanks to the proliferation of pre-baked engines that allow any skilless fool with no self-awareness to call themself a game developer.
"Forget it Jake, it's Monkey Ball"
Not a Unity problem, guys. It's a developer lack of knowledge problem.
Unity uses PhysX from Nvidia ans it allows you to tweak the physics timestep as you like.
Also, tiying visuals with physics simulation is a junior game development problem
Why is it 50hz tick rate default for physics and not 60 or 30?
Because you have to set it in seconds. 50hz = 0.02s, 60hz = 0.01666666... Why they don't make it based on hertz though i have no clue, probably because of some low-level computer stuff.
The tick rate is not super relevant. Setting it to 60hz would cause the same stutter at framerates higher than 60fps. Also, it might cause problems even at 60fps because there is no guarantee that the start of a 60hz physics tick is also the start of a 60fps graphics update.
My guess is that it's coded for PAL regions as Unity was originally founded in Denmark and it just never got changed
@@kortyzol420 Unity can't measure milliseconds? If it only has integers for centiseconds I understand but I refuse to think that's the case.
@@AzaiaMonota Yeah, I imagine this traces back to PAL in some way
As someone with a bit of Unity experience: this is not a bug, this is an "issue" in any game engine or game with a flexible frame rate. The devs likely tied the camera movement to the fixed physics frame rate, which can get desynced from the frame rate of the renderer.
Basically: the Unity engine (and most other engines out there) have two main update methods:
1) FixedUpdate, which is untied from the frame rate and gets called in exact intervals, which is useful for physics and code that NEEDS to run in perfect steps (like character controllers)
2) Update, which is tied to the frame rate of the game.
You usually put camera movement code into something called "LateUpdate" which gets called directly after "Update" and then use "Lerp" to smooth the movement.
I guess the devs wanted the camera to stick perfectly to the ball, which means they likely put the camera as a child of the character (ball) or put the movement code into "FixedUpdate"
Thats bananas 🍌
The FF pixel remasters were just weird releases in general
Why I will never sell my GCN monkey ball games. For whatever reason they can't top them.
I noticed that with RE4 too the red light laser is the best on GCN and has been inferior on every other port including Wii and PC.
GCN also had the best original Beyond Good and Evil. Xbox was a close second but the water was better on GCN
This is 2024's version of the NTSC/PAL speed issues.
2:31 John, I think you mean "which is bananas"
Isn't this what the physics interpolation/extrapolation is for (which has been a feature since Unity 1.0)?
Yes but mainly the camera should not be dependent on Fixed time
@euden_yt If the camera is following an object, you want the object to remain the same size and position on screen. You don't want that object to judder further/closer from the camera. The rest of the setup need to adhere to that. So fixed time is not the core issue, cohesion between the camera & target is, and also you should have interpolation on your target & camera.
Are you fucking kidding me this is what causes that obnoxious problem. I have always heated it and thought it looked incredibly unprofessional and it was that damn easy to fix???
As a coder, it’s a constant humility refresh that despite cool complex systems, things like this can still bottleneck the quality of my output.
Game devs got nostalgic for the NTSC DVD 6th frame duplication! 😂
Why is the camera attached to a physics object at all? What purpose could this possibly serve? I’m asking because I genuinely want to know.
I read about this issue regarding banana rumble, still bought it. I didn't know this issue stems from the unity engine, shame.
You can't blame Unity. They set physics default to 60hz and then game runs uncapped or just at a higher framerate. Same problem now. Even worse, because if there's any frame drop, just so slightly you'll have a frame with 2 physic ticks. Most have 144+hz monitors now, so interpolating physic objects and making presentation position detached from actual simulation position is totally normal nowadays.
The only one to blame is the devs who seemingly didn't catch it. Which is very odd with todays resources.
I highly doubt that most people have 144 Hz monitors now. High refresh or 4K displays still seem to be used by a minority of PC users according to Steam surveys.
I personally refuse to get a 144 Hz monitor because it would make so many games that are locked to 60 FPS look horrible. 120 Hz is preferable.
@@11clockyMost people might not have 144Hz monitors, but I would say that most people have monitors that have refresh rates higher than 60.
And to take such a stance against an obvious, inarguable improvement is pure ignorance. We are at the point where even the most sludge-grade, sub-$100 monitors support VRR, and therefore are perfectly capable of locking themselves to 60Hz when a game runs at 60fps. Educate yourself and improve the quality of your life.
Or use the Update or, better yet, the LateUpdate loop and use the Delta Time or even Smooth Delta Time for updating camera position.
That's what I was thinking, just don't attach it to a physics object and let the pos update normally.
So THAT’s why Dave The Diver looks that way…. Will they fix it ever?
For what it's worth, the Series X version of SMB: Banana Mania seems to have fixed this via a patch at some point! I've been playing it again recently and it's buttery smooth now, no 50Hz stutter when the course begins.
Unfortunatelly, the problem was still present in the PS5 version a few days ago :(
@@Zebes1984The PS5 version of Banana Mania looks very smooth to me, with a stutter only every once in a while (which I assumed to be the garbage collector). Banana Rumble on the other hand I am finding practically unplayable with how horrible the stuttering is.
@@11clocky Ahh, the problem I have noticed in PS5 is the one you described: an small stutter or frame drop every certain amount of time. I thought it was the same case in Xbox version and this new game in Switch.
@@Zebes1984 In Banana Rumble it’s 10 times a second, which is substantially worse.
It's sad because Banana Rumble is SOOO good but performance is less than ideal.
I wonder if future PC or PS5 ports will have the same problem since it's a engine problem
Yes unless they fix it. On pc, mods definitely will.
interpolation as in when using a rigid body?
In the year of our lord 2024 there are still devs coding logic linked to frame rate???
This is not a unity problem since you can just use interpolation or use physics directly in Update, it is set to 50 hz by default because it is the sweet spot that works with all frame rate, this just looks like there were not proper testing of quality
Also giving the camera a Rigidbody and setting the interpolation to Interpolate would fix this issue, at least partially.
This game almost certainly does not have demanding physics concerns outside of precision, so there is no excuse for using 50hz for physics.
Gotta agree with the video 100%, It drives me nuts seeing when this happens.
Unity should enable these settings by default.
Just have the camera follow the object instead of tying it directly.
Take the difference from of the object location between frame and have it move by a division of that
In my experience with Unity, using interpolation doesnt fix camera judder. It improves it for sure, but there can still be issues.
You need to use SmoothDamp (a function built in to Unity) to get it smoothed out
but SmoothDamp averages the object's position over time, so it does add a squishiness (for lack of a better word) to the camera motion that might not match the feel you want for your game
That is a super bummer to hear, I kept reading this was the best Monkey Ball since 2, which isn't that high of a bar to clear because they've all basically been crap since then but I was still excited to try it out. Was about to buy this last night after FINALLY beating Rebirth, but maybe I will hold off for now and hope for a fix.
Unity have like since year the really comprehensive camera system called Cinemachine and if you use it you don't get the problem because the interpolation works properly.
So they got out of the way to create there own camera system and still forget to fix the interpolation instead of just using Cinemachine.
Also PhysX is like the old engine, now Unity is more and more want you to use DOTS Physics or Havok.
Having a higher physic tickrate also makes physic way better and accurate.
If the issue is easilly fixable, why doesn't unity change the default settings to prevent the issue?
i find issues with the physics in games made in unity so often, is it just janky naturally?
Yes, but it can be mitigated with some basic know how. Some devs missed the memo.
Why 50 HZ? Where did that come from for Unity?
This problem also affects the Unity PC ports of Doom Classic and Doom II
We've had the same problem, had to take fixedupdate vs update into account everywhere to avoid stuttering. Interpolation made everything look worse
I've never seen or played a Unity game that didn't have a stink about it. It's like the 3D equivalent of Flash.
Try to edit something that doesnt divide to 30 or 60 is just pain, so setting the screen refresh rate to 50 is the bad option here.
The amount of people at the top of the Dunning-kruger curve in the comment section is insane.
So it’s difficult to change Unity’s physics tick rate from 50hz?
I've used Unity for years, almost a decade. Changing the physics tick rate is as simple as opening the project settings, going to the physics tab, and changing a single text field. It can literally be fixed in under a minute. If you'd rather go the interpolation route, that's even easier. Just select the object that has the rigidbody component attached, and select "interpolation" from the "interpolation type" drop down. It's not a bug, but a case of the default settings in the engine being suboptimal.
Even more insane is people who have never used unity assuming this is some insurmountable obstacle that sega couldn't possibly have foreseen despite it being well documented, easy to spot, and easy to fix.
@@johnclark926 Changing the physics time step doesn't solve the problem.
You can try to match the physics time step as close to the frame rate as possible, but it will never be perfect.
Matching the time steps will reduce stuttering a lot but it will still be visible.
Interpolation is the only solution & it works no matter what the physics time step or the frame rate is.
@@john_hunter_ Yeah that, and don't update visuals in FixedUpdate() and use the Transform position and not the RigidBody position since it is the one that will have interpolation.
How does this even happen?
Really all of these issues because the default value is 50Hz?!? You mean they don't even check the refresh rate?!? They don't see the frame skipping?
All they had to do was change it to 60 or tick a box for interpolation? These are amateur mistakes, I would expect this from a highschooler learning Unity by themselves not professional game studios.
Yeah, it doesn't make very much sense. I'd love to see some undercover reporting on how QA is done at these studios because this problem is ridiculous.
Can't see it
I encountered this same problem with Unity. Interpolation will fix the issue in most instances.
But there are times where simply turning on interpolation won't fix it.
The devs could have interpolation on but the interpolation doesn't work correctly because of the way they are programming the movement of the ball.
To fix this issue, you need to do a "late fixed update" that sets the position or rotation of the object after all the other fixed update code has finished.
This ensures that Unity correctly uses your position & rotation for the interpolation.
Unity's documentation states that certain functions will move physics objects to work correctly with interpolation, but it's not true.
Been doing game dev for a decade. Simple problem that Unity cant and shouldn't fix. Devs need to understand variable vs fixed frame times.
I reckon they used unity for this, because unity was also used for the judgement pinball minigame
This is a never-ending problem with shittily coded games. Games will never stop being released unfinished because we keep buying them.
Hyper Dimension Neptunia : Sisters vs Sisters also has this problem as well as it's sequel GameMaker Revolution. The motion sickness is real and the fact that CompileHeart haven't noticed this or don't seem to care about it is upsetting. It's apparent on PS5, PS4, Switch, Xbox and PC. All platforms they ship to for those two Unity based games.
So many Japanese games have this issue with FixedUpdate. I made a few mods for games to change the FixedUpdate rate to the screen refresh rate (Little Noah) or to patch the offending gameplay logic (Neptunia Sisters vs Sisters). I've been needing to get around to fixing the stuttering in Samurai Maiden as due to the physics relying on 60FPS timing, simply raising the rate caused issues with jumping.
Godot is luckily fixing this issue with Godot 4.4.
Fix it please! 🙈
GeneRally 2 has / had it too. Insane how no dev seems to have noticed it. Instant red flag when developing or testing I would say!
Why isnt this game on PC?
Blame the devs, not the engine this time. Unity is not perfect, but this is just lazy.
How do I know? I make games in Unity, please check Ziggurat 2!!!
It's so weird how well documented problems like this can plague engines and games for years. 🤔
edit-
Evidently, for this problem in Unity, it's not a simple solution. I've seen more than one developer talking about how difficult it is to deal with in Unity, often having to come up with hacky solutions. Apparently even if you set physics to 60, if a camera is locked on a physics object, it will still generally render incorrectly and jump around inconsistently.
It's not an engine problem it's a game problem. If you tell the camera to update at 50hz that's what the engine does. The problem is developers not understanding what they are doing + some developers are so insensitive to stutter and frame rate issues they can't tell the difference between 20 fps and 120 fps, let alone be able to notice a 50hz stutter at 60fps.
It's not really an 'issue' per se, Unity by default has physics updating every 200ms detached from the main loop, which updates as fast as possible (or capped to a max fps value). This is done this way because physics need to have a fixed tick rate to make it behave the same way every time. As per why the interpolation is not enabled by default, I assume it's mostly due to it not being needed 99% of the time
@@TheCrewExpendable It's a problem if it's the default setting. People don't change default settings unless they have a good reason for it.
Evidently, for this problem in Unity, it's not a simple solution. I've seen more than one developer talking about how difficult it is to deal with in Unity, often having to come up with hacky solutions. Apparently even if you set physics to 60, if a camera is locked on a physics object, it will still generally render incorrectly and jump around inconsistently.
@@TwinOpinion Unity Developer here, anything related to Frame Rate and Hz in Unity is a pain to deal with, it goes way beyond just messing with some settings. For example you can set the Target Frame Rate(Or the FPS Cap) to something specific, however more often than not the engine will not cap at that, due V Sync and a lot of other things, not to mention the mess that the Frame Pacing will be. And as you said, the usual solution is a bunch of hacky code that is not ideal.
Interpolation does solve this problem.
Also, Nintendo was not cared about precision for a very long time. The modern taiko no tatsujin game is unplayable compared to the old ones. It takes like an entire training session of months to get used to the new set up. The lag is horrible and the performance is not great and, I think a lot of it is because of the motion control processing and other complex processes that have to happen because the value features over reliability
at least it's an easy patch for the devs.
Fix it !!!
This is too nerdy for me to even understand the "problem" here.
But it seems to be legit since John pulls examples from consoles which prime is long, long gone.
=)
Game looks choppy instead of smooth because of a unity setting/camera issue.
Sorry I can't see any difference AT ALL between the examples they look identical to me.
Same. I want to see the problem lmao I can't.
Some people are more sensitive to framerates than others. I can tell very easily.
I am still flabbergasted by people who can’t tell the difference between 30 fps and 60 fps.
Bloody hell. back in the superior CRT days 85hz was the bare minimum. Sad times indeed.
Either they didnt care or targeting just 30fps.
it boggles my mind how game development studios miss simple things like this that are so crucial too the playability of the game do you guy's not play your own games? My pet peeve is develioetrs that refuse to check the box to allow real exclusive fullscreen. Yes I know borderless window is supposed to be better in this day but some times its simply not (and can cause other issues.) Please just put the option in..
I guess they just played the game and worked on it for so long they went blind to it.
This is not a Unity issue. It’s a game developer using Unity incorrectly and not interpolating positions issue. It’s actually not even hard to fix with a bit of code
No, its Unity's fault for not defaulting to 60 hertz
Please stop trying to shift the blame
@@KenBladehart It won't fix the problem because physics updates are not synched with normal updates. You will still get stuttering. Proper solution is interpolation at normal update.
@@KenBladehart Wrong... proper fix is simulating at a reasonable rate like 300hz.
@@KenBladehart No because then if you run at an arbitrary frame-rate like 100 hertz (yes monitors do exist with this rate I own one) it's off still. Interpolation is the correct solution for physics updates no matter what the base update rate. Please stop acting like you know what your are talking about.
@@KenBladehart So what do you think would happen if you run the game at anything else than 60 fps? Like OP said, it is a developer not knowing the engine they are using issue. Physics using PhysX always update at a fixed rate independent of the game frame rate for accuracy reasons since the rendering frame rate can be all over the place. Rigidbodies then interpolate between each physics frame. So they either update stuff in the FixedUpdate() or have interpolation disabled. Also, it takes about 4-5 clicks to change it to 60 hz or whatever number you want.
IMHO, bad defaults are bad defaults. Sure you can fix it, but it really shouldn't be on the game devs to make Unity look good.
THe timing on this video. I tried playing Tormented Souls last night and gave up because of this.
Urgh. This explains so many issues I’ve seen in unity games, first time I properly noticed was Long Dark early access.
This is not unity issue or a bug but inexperienced developer. The reason physics engines update interval being capped is to make sure simulation is deterministic and updated at constant intervals (20ms instead of random fluctuations) so if your frame rate is lower than this value it will even update multiple times. The reason there is jittery motion is the difference between camera and the player's update rate which unity absolutely does allow you to choose.
This is not a Unity problem. Its a coding issue. Blame the developers, not the tool
This kind of jitter is really a common problem of bad coding
Matching the rendering fps is not a god solution and would still cause jittering when fps might not be reached. Physics framerate should ALWAYS be set as low as possible, so that physics simulation still behaves correctly and doesn't waste additional CPU resource beyond that. Then to make visuals smooth, there's the 'interpolate' option. It's fine for most gameobjects, but for camera I would still unparent/unconstrain it from the rigidbody and just use my own smoothing algorithm for setting location and rotation based on target in the update loop. Smoothing based on 2 or 3 past physics frames gives perfect results even if you run the game 200fps.
Locking the FPS to 25 should do the trick, right? Right?!
🙈
/s
I've been on the fence about this game. Despite all of the problems, it looked really fun. But this has convinced me against it. Massive bummer since this is such a fun concept for a Monkey Ball game, but SEGA seemingly just doesn't want to do the IP justice.
I literally couldnt tell the difference until you mentioned it. the new monkey ball game is so great!
I have smooth gameplay ... just a very convoluted codebase. Hahahah
Hear me out...
Monkey Ball with Dragon Engine Phyiscs :D
Hence Godot must thrive!!!
i think sonic colors ultimate was godot and that game was a buggy mess lol
@steppinonastoop677 That was Godot 3, which is made more for 2d games. Even the godot devs were impressed at the amount of effort it would've taken to do it.
That being said Godot 4 is the engine everyone should be using. Godot 4 was not available yet when sonic colors ultimate was in development.
@@SpeedsterBlur Did they ever explained why they used Godot at all though? With the game targeting nearly platform under the sun, i think Unity would be the best bet, unless SEGA didn't want to play licenses, i guess.
Classic Sonic made me want to buy the game, but when I saw that it wasn't for PS5, I was out. This should be 120fps.
Probably why DARK SOULS /from software games ties the physics rate and animation speed with the frame rate... To offer a consistent experience ... Is it?
The logic gets a lot simpler when you tie everything in the game to a set rate. Calculating the change in time with screen and logic frames has a bit of overhead to it. And if the framerate jumps too high or too low and the code doesn't consider this, you might be moving through thin solid objects or game scripted triggers stop working correctly. If you make a console game, the hardware normally was never supposed to change, so you are never going to get that high speed boost in the future. In some older MS-DOS shooting games with unlocked frame rates, you end up literally shooting yourself today because the framerate gets so high on modern PCs, no one noticed the "bad" logic on the standard slow machines of the 90s until 15 years of hardware advancement showed the problem.
Correct. Though it can have its own issues... See how weapon degradation was faster at higher frame rates.
Software / game development is a constant battle of solving dilemmas, rarely is there a perfect solution. Almost every question in which way to go has an answer of "depends".
No, it's because of incompetence.
Does not happen in godot
The amount of halbwissen is unbearable
❤
I always set my physics to 60 FPS in Unity to avoid random jank.
Such a shame Unity is dead now. At least we have Godot.
Bad QA it is
I'm not a Unity fanboy or anything, but I feel hyperbole like this does more harm than good. You can even see this in the comments talking about how 60hz should be the default and similar nonsense like that, as if that will fix anything. The problem here are bad developers. Period. This has nothing to do with Unity. Setting the default to 60hz would just mask the problem. Unity themselves have stated the reason the default is 50hz and not 60hz is for this exact reason. Programming your game to only work correctly at a specific framerate is stupid.
Actually learning how to use the tools at your disposal when making games, or just in general not being a shit developer and having some semblance of quality control before you ship your game is all that's needed here. As is mentioned in this video, it was immediately visible when playing the game that something was wrong. Hence it should have been immediately visible while developing the game as well. We're not talking about advanced topics here. It doesn't really get more fundamental than ensuring your game is at least capable of running smoothly. The game discussed in this video is programmed to not run smoothly, ever.
You could argue interpolation should be on by default, or you could argue that Unity's use of a fixed timestep for physics is the wrong approach, but none of this changes the fact that a developer that has chosen Unity to develop their game should be expected to know how the engine works before shipping their game.
Tell me the reason why they chose 50hz in a world that works at 60hz.
Is there any justification?
@@deathdoor It's literally written in my reply.
@@TwiiK I ask again, is there a reason why they chose 50hz instead of 60hz? Beyond the supposed "mind games"?
It's because when you set the interval at 20s you get clear 50fps. But if you use 16.66666666.... You will get 60.000000002 that's why
I mean why is nobody talking about the possibility that they werent able to quiet get the game to hit 60 so they just kept it at 50hz in unity? Or is that unrealistic?
Given that Banana Mania doesn’t have this problem (at least on PS5), this was also my guess.
50 hz issues will never leave us
But interpolation will always be the solution.
@@SnakeEngine disgustang
@@nikodem123asdf Well, yeah, the nature of the problem is nasty. And the solution is the same, regardless what engine you use.
@@SnakeEngine it could just be 60 Hz by default since it's the most common refresh rate. Interpolating to a framerate is always a hack job.
@@nikodem123asdf Yeah, but since the refresh rate is never exactly 60, you would get stutters anyway, once in a while. So the natural solution is still to use interpolation.
Dead Core had a hack made by someone to decouple the camera from the... player? Or something? This was back in 2016 maaaan...
DeadCore main artist here. Nice to see it mentionned. ^^ (even in a bad way ah ah)
@@BlindTrustProject LMAO go give the coder a kicking for me
60 hz should be the standard.
Incompetent devs. There is no nice way to explain this.
Hells teeth john, you're lucky you didn't grow up in the spectrum era. 50hz, outrageous!