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
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
@@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
