Its not a bug its an oversight. This is the default behavior of all computer hardware. There is no bug. This is a complete lack of accounting for runtime.
I don't really like the way you phrased it. Code pretty much always runs the way it is written. A bug is any oversight or unintended effect of such code. When your code doesn't run the way you want it to, we call it a bug. Even if the code is running "correctly," because otherwise there'd be no bugs.
This is a bug due to oversight. Rocket turning speed is not meant to be bound to framerate, but it does so it is a bug. Hardware has nothing to do with this, hardware has no concept of ultrakill rocket or the game itself. It's just game logic not taking delta time into account which results in a bug.
that made me remember a lot of video games I've played that delay the speech (it plays the audio, but the game is so laggy that even when the speech ends, the chaaracter is still speakingw the mouth of the character has to stop moving so that he/she can say anything else) it doesnt impact much, just gives you more wait time/cutsene time
Thanks for this video. The game Factorio has a clean model useful for discussing this idea. In their engine, rendering a frame is separated from running a single tick of game logic. A frame is rendered based on a given game logic state. The logic updates can be capped at 60Hz, and now the game runs at the same speed regardless of frame painting. Interestingly, due to the game contents and internals, the logic updates tend to slow down before the rendering code. So in certain cases, you end up with a slower game, but the frames are fine. You don't see this in your average game because 3D games are largely GPU-bound, but Factorio is a CPU-bound 2D game.
Minecraft is also a great example of this, as it runs off a pretty similar process (albeit at 20Hz instead), also resulting in it being primarily CPU-bound performance-wise rather than GPU-bound. Though, being 3D, the effects of high load tend to stack up a lot quicker than with Factorio.
Returning here 2 years after I first saw the video, I realised just now how much I have learnt. I am so grateful for your channel, everytNice tutorialng
sometimes even better than time.deltaTime is time.fixedDeltaTime, which is (typically) tied to the time between physics updates. Might not be the case for every engine, but it's necessary to maintain physics accuracy by ensuring that any discrepancies between physics updates are accounted for.
Nah, it's not that insane that they forgot, pretty sure the config file for ultrakill forces vsync on all the time so it's no wonder this went under the radar
@@SparkPSX ultrakill uses unity right? I guess i can't speak for others, but for anything at all physics related, i would never use Time.deltaTime, so long as its being done in FixedUpdate
@@SparkPSX as a guy who suffered from it, and still got to wave 40, i absolutely can prove it, tho i didn't turn on a rocket since. gonna check how it feels now
Since delta time is 2 frames, wouldnt it still be tied to the framerate? Like, if i were torturing myself and playing at 2 fps then every delta time tick would be a second, whereas if were playing at 200 fps it would be 0.01 seconds
![Can You Beat ULTRAKILL in VR? [ 2 ]](http://i.ytimg.com/vi/Z4JNcL18C4s/mqdefault.jpg)
![Can You Beat ULTRAKILL in VR? [ 2 ]](/img/tr.png)
![BOWKYLION - วิงวอน (ex-change) [Official MV]](http://i.ytimg.com/vi/cLdnZWDaO-w/mqdefault.jpg)
Its not a bug its an oversight.
This is the default behavior of all computer hardware. There is no bug. This is a complete lack of accounting for runtime.
True, actually
I don't really like the way you phrased it.
Code pretty much always runs the way it is written. A bug is any oversight or unintended effect of such code. When your code doesn't run the way you want it to, we call it a bug. Even if the code is running "correctly," because otherwise there'd be no bugs.
This is a bug due to oversight. Rocket turning speed is not meant to be bound to framerate, but it does so it is a bug. Hardware has nothing to do with this, hardware has no concept of ultrakill rocket or the game itself. It's just game logic not taking delta time into account which results in a bug.
oh so that's why rockets go wild after a small button tap
You might be on an old version, this is patched now
Hakita forgets to use deltatime for the 34362th time
Wow, this video explained this perfectly, underrated, nice work!
I think this is why when I see other people use rockets they seem more agile and mobile but when I use it feels clunky and messy
how much fps do you play on?
throughout watching this video i had no idea you were a small channel, your content is very short, but very well made!
That's kinda what I'm going for, I'm not that good at keeping the viewers attention for long periods of time so I'll just keep it short
@@SparkPSX youll improve over time im sure! i hope u go far!
"faster isn't always better"
That's what
She said
Blocked, muted, reported and deleted
That lego island rookie mistake
A fellow MattKC enjoyer
that made me remember a lot of video games I've played that delay the speech
(it plays the audio, but the game is so laggy that even when the speech ends, the chaaracter is still speakingw the mouth of the character has to stop moving so that he/she can say anything else)
it doesnt impact much, just gives you more wait time/cutsene time
cutsece*
Thanks for this video.
The game Factorio has a clean model useful for discussing this idea. In their engine, rendering a frame is separated from running a single tick of game logic. A frame is rendered based on a given game logic state. The logic updates can be capped at 60Hz, and now the game runs at the same speed regardless of frame painting.
Interestingly, due to the game contents and internals, the logic updates tend to slow down before the rendering code. So in certain cases, you end up with a slower game, but the frames are fine. You don't see this in your average game because 3D games are largely GPU-bound, but Factorio is a CPU-bound 2D game.
Yeah, that's a really good example, I play factorio too btw
Minecraft is also a great example of this, as it runs off a pretty similar process (albeit at 20Hz instead), also resulting in it being primarily CPU-bound performance-wise rather than GPU-bound.
Though, being 3D, the effects of high load tend to stack up a lot quicker than with Factorio.
Nice music, I love potsu
Returning here 2 years after I first saw the video, I realised just now how much I have learnt. I am so grateful for your channel, everytNice tutorialng
This is a bot, right?
@@SparkPSX nah bro hes just a time traveler
everytNice tutorialng
this is so underrated. great editing and straight to the point, i love it.
Thats why i cant turn the rocket while playing at 15fps, what a video now where is my hammer...
Don't
Thanks bro that was really helpful
thank you so much! i always wondered what this meant when using unity.
Dude first of all great video. Second of all you are the first guy I have ever seen use a song from potsu in a vid
Potsu songs are straight bangers
@@SparkPSX agreed
I will admit that I do like the game to be tied to framerate when I'm getting like 20fps. just can't control it when I'm missing 2/3rds the action
sometimes even better than time.deltaTime is time.fixedDeltaTime, which is (typically) tied to the time between physics updates.
Might not be the case for every engine, but it's necessary to maintain physics accuracy by ensuring that any discrepancies between physics updates are accounted for.
really good vid, i totally thought you would have 10+ thousand subs!
ah so thats why im always crashing into the walls and not turn quickly
You should be on an old version, this is patched now
Ah lovely frame rate locked physics. People need to study time *time.deltatime
Nah, it's not that insane that they forgot, pretty sure the config file for ultrakill forces vsync on all the time so it's no wonder this went under the radar
@@SparkPSX tbf i didnt know it has an FPS lock
@@SparkPSX ultrakill uses unity right? I guess i can't speak for others, but for anything at all physics related, i would never use Time.deltaTime, so long as its being done in FixedUpdate
Weird that this is happening, because unity has FixedUpdate() which runs at 60 times a second regardless of computer
2 things could have happened, they either multiplied by delta time IN fixedUpdate() OR they forgot to use deltatime in Update()
mmm, love when my fps fucking sucks, and so rocket is slow asf
It used to turn slower than a semi-truck on a roundabout
@@SparkPSX as a guy who suffered from it, and still got to wave 40, i absolutely can prove it, tho i didn't turn on a rocket since. gonna check how it feels now
OH MY FUCKING GOD IT'S SO FAST NOW
Sa. TNice tutorials quarantine is making question my whole existence.
Since delta time is 2 frames, wouldnt it still be tied to the framerate?
Like, if i were torturing myself and playing at 2 fps then every delta time tick would be a second, whereas if were playing at 200 fps it would be 0.01 seconds
MAKE MOREEEE!!!!!!!!!
good i don't know how to code I use unreal engine building blocks
I find those harder to use than code honestly
step one: subframe
in my game if i have a cooldown that needs to be run i add/subtract deltatime every frame
Add?? Subtract??
@@SparkPSX yes. Cooldownvariableholder -= Time.deltaTime;
make more
if only terraria had delta time lol
"Frame Skip: off" user ✊
make more!!!
OK !!