Delta_time is new to me, so I set up my game based on posts by other people that were using delta_time (most of them used delta_time with an abnormally fast room speed).
I see. While it may produce results that technically qualify as "working" for this purpose, this method tortures the hardware of an unsuspecting player for no good reason. You're literally asking the game to absolutely, under any circumstance, max out the player's hardware's capabilities, until one of them creates a bottleneck.
It
does fulfill its intended purpose of keeping the refresh rate of the game at its absolute maximum, but it does so using an extremely unconventional and unhealthy wet bandaid of a workaround rather than a proper solution.
It's a bit like like flooring it in the middle of traffic - it might speed up things (slightly, depending on how fast it's moving by default?), but you run the risk of ending up with a trail of wreckage left behind in your path... or with police and firefighters on your tail. (The firefighters part was only partially a joke... maxing out a PC's hardware over an extended period of time can easily lead to it overheating. Not that it'll catch fire or anything... unless it's extremely old or broken... maybe.)
So with a room_speed of 60, how can a game render smoothely at 144mhz? It doesn't matter if the player's sprite draws 144 times per second if it's position is only updated 60 times per second.
Oh, it does matter. It renders exactly the same way a game that runs at 30 FPS renders on a 60Hz monitor - at 30 FPS, with roughly every second frame displayed twice, at least without lag spikes.
With that said, a higher refresh rate is not only relevant for the amount of
different frames it can display per second. Merely drawing the same frame multiple times can help reduce some visual artifacts such as blurs and trials that are often (more) apparent in monitors with lower refresh rates. I'd even call this a more important aspect than the capability to draw more different frames per second, as you get to experience the benefits of blur and trail reduction regardless of the game's frame rate.
That aside, this is why I mentioned to give players a choice regarding frame rates - if you wish to support higher frame rates, running the game at the respective room speed and adapting timing with delta timing should be the optimal way.
This is kinda getting off topic but I'm curious on how delta_time really works.
To quote the manual,
delta_time "measures the time that has passed between one step and the next in microseconds". It is therefore used to adapt any calculations or values that are otherwise relative to game time (movement in pixels per frame, amount of frames an alarm ticks down) to real time.
With that said, does keeping the room speed at 60 resolve the audio issues by any chance? It shouldn't - as in, it should neither make it work nor break it either way - but just to make sure.
When you say "ever since I've started using delta_time", you don't mean that you're factoring delta time into the 8000 milliseconds of the audio fade calculation, correct? The audio functions are by default based on real time, so applying a second layer of this would surely throw the timing off.
